Re: Best Practices for Internal Package Structure

2016-04-06 Thread Chris Angelico
On Thu, Apr 7, 2016 at 5:37 AM, Sven R. Kunze wrote: > On 06.04.2016 01:47, Chris Angelico wrote: >> >> Generally, I refactor code not because the files are getting "too >> large" (for whatever definition of that term you like), but because >> they're stretching the file's

Re: Best Practices for Internal Package Structure

2016-04-06 Thread Sven R. Kunze
On 06.04.2016 01:47, Chris Angelico wrote: Generally, I refactor code not because the files are getting "too large" (for whatever definition of that term you like), but because they're stretching the file's concept. Every file should have a purpose; every piece of code in that file should

Re: Best Practices for Internal Package Structure

2016-04-06 Thread Sven R. Kunze
On 06.04.2016 09:28, Michael Selik wrote: On Wed, Apr 6, 2016, 2:51 AM Steven D'Aprano wrote: On Wed, 6 Apr 2016 05:56 am, Michael Selik wrote: [Michael] When you made that suggestion earlier, I immediately guessed that you were using PyCharm. I agree that the

Re: Best Practices for Internal Package Structure

2016-04-06 Thread Michael Selik
On Wed, Apr 6, 2016, 2:51 AM Steven D'Aprano wrote: > On Wed, 6 Apr 2016 05:56 am, Michael Selik wrote: > > [Sven R. Kunze] > >> If you work like in the 80's, maybe. Instead of scrolling, (un)setting > >> jumppoints, or use splitview of the same file, it's just faster/easier

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Steven D'Aprano
On Wed, 6 Apr 2016 09:54 am, Ethan Furman wrote: > On 04/05/2016 04:38 PM, Steven D'Aprano wrote: >> On Wed, 6 Apr 2016 04:40 am, Ethan Furman wrote: >> >>> Well, there should be one more module: >>> >>> test.py >>> >>> So in total, two files >>> >>> bidict/ >>> |-- __init__.py >>> |--

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Steven D'Aprano
On Wed, 6 Apr 2016 05:56 am, Michael Selik wrote: [Sven R. Kunze] >> If you work like in the 80's, maybe. Instead of scrolling, (un)setting >> jumppoints, or use splitview of the same file, it's just faster/easier to >> jump between separate files in todays IDEs if you need to jump between 4 >>

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Ethan Furman
On 04/05/2016 04:38 PM, Steven D'Aprano wrote: On Wed, 6 Apr 2016 04:40 am, Ethan Furman wrote: Well, there should be one more module: test.py So in total, two files bidict/ |-- __init__.py |-- test.py Your test code shouldn't necessarily be part of the package though. If I already

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Chris Angelico
On Wed, Apr 6, 2016 at 9:29 AM, Steven D'Aprano wrote: > As we speak, I have 28 text editor windows open. Not all of them are Python > code, but among those which are, I have: > [chomp line number counts] I was about to say "Wow, I don't have anything LIKE that many text

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Steven D'Aprano
On Wed, 6 Apr 2016 04:40 am, Ethan Furman wrote: > Well, there should be one more module: > >test.py > > So in total, two files > > bidict/ > |-- __init__.py > |-- test.py Your test code shouldn't necessarily be part of the package though. If I already have a package, then I will usually

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Steven D'Aprano
On Wed, 6 Apr 2016 03:38 am, Sven R. Kunze wrote: > On 05.04.2016 03:43, Steven D'Aprano wrote: >> The purpose of packages isn't enable Java-style "one class per file" >> coding, especially since *everything* in the package except the top level >> "bidict" module itself is private. bidict.compat

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Mark Lawrence via Python-list
On 05/04/2016 19:49, Sven R. Kunze wrote: It appears to me as if you like messy code then. ;) The messy code is with the person who needlessly splits a single module of a few thousand lines into several modules just for the sake of it. If you want to play yo-yo, leaping from source file to

Re: Best practices for single file modules Inspired by: Best Practices for Internal Package Structure

2016-04-05 Thread Ethan Furman
On 04/05/2016 12:49 PM, Eric S. Johansson wrote: I was inspired by the thread on packaging practices discussion with bidict to ask a related question which is what are the best practices with packaging/releasing a single file Python module ? Back story: I'm always creating little bits of

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Ethan Furman
On 04/05/2016 12:09 PM, Sven R. Kunze wrote: On 05.04.2016 20:40, Ethan Furman wrote: Steven D'Aprano wrote: Your package is currently under 500 lines. As it stands now, you could easily flatten it to a single module: bidict.py Yup... well, actually you could just stick it in __init__.py.

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Michael Selik
> On Apr 5, 2016, at 7:49 PM, Sven R. Kunze wrote: > >> On 05.04.2016 19:59, Chris Angelico wrote: >> On Wed, Apr 6, 2016 at 3:38 AM, Sven R. Kunze wrote: Your package is currently under 500 lines. As it stands now, you could easily flatten it to a

Best practices for single file modules Inspired by: Best Practices for Internal Package Structure

2016-04-05 Thread Eric S. Johansson
I was inspired by the thread on packaging practices discussion with bidict to ask a related question which is what are the best practices with packaging/releasing a single file Python module ? Back story: I'm always creating little bits of useful code that I want to reuse (for example,

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Sven R. Kunze
On 05.04.2016 20:40, Ethan Furman wrote: (utils.py does export a couple of functions, but they should be in the main module, or possibly made into a method of BidirectionalMapping.) Your package is currently under 500 lines. As it stands now, you could easily flatten it to a single module:

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Sven R. Kunze
On 05.04.2016 19:59, Chris Angelico wrote: On Wed, Apr 6, 2016 at 3:38 AM, Sven R. Kunze wrote: Your package is currently under 500 lines. As it stands now, you could easily flatten it to a single module: bidict.py I don't recommend this. The line is blurry but 500 is

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Ethan Furman
On 04/05/2016 10:38 AM, Sven R. Kunze wrote: On 05.04.2016 03:43, Steven D'Aprano wrote: The purpose of packages isn't enable Java-style "one class per file" coding, especially since *everything* in the package except the top level "bidict" module itself is private. bidict.compat and

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Ethan Furman
On 04/04/2016 06:43 PM, Steven D'Aprano wrote: On Tue, 5 Apr 2016 02:47 am, Josh B. wrote: My package, available at https://github.com/jab/bidict, is currently laid out like this: bidict/ ├── __init__.py ├── _bidict.py ├── _common.py ├── _frozen.py ├── _loose.py ├── _named.py ├── _ordered.py

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Chris Angelico
On Wed, Apr 6, 2016 at 3:38 AM, Sven R. Kunze wrote: >> Your package is currently under 500 lines. As it stands now, you could >> easily flatten it to a single module: >> >> bidict.py > > > I don't recommend this. > > The line is blurry but 500 is definitely too much. Those will

Re: Best Practices for Internal Package Structure

2016-04-05 Thread Sven R. Kunze
On 05.04.2016 03:43, Steven D'Aprano wrote: The purpose of packages isn't enable Java-style "one class per file" coding, especially since *everything* in the package except the top level "bidict" module itself is private. bidict.compat and bidict.util aren't flagged as private, but they should

Re: Best Practices for Internal Package Structure

2016-04-04 Thread Steven D'Aprano
On Tue, 5 Apr 2016 02:47 am, Josh B. wrote: > My package, available at https://github.com/jab/bidict, is currently laid > out like this: > > bidict/ > ├── __init__.py > ├── _bidict.py > ├── _common.py > ├── _frozen.py > ├── _loose.py > ├── _named.py > ├── _ordered.py > ├── compat.py > ├──

Re: Best Practices for Internal Package Structure

2016-04-04 Thread Mark Lawrence via Python-list
On 04/04/2016 19:45, Michael Selik wrote: On Mon, Apr 4, 2016 at 6:04 PM Sven R. Kunze wrote: Hi Josh, good question. On 04.04.2016 18:47, Josh B. wrote: My package, available at https://github.com/jab/bidict, is currently laid out like this: bidict/ ├── __init__.py ├──

Re: Best Practices for Internal Package Structure

2016-04-04 Thread Michael Selik
On Mon, Apr 4, 2016 at 6:04 PM Sven R. Kunze wrote: > Hi Josh, > > good question. > > On 04.04.2016 18:47, Josh B. wrote: > > My package, available at https://github.com/jab/bidict, is currently > laid out like this: > > > > bidict/ > > ├── __init__.py > > ├── _bidict.py > > ├──

Re: Best Practices for Internal Package Structure

2016-04-04 Thread Sven R. Kunze
Hi Josh, good question. On 04.04.2016 18:47, Josh B. wrote: My package, available at https://github.com/jab/bidict, is currently laid out like this: bidict/ ├── __init__.py ├── _bidict.py ├── _common.py ├── _frozen.py ├── _loose.py ├── _named.py ├── _ordered.py ├── compat.py ├── util.py

Best Practices for Internal Package Structure

2016-04-04 Thread Josh B.
My package, available at https://github.com/jab/bidict, is currently laid out like this: bidict/ ├── __init__.py ├── _bidict.py ├── _common.py ├── _frozen.py ├── _loose.py ├── _named.py ├── _ordered.py ├── compat.py ├── util.py I'd like to get some more feedback on a question about this layout