On Sat, Sep 24, 2016 at 9:32 PM, Brendan Abel <007bren...@gmail.com> wrote:
>> Splitting it up would make it slower to load.
>
> It's usually the opposite. When packages are split up, you only have to
> load the specific portions you need. Putting it all in a single module
> forces you to always
> Splitting it up would make it slower to load.
It's usually the opposite. When packages are split up, you only have to
load the specific portions you need. Putting it all in a single module
forces you to always load everything.
On Fri, Sep 23, 2016 at 11:59 PM, Lawrence D’Oliveiro <
On Sat, 24 Sep 2016 04:59 pm, Lawrence D’Oliveiro wrote:
> On Saturday, September 24, 2016 at 2:11:09 PM UTC+12, Chris Angelico
> wrote:
>> It's a large and complex module, and about at the boundary of being
>> broken up a bit.
>
> Splitting it up would make it slower to load.
Would it? You've
On Saturday, September 24, 2016 at 2:11:09 PM UTC+12, Chris Angelico wrote:
> It's a large and complex module, and about at the boundary of being
> broken up a bit.
Splitting it up would make it slower to load.
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, Sep 24, 2016 at 11:42 AM, Lawrence D’Oliveiro
wrote:
> On Friday, September 23, 2016 at 4:25:21 AM UTC+12, Chris Angelico wrote:
>> For reference, the Decimal module (ignoring the C accelerator) is over six
>> thousand lines of code, as a single module. Now, that
On Friday, September 23, 2016 at 4:25:21 AM UTC+12, Chris Angelico wrote:
> For reference, the Decimal module (ignoring the C accelerator) is over six
> thousand lines of code, as a single module. Now, that might be pushing the
> boundaries a bit ...
What “boundaries” do you think that might be
Peng Yu writes:
> Is there such a good automated tool for python refactoring?
This sounds like a job for — Bicycle Repair Man!
Watch him extract jumbled code into well ordered classes.
Gasp, as he renames all occurrences of a method.
Thank You Bicycle Repair
On Thu, Sep 22, 2016 at 8:35 PM, Ben Finney wrote:
> Peng Yu writes:
>
>> On Wed, Sep 21, 2016 at 11:14 PM, Ben Finney
>> wrote:
>> > [Importing ‘*’ from a module] will also make the names in the code
>> > impossible
Peng Yu writes:
> On Wed, Sep 21, 2016 at 11:14 PM, Ben Finney
> wrote:
> > [Importing ‘*’ from a module] will also make the names in the code
> > impossible to automatically match against where they came from.
> > Explicit is better than
On Fri, Sep 23, 2016 at 1:50 AM, Peng Yu wrote:
>
> This will make refactoring easy. If everything is explicit, when one
> do refactoring, at two places need to be changed which can be a
> burden.
So you want it to be easy to move stuff around between files in a
package?
On Wed, Sep 21, 2016 at 11:14 PM, Ben Finney wrote:
> Peng Yu writes:
>
>> I want to import all the thing (or the ones available in the
>> respective __all__) defined in each of the file by putting the
>> following lines in __init__.py
>>
>> from
Peng Yu writes:
> I want to import all the thing (or the ones available in the
> respective __all__) defined in each of the file by putting the
> following lines in __init__.py
>
> from file1 import *
>
> from filen import *
>
> However, I don't want to hardcode the
Hi,
Suppose that I have file1.py, ..., filen.py in a module directory.
I want to import all the thing (or the ones available in the
respective __all__) defined in each of the file by putting the
following lines in __init__.py
from file1 import *
from filen import *
However, I don't want
13 matches
Mail list logo