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 concept. Every file shou
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 ideally
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 decision to split into multip
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
> to
> >> jump betwee
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
>>> |-- test.py
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
>> pl
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 ha
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
editor windows open"... b
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
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 a
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
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 useful
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.
> 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 single module:
bidict.py
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, recursi
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:
b
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 definitely too much. T
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 bidict.util
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
├
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 simply not fit
> o
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 be
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
> ├── util.py
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
├── _bidict.py
├── _c
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
> > ├── _common.py
> > ├─
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
I'd
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
26 matches
Mail list logo