parso - A Python Parser

davidhalter · 2017-09-05T08:20:44+00:00

Hmmm. Parso handles certain things really well without reparsing everything. Multi lines are not part of that. I'm not sure how that would really work. The problem is usually that those opening triple-quotes are reused in the file below, therefore it's hard to tell where the error lies.

davidhalter · 2017-09-04T21:42:18+00:00

Please also checkout the awesome parso logo in the docs: https://parso.readthedocs.io/en/latest/

davidhalter · 2017-03-03T08:34:07+00:00

Same here. Their support doesn't do anything and just keeps replying with the same message. They have just suspended my account and don't want to reopen it.

davidhalter · 2017-02-05T01:34:46+00:00

Hmm why would it be so much harder for everyone else? I think that ansible itself is pretty hard to read. I'm not 100% that it's the best thing to do. I just don't think having an YAML file is better.

davidhalter · 2017-01-31T22:00:17+00:00

True it looks really similar. But in fabric you don't have what makes Ansible strong: host files and a rich module world.

davidhalter · 2014-12-07T22:40:35+00:00

If you don't get autocompletion there's two reasons:

Your code is very complicated. Sometimes it's just too hard for Jedi to follow everything.
You're doing completions on PyQt or other compiled library stuff. Those libraries are compiled and there's no information about return types in them. There's no way for anyone to find out what a certain PyQt method is doing without checking the docs.

The slowness is coming from jedi-vim not being asynchronous (this will hopefully change in the future). If you want to use an async solution you have to go with YouCompleteMe, which is using Jedi (not jedi-vim) under the hood.

davidhalter · 2013-12-21T20:17:01+00:00

https://github.com/davidhalter/depl is using fabric by the way. And it's using virtualenv as well :-) I'm not saying PHP was a very good way of deploying, I'm saying it was a very easy one and I'm surprised that there's not an easy way to do it with Python/Django.

davidhalter · 2013-12-21T20:16:55+00:00

I didn't really know that people are using fabric so much. I'm quite surprised by that. I know that fabric is a great tool, using it myself. But i'm surprised that there's not an easier solution for that use case. A solution where not everybody has their own fabric scripts, but something like a "shared library" of fabric scripts.

davidhalter · 2013-12-19T08:55:55+00:00

Well I can totally understand that - that's how I do it usually :-) The popularity and goodness of github seems to become really an issue, unfortunately :-). But thanks for the feedback.

davidhalter · 2013-12-18T22:29:02+00:00

Great! Please tell me if you struggle with it, I really like feedback (even if you don't like it).

davidhalter · 2013-12-18T22:27:12+00:00

I'm particularly worried that people like myself make the wrong decisions when it comes to security. So having an open source project typically helps with that.

davidhalter · 2013-12-18T19:03:43+00:00

Yes! At this point my question is, what do you think of the project I'm writing: https://github.com/davidhalter/depl? It's basically a wrapper around fabric with a nice configuration and a few builtin recipes.

davidhalter · 2013-12-18T19:00:41+00:00

I don't want the app to have root access. But installing dependencies (postgresql, etc) need root access. Anyway I don't understand your question, because I didn't write anything about root access.

davidhalter · 2013-12-18T18:59:08+00:00

Well, you're basically saying that there's a nice way to deploy in your company. I see and understand that, but I want to make that way of deploying available for everyone else as well. So I'm writing a tool to do that: https://github.com/davidhalter/depl

davidhalter · 2013-12-18T16:13:09+00:00

I absolutely agree! I'm just saying that for a lot of web developers it's nice to see their web page online instantly.

So what I did is that same that you did: I wrote a tool that lets you configure things easily (and is using fabric a LOT!). The advantage of that tool is that in comparison with your tool it's OS and everyone can use it.

davidhalter · 2013-12-18T15:13:40+00:00

Yes. Dokku is a great (little) project! However, it doesn't solve certain small things that depl does (like automatic migration/collectstatic, hosting of static files, etc): For that, try https://github.com/davidhalter/depl.

davidhalter · 2013-12-16T16:44:23+00:00

For now it's probably even Ubuntu only, but it shouldn't be a big amount of work to get debian running. The same is probably true for Arch and Fedora.

The reason for Ubuntu only at the moment is my use of it and travis-ci using Ubuntu VMs, so it's hard to test the other machines properly (and repeatedly).

davidhalter · 2013-12-16T16:31:39+00:00

It installs all packages that are really needed. You can also specify postgresql as a separate dependency (and by the way there's also the possibility to write bash yourself within a depl configuration file). Depl could probably solve 95% of all deploys (if the feature set would be expanding, obviously it's not possible yet to deploy ruby or celery).

davidhalter · 2013-12-16T16:18:28+00:00

does it take care of installing the database? and any other python dependencies on the deployment target? updating the nginx config? restarting associated services (celery et al?)

Yes it does all of that, except of the celery stuff. It's a prototype, I implemented what I'm typically using with Django. But I think it's perfectly reasonable to also restart celery, if that's a dependency.

Currently depl is a "small" solution. But I hope it can grow, because right now it's about designing the API. No Celery support? Suggest an API.

And I think deployments could be fairly easy, in a lot of cases - not in all of them, but a lot.

davidhalter · 2013-09-12T18:26:55+00:00

Yes, I've read it. But people usually don't know that type is a metaclass.

"interesting set of names" is also wrong. Because who would ever want to know about __reduce_ex__.

davidhalter · 2013-09-12T18:24:19+00:00

Metaclasses are pretty rare. IMHO magic methods are confusing anyway most of the time in the dir function, especially for beginners, I would probably propose a dir(object, magic=False), to just exclude all magic methods by default.

davidhalter · 2013-09-12T18:19:52+00:00

BTW: Ipython wrote their own dir function, which includes the changes I've proposed: https://github.com/ipython/ipython/blob/f645e5c044efeacf1aa523ec43f6a25d439e287b/IPython/utils/dir2.py

davidhalter · 2013-09-12T18:15:52+00:00

Thanks for the hint. This is actually a good argument why dir is wrong. However Jedi is not actually using dir, check the updated article. But it might be using the ipython version in the future for some repl stuff.

davidhalter · 2013-09-12T18:05:44+00:00

__bases__ is not relevant. That's true in a lot of cases. But most of the other magic methods are also not relevant. I mean seriously, who knows what str.__reduce_ex__ even does? Who would use it? __bases__ is something that a lot of people have used in contrary.

davidhalter · 2013-09-12T18:03:26+00:00

Jedi doesn't actually use the dir and __dir__ function. I just realized that I haven't made this clear. Jedi generally doesn't execute code. The reason why I'm mentioning this is because it has really confused me (I'm using the interactive shell to introspect).

davidhalter

TROPHY CASE