guyzmo

a coconut!

I'm guilty of the Lua feature, and even though it's only covering the existing muttrc API, it can already do quite a lot. The Lua feature is (not yet) turned on by default at compile time (and thus in systems distributions).

I'd be very happy to have more feedback and help to extend further that API and have some great scripts happening!

Oh, I need to make a ticket about adding that to the wizard. Be my guest if you want to :-)

<3 I guess you're referring to my other project :-)

Yes there is! There's a bug that has been found that crashes the feature, but I got a patch ready to publish.

thank you. Please suggest a better name! :-D

Well, for the easy to remember, I might have been presomptuous O:-)

Well as I said for another post I'm aware of that. As the google project is mostly used only for android and chromium, and as the canonical name of the tool really is /repo/ and not /git-repo/, there's no real name clashing.

The only issue might be my project being shadowed by google and go, but the more people will like and use the tool I baked with , the more it'll appear on their first page. So it's not really up to me, but up to you all liking it!

And finally, if someone comes with a nicer better name than what I chose (I actually did not spend more than 2.42 minutes on the name when I had to mkdir the project's directory), I might be happy to rename :)

Otherwise, I hope you'll like the tool and send me patches and <3

Well, TBH, as an engineer, I hate to reinvent the wheel. I prefer to join and improve the existing concept with my own ideas to make it the synthesis of many peoples ideas

You might see on my github that I do that a lot, I'm being some sort of mercenary of FLOSS projects, as I patch wherever I see a bug or want a new feature without really caring about the "big plan"

Actually, I wrote the tool because deep down I just want to /use/ the tool.

My bad, I did not scroll down to see how complete the command set was. At the top of the readme the list of commands is misleading (I thought there were only those at the first read).

I'm not sure I can see a real use for checking out every repo of an organisation (I mean, if you do that with mozilla, you better start before going for a long holiday ), but having it /possible/ is a great thing

So I guess we're pretty much alike, git-repo being strong for being service agnostic, and git-hub being more complete.

Though, in my redesign plan I got for version 2, I have in mind a framework to make it possible to implement service-specific CLI API, while sharing a same core CLI API for the service-agnostic features.

So my hope is that people will like the tool enough to participate in the development and help make the tool more feature complete across the services!

hehe, it's also implemented in git-repo: `git hub open`

note that I did not say that git has a good UX, I said it's /rather well designed/… Maybe should I have emphazised on the /rather/, or used something stronger like /relatively/ .

But anyway, designing the command line API of my own tool took me enough headaches — and I'm still not 100% satisfied — to understand how hard it is to have a consistent and great UX for something that offer as many features as git does. Though, I'm trying my best to avoid the decade old troll about git's UX (like vs mercurial)…

In the end, what I try to make clear it's that I'm not trying to replace what git does, but cluster a bunch of repository actions tied with some service's API operations.

And I try my best to offer a pleasant UX doing so. But please, help me making it better!

Thank you, though pretty close, our approaches are slightly different. My main focus is use case, I did not implement the social features of a repository, because those are things that happen happily in a browser.

But project/merge requests/gists are things that have a lot of sense to happen in the commandline /instead/ of within the browser. So basically, his solution is more feature complete on the social side, whereas I implemented more the repository interaction side (like creating gists, or fetching a PR).

So for sure he's got a point for portability being a bash script, but still python3 is begining to be widespread enough.

I mean, if debian-stable got it, you can consider it's everywhere…

Bitbucket support is there. But it's not feature complete, and not up to my standards…

The issue I have is that I got to implement OAuth2 for bitbucket, because the privatekey scheme offered by bitbucket does not work for a CLI tool use case. So currently, the credentials (login/password) of bitbucket are stored in CLEAR in the configuration file, which really, really sucks…

And some new features (like the snippets) are not implemented in third part python libraries, because most of the libs are old and unmaintained.

Anyway, following some discussions I had with atlassian bitbucket developers, bitbucket (like gitlab) is planning to switch to swagger, which will help automagical generation of client-side feature complete libraries. So I'm planning to level bitbucket feature set as soon as they land the new API.

So I hope it won't be long before all the features will land for the three services!

nah, I don't think so, I think you might have reloaded as I was recompiling the blog

And I hope also level the game for alternatives to github. Git is distributed by nature, and we should only be happy to see cross services forks happening!

what the… ok I totally missed that one! And I DID search before writing such a tool

See the issues, it's already implemented, but not released yet. The issue is that I also am working on the gitlab snippets… which lacks an API. So I'm currently working on a patch to add an API to the gitlab snippets, so my tool can have gitlab snippets!

https://github.com/guyzmo/git-repo/commit/59c7ac2cd4c0316016...

So pretty soon I hope I'll be able to finish both MR and snippets for gitlab, and finish the tests and merge all that back to git-repo!

Well, first the name really is `git-repo` not `repo`, and as nobody has really heard of it yet, the pypi package is already on first page of go, and second page of google.

I hope that if people like the tool, it's going to be easier to find.

Of course, I'm not really obsessed with the name (as anyway the tool is designed so the user does not type git-repo everyday ). So if someone comes up with a name that's great that can be better, I'm all ears!

About the fact that google has that other tool… Well they really are not much projects using it, beyond the google projects, and the tool really is called `repo`, not `git-repo`, so the name clash is not really there.

Thanks, fixed

Well, I saw about hub, but I wasn't happy with the fact that it's a github only tool, I really wanted a service agnostic tool, and also because the CLI API was not great. I don't want a tool to replace git, I want it to extend it.

What git-repo really offers is a tool that integrates nicely to the git CLI (as `git-something` is also available as `git something`, so git-repo acts per default as `git repo hub…`). And then it autoconfigures the .gitconfig aliases to have the `git hub`, `git lab`, `git moo` you'd want.

So besides the fact that hub is certainly much more mature than my tool, it wouldn't be a tool I'd like to really use.

thank you a lot for your comments

I actually wrote that tool based on a huge frustration I had going back and forth to the browser, and not being able to work while being agnostic to the services, which felt being a totally broken UX. I have then worked on that tool for a while, used it and refactored it a lot up until I'm happy using it.

All in all, when I'm doing a tool, I'm first doing it for myself (I might invent the DIFY concept, to override the DIY concept )… only then I'm sharing it with others.

The sad truth is: s/Some/Most/

Yes! Exactly! I added the py3 links of those in my big lengthy parent comment, so people get twice the chance to RTFM !

Well, private fields are all members starting with an underscore and that are not publicised in the documentation.

/That/ includes double underscores mangled members and and "magic" methods.

Yes, it is intended and fully part of the philosophy behind the language's design (as shown in PEP-20, aka the Zen of Python):

> Explicit is better than implicit

So there's no "leaking" of implementation details, because the implementation shall always be fully exposed.

As said in a sibling post, the private fields are just public fields, which are not documented as part of the public API and start with a `_`.

And as I said in the parent post, the reason to use the name mangling mechanism on top of that is to ensure that those variables won't be used by descendants in the class hierarchy, when a given class is intended to be subclassed by a peer.

The the sugar /is/ actually sugary-sweet-yummy, as it's preventing potential faults from people who blindly subclass stuff they haven't read the source code of.

just been fixing that, though I've added four, I hope it's ok

The part of the article about an issue with name mangling of private fields is somehow misleading.

The feature is just some syntactic sugar.

When within a class, private fields such as:

    class Foo:
        def __init__(self):
            self.__bar

are accessible from within other methods of class Foo as `self.__bar`. But that's just syntactic sugar, the real name of `self.__bar` is `self._Foo__bar`.

So from the outside "world", including `hasattr()`, you can still access `self.__bar` as `Foo()._Foo__bar`.

    >>> class Foo():
    ...   def __init__(self):
    ...     self.__bar = 'hello'
    ...   def show(self):
    ...     print(1, self.__bar)
    ...     print(2, getattr(self, '__bar'))
    ... 
    >>> foo = Foo()
    >>> foo._Foo__bar
    True
    >>> foo.show()
    1 hello
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 6, in show
    AttributeError: 'Foo' object has no attribute '__bar'
    >>> foo.__bar = 'world'
    >>> foo.show()
    1 hello
    2 world

In the end, when `x.__private` is setup outside of the class definition, obviously, it's a new member as its name differs from the internal name `__private` (which really is `_X__private`).

From within the code doing `getattr('X', '__private')` will return the `__private` setup from outside the class, and `getattr('X', '_X__private')` the one defined from within the class.

The whole point of that feature is to ensure that members defined within a class that are not part of the public API are left untouched when that class get subclassed, to avoid unexpected behaviours.

Here's an example of why this has been designed:

  >>> class A:
  ...   def __init__(self):
  ...     self.__internal = "this is a"
  ...   def show(self):
  ...     print(1, "A", self.__internal)
  ... 
  >>> class B(A):
  ...   def __init__(self):
  ...     super(B, self).__init__()
  ...     self.__internal = "this is b"
  ...   def show(self):
  ...     super(B, self).show()
  ...     print(2, "B", self._A__internal)
  ...     print(3, "B", self.__internal)
  ... 
  >>> B().show()
  1 A this is a
  2 B this is a
  3 B this is b
  >>> 

There's nothing that should be surprising or asymmetrical to anybody who've read the python documentation, and use that feature appropriately. It's maybe a weird feature, but it's still a coherent and homogeneous behaviour and actually adding more safety to codes.

Documentation references:

  * https://docs.python.org/3/faq/programming.html#i-try-to-use-spam-and-i-get-an-error-about-someclassname-spam
  * https://docs.python.org/3/reference/expressions.html#atom-identifiers

well, the main feature Excel really suck, and makes it almost impossible to use: Undo/Redo. Why the hell did they make undo/redo work across spreadsheets (eventually reopening closed spreadsheets)?

And then, why is it impossible once you wrote some content, to copy it, undo writing it and paste it? The copy gets undoed!

To me, that behaviour makes Excel unusable.

And anyway, why would any decent SW engineer want to use Excel, which is like a 2 dimensional view of the world, whereas after a career designing software I can see the multiverse.

Wel, too bad they did not implement this with python 3, and actually gave some meaning to the type annotations… I mean

def dprod(l0: list[int], l1: list[int]): return sum(x * y for x, y in zip(l0, l1))

Wouldn't it be much nicer?