Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

github.com

Post reply on HN
Print view View original

91–100 of 192 posts

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#91

Post by xwowsersx »

onedognight wrote: post #70

The “src/“ directory[0] contains compiled .so files. Is this even open source? [0] https://github.com/cirospaciari/socketify.py/tree/main/src/s...

Hmm... there's Python and CPP.

  src/socketify
  ├── __init__.py
  ├── __main__.py
  ├── asgi.py
  ├── cli.py
  ├── helpers.py
  ├── libsocketify_darwin_amd64.so
  ├── libsocketify_darwin_arm64.so
  ├── libsocketify_linux_amd64.so
  ├── libsocketify_windows_amd64.dll
  ├── loop.py
  ├── native
  │  ├── Make.bat
  │  ├── Makefile
  │  ├── src
  │  │  ├── libsocketify.cpp
  │  │  └── libsocketify.h
  │  └── uv_selector.txt
  ├── native.py
  ├── socketify.py
  ├── ssgi.py
  ├── status_codes.py
  ├── tasks.py
  ├── uv.py
  ├── uWebSockets
  └── wsgi.py
I think the .so files are built from other source though? I'm not sure. In the makefile they are rm'd and then created. The linux workflow file, for example, has:

  make linux
  cd ../
  git add libsocketify_linux_amd64.so

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#93

Post by xwowsersx »

o_1 wrote: post #87
cirospaciari wrote: post #72

Earlier quoted context omitted.

Python (CPython) is written in C so always will be C, PyPy i think is C too? not sure.

Claiming python has blazing speed while literally being CPython is insanity. This is like saying "Im a natural body builder who only uses Test, HGH, and Dianabol". Great drop the natural part, similarily just advertise speed as CPython.

By bodybuilder standards, using just Test, HGH, and Dianabol is practically natty!

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#94

Post by cirospaciari »

xwowsersx wrote: post #91
onedognight wrote: post #70

The “src/“ directory[0] contains compiled .so files. Is this even open source? [0] https://github.com/cirospaciari/socketify.py/tree/main/src/s...

Hmm... there's Python and CPP. src/socketify ├── __init__.py ├── __main__.py ├── asgi.py ├── cli.py ├── helpers.py ├── libsocketify_darwin_amd64.so ├── libsocketify_darwin_arm64.so ├── libsocketify_linux_amd64.so ├── libsocketify_windows_amd64.dll ├── loop.py ├── native │ ├── Make.bat │ ├── Makefile │ ├── src │ │ ├── libsocketify.cpp │ │ └── libsocketify.h │ └── uv_selector.txt ├── native.py ├── socketify.py ├── ssgi…

you need to pull all git submodules too git submodule update --init --recursive --remote

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#95

Post by davedx »

jimnotgym wrote: post #66

I'm feeling old. I went back to Flask recently and keep finding everything I know is deprecated, or not best practice any more. Then I read every week that some new framework is out that is better. I'm tired of it. I end up spending more time learning new things than I do building new things! Maybe I should get off hn for a while

JavaScript Developer has entered the chat

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#96

Post by ModernMech »

Ensorceled wrote: post #43
kasey_junk wrote: post #2

This is a python wrapper around libuv not a pure python solution (not that it’s bad but it explains the click bait title).

I don't really understand this criticism nor why it's "clickbait". I have 12 "unpure" python packages in production. If my app ever needs WSGI, I'll have 13.

The reason this is clickbait is because you can wrap libuv in some other language and get the same results. So what’s the purpose of this article? That a language can wrap libuv is not a new or interesting idea.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#97

Post by [deleted] »

jimnotgym wrote: post #66

I'm feeling old. I went back to Flask recently and keep finding everything I know is deprecated, or not best practice any more. Then I read every week that some new framework is out that is better. I'm tired of it. I end up spending more time learning new things than I do building new things! Maybe I should get off hn for a while

[deleted]

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#98

Post by asoneth »

jimnotgym wrote: post #66

I'm feeling old. I went back to Flask recently and keep finding everything I know is deprecated, or not best practice any more. Then I read every week that some new framework is out that is better. I'm tired of it. I end up spending more time learning new things than I do building new things! Maybe I should get off hn for a while

I feel you. Tooling for programming often seems to presume that programming is your primary focus and that you can afford to spend time every month keeping up with changes. For a small passion project the overhead of this churn eats a large fraction of the time budget, not to mention the demotivation of realizing how much energy you are spending to essentially tread water.

Whereas with art or math or writing projects I can come back to old notes decades later and basically pick up where I left off.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#99

Post by epolanski »

jimnotgym wrote: post #66

I'm feeling old. I went back to Flask recently and keep finding everything I know is deprecated, or not best practice any more. Then I read every week that some new framework is out that is better. I'm tired of it. I end up spending more time learning new things than I do building new things! Maybe I should get off hn for a while

That's just the nature of our work.

Anyway what worked fine yesterday isn't necessarily a bad choice today.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#100

Post by ktzlf »

I assume that if this C-extension is faster than Golang Fiber, it is way faster than asyncio!

And it would have been the same with Python 2.7. This demonstrates yet again that the main value of Python has always been C-extensions.

The efforts of the old boys to add bloat in Python 3 (mostly written by other people of course, the old boys talk and rarely develop) have been misguided.

Post reply on HN