5 ms·

Too much abbreviation! pypeline --> pypeln multiprocessing pipeline --> pr threads pipeline --> th asyncio pipeline --> io this is totally unnecessary If

Too much abbreviation! pypeline --> pypeln multiprocessing pipeline --> pr threads pipeline --> th asyncio pipeline --> io this is totally unnecessary If I want to use short abbreviated names in my code I can always `from pypeline import multiprocess_pipeline as pr` Your library shouldn't export them like this as the default. `io` is especially bad since this overshadows the `io` module in the Python stdlib

thenaturalist 8y ago
Absolutely agree with this.
ricw 8y ago
Not a fan of this. You save a couple of chars and massively decrease legibility. Anyone new to the project will find it way harder to understand. Instead of abbreviation hell, just spell it out and move on. Not worth saving a couple of characters.
- maxander 8y ago
  True masters of naming make sure to use variable names that are long but unambiguous after the first several characters, so that with tab-completion you get the best of both worlds.
dajohnson89 8y ago
At risk of speaking from ignorance (i dont really know python), isn't this succinctness an aim of python? A lot of python enthusiasts i speak with decry the verbosity of Java and point to how much less code it takes to do the same thing in python.
- trymas 8y ago
  Python has a famous adage `explicit better than implicit`. You want to be explicit but still concise while writing python. I do not have any experience with Java, but I guess when writing Java you can feel that you use too many words than needed (i.e. definition of verbose [0]), wikipedia has a hello world example[1] and it feels just heavy. IMHO if you write pythonic code, very often it feels like writing/reading prose, seems like talking to computer. You are not too implicit, neither too verbose. [0] https://www.merriam-webster.com/dictionary/verbose https://www.merriam-webster.com/dictionary/verbose [1] https://en.wikipedia.org/wiki/Java_(programming_language)#"Hello_world"_example https://en.wikipedia.org/wiki/Java_(programming_language)#"H...
  - agumonkey 8y ago
    I'm guilty of this, because words are so meaningless to me. I'd rather have single lettre or glyph than ~clear yet ambiguous words.
- dec0dedab0de 8y ago
  It's really more about readability, In this case threads_pipeline is much easier to understand than th. Descriptive names also means needing less comments.
- anentropic 8y ago
  The succinctness of Python (such as there is) comes from the syntax itself. On the other hand, obscure variable names are discouraged. It's not a 'code golf' language. The aim is clarity and readability - unobscured by either verbose boilerplate or excessive brevity. A library author should provide names which are descriptive and clear. Users can then abbreviate them however much or little as we choose (by import aliasing). For example it is very common to see `import numpy as np`... but you wouldn't want them to publish the library as `np`. It should have its proper name. One reason for this is if I'm exploring code in a REPL or IDE with tab-completion. You want to have some idea what a module is for, without having to play 'guess the abbreviation'.
sebcat 8y ago
Agreed. When it comes to naming things, I really like the way Russ Cox puts it: https://research.swtch.com/names https://research.swtch.com/names
rcthompson 8y ago
And it's especially unnecessary since Python already supports abbreviation during import. It could just as easily be "from pypeline import process as pr" or something similar.
cgarciae 8y ago
Point taken! Thanks a lot for your feedback. Just a few points: * pypeline is already taken :( * My main reason for this was because initially I was thinking that you did an `import pypeln as pl` and then called things like e.g. `pl.pr.map` since you cant abbreviate the module inside `pl` then I picked short names, but then I decided to go for and import the module kind of strategy. I am thinking about expanding the module names to their worker names: * pr --> process * th --> thread * io --> task And then have the conventions * from pypeln import process as pr * from pypeln import thread as th * from pypeln import task as io # as ta? This conversation is very valuable, thank you all for the feedback.
- neuromantik8086 8y ago
  "import pypeln as pl" could cause quite a bit of confusion in Poland I would imagine.
  - bb88 8y ago
    And maybe perl...
  - cgarciae 8y ago
    jajajajaja
- bb88 8y ago
  First of all, it's super cool. :) There are a lot of "pipe" projects in PyPi, but your project is also about process management. Maybe you should avoid "pipe" in your name perhaps? FlowProcessor? nFlow? xFlow? I do agree that you should avoid io for asyncio. You should probably at least use aio, but there's no reason you can't have asyncio_task, thread_task, multiprocessing_task. Lastly, in my mind the killer app for this would be to allow something that works on top of Celery in production, but then be able to fall back to say multiprocessing or threading when running locally. That would allow me to prototype something, and then when I want to scale, I can just change a config setting.
  - cgarciae 8y ago

thenaturalist 8y ago

Absolutely agree with this.

ricw 8y ago

Not a fan of this. You save a couple of chars and massively decrease legibility. Anyone new to the project will find it way harder to understand. Instead of abbreviation hell, just spell it out and move on. Not worth saving a couple of characters.

maxander 8y ago
True masters of naming make sure to use variable names that are long but unambiguous after the first several characters, so that with tab-completion you get the best of both worlds.

dajohnson89 8y ago

At risk of speaking from ignorance (i dont really know python), isn't this succinctness an aim of python? A lot of python enthusiasts i speak with decry the verbosity of Java and point to how much less code it takes to do the same thing in python.

trymas 8y ago
Python has a famous adage `explicit better than implicit`. You want to be explicit but still concise while writing python. I do not have any experience with Java, but I guess when writing Java you can feel that you use too many words than needed (i.e. definition of verbose [0]), wikipedia has a hello world example[1] and it feels just heavy. IMHO if you write pythonic code, very often it feels like writing/reading prose, seems like talking to computer. You are not too implicit, neither too verbose. [0] https://www.merriam-webster.com/dictionary/verbose https://www.merriam-webster.com/dictionary/verbose [1] https://en.wikipedia.org/wiki/Java_(programming_language)#"Hello_world"_example https://en.wikipedia.org/wiki/Java_(programming_language)#"H...
- agumonkey 8y ago
  I'm guilty of this, because words are so meaningless to me. I'd rather have single lettre or glyph than ~clear yet ambiguous words.
dec0dedab0de 8y ago
It's really more about readability, In this case threads_pipeline is much easier to understand than th. Descriptive names also means needing less comments.
anentropic 8y ago
The succinctness of Python (such as there is) comes from the syntax itself. On the other hand, obscure variable names are discouraged. It's not a 'code golf' language. The aim is clarity and readability - unobscured by either verbose boilerplate or excessive brevity. A library author should provide names which are descriptive and clear. Users can then abbreviate them however much or little as we choose (by import aliasing). For example it is very common to see `import numpy as np`... but you wouldn't want them to publish the library as `np`. It should have its proper name. One reason for this is if I'm exploring code in a REPL or IDE with tab-completion. You want to have some idea what a module is for, without having to play 'guess the abbreviation'.

sebcat 8y ago

Agreed. When it comes to naming things, I really like the way Russ Cox puts it: https://research.swtch.com/names https://research.swtch.com/names

rcthompson 8y ago

And it's especially unnecessary since Python already supports abbreviation during import. It could just as easily be "from pypeline import process as pr" or something similar.

cgarciae 8y ago

Point taken! Thanks a lot for your feedback. Just a few points: * pypeline is already taken :( * My main reason for this was because initially I was thinking that you did an `import pypeln as pl` and then called things like e.g. `pl.pr.map` since you cant abbreviate the module inside `pl` then I picked short names, but then I decided to go for and import the module kind of strategy. I am thinking about expanding the module names to their worker names: * pr --> process * th --> thread * io --> task And then have the conventions * from pypeln import process as pr * from pypeln import thread as th * from pypeln import task as io # as ta? This conversation is very valuable, thank you all for the feedback.

neuromantik8086 8y ago
"import pypeln as pl" could cause quite a bit of confusion in Poland I would imagine.
- bb88 8y ago
  And maybe perl...
- cgarciae 8y ago
  jajajajaja
bb88 8y ago
First of all, it's super cool. :) There are a lot of "pipe" projects in PyPi, but your project is also about process management. Maybe you should avoid "pipe" in your name perhaps? FlowProcessor? nFlow? xFlow? I do agree that you should avoid io for asyncio. You should probably at least use aio, but there's no reason you can't have asyncio_task, thread_task, multiprocessing_task. Lastly, in my mind the killer app for this would be to allow something that works on top of Celery in production, but then be able to fall back to say multiprocessing or threading when running locally. That would allow me to prototype something, and then when I want to scale, I can just change a config setting.
- cgarciae 8y ago