Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #101963 > unrolled thread

importing: what does "from" do?

Back to article view | Back to comp.lang.python

Contents

  importing: what does "from" do? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2016-01-21 14:20 +0000
    Re: importing: what does "from" do? Ian Kelly <ian.g.kelly@gmail.com> - 2016-01-21 07:52 -0700
      Re: importing: what does "from" do? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2016-01-21 15:12 +0000
        Re: importing: what does "from" do? Ian Kelly <ian.g.kelly@gmail.com> - 2016-01-21 08:59 -0700
          Re: importing: what does "from" do? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2016-01-21 16:30 +0000
            Re: importing: what does "from" do? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2016-01-21 16:41 +0000
        Re: importing: what does "from" do? Steven D'Aprano <steve@pearwood.info> - 2016-01-22 03:22 +1100
    Re: importing: what does "from" do? John Gordon <gordon@panix.com> - 2016-01-21 15:31 +0000
      Re: importing: what does "from" do? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2016-01-21 15:37 +0000
        Re: importing: what does "from" do? John Gordon <gordon@panix.com> - 2016-01-21 15:44 +0000
          Re: importing: what does "from" do? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2016-01-21 15:46 +0000
            Re: importing: what does "from" do? John Gordon <gordon@panix.com> - 2016-01-21 15:59 +0000
          Re: importing: what does "from" do? "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2016-01-21 15:53 +0000
            Re: importing: what does "from" do? Steven D'Aprano <steve@pearwood.info> - 2016-01-22 03:28 +1100
    Re: importing: what does "from" do? Rustom Mody <rustompmody@gmail.com> - 2016-01-21 23:03 -0800
      Refactoring in a large code base (was: importing: what does "from" do?) Ben Finney <ben+python@benfinney.id.au> - 2016-01-22 18:54 +1100
        Re: Refactoring in a large code base Marko Rauhamaa <marko@pacujo.net> - 2016-01-22 10:29 +0200
          Re: Refactoring in a large code base Rustom Mody <rustompmody@gmail.com> - 2016-01-22 01:21 -0800
            Re: Refactoring in a large code base Marko Rauhamaa <marko@pacujo.net> - 2016-01-22 12:19 +0200
              Re: Refactoring in a large code base Chris Angelico <rosuav@gmail.com> - 2016-01-22 22:19 +1100
                Re: Refactoring in a large code base Marko Rauhamaa <marko@pacujo.net> - 2016-01-22 13:54 +0200
                  Re: Refactoring in a large code base Chris Angelico <rosuav@gmail.com> - 2016-01-22 23:28 +1100
                    Re: Refactoring in a large code base Marko Rauhamaa <marko@pacujo.net> - 2016-01-22 15:00 +0200
                      Re: Refactoring in a large code base Chris Angelico <rosuav@gmail.com> - 2016-01-23 00:26 +1100
                        Re: Refactoring in a large code base Marko Rauhamaa <marko@pacujo.net> - 2016-01-22 15:48 +0200
                          Re: Refactoring in a large code base Chris Angelico <rosuav@gmail.com> - 2016-01-23 01:09 +1100
                Re: Refactoring in a large code base Rustom Mody <rustompmody@gmail.com> - 2016-01-22 04:04 -0800
                  Re: Refactoring in a large code base Marko Rauhamaa <marko@pacujo.net> - 2016-01-22 14:21 +0200
                  Re: Refactoring in a large code base Thomas Mellman <tmellman@web.de> - 2016-01-22 12:27 +0000
                  Re: Refactoring in a large code base Chris Angelico <rosuav@gmail.com> - 2016-01-22 23:34 +1100
                    Re: Refactoring in a large code base Rustom Mody <rustompmody@gmail.com> - 2016-01-22 05:30 -0800
                      Re: Refactoring in a large code base Marko Rauhamaa <marko@pacujo.net> - 2016-01-22 15:43 +0200
                        Re: Refactoring in a large code base Rustom Mody <rustompmody@gmail.com> - 2016-01-22 05:58 -0800
                      Re: Refactoring in a large code base Chris Angelico <rosuav@gmail.com> - 2016-01-23 01:08 +1100
              Re: Refactoring in a large code base "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2016-01-22 11:45 +0000

Page 1 of 2  [1] 2  Next page →

#101963 — importing: what does "from" do?

What does "from (module) import (func)" do?

Please don't tell me that I shouldn't ask because real programmers
know not to have circular dependencies ...

I have no idea what was imported before.  I just want to import hexdump().
Unfortunately, this does not work:

  from utilities import hexdump

    ImportError: cannot import name hexdump

Now, I shouldn't have a problem because the programmers before me didn't
understand either, and so just duplicated it everywhere, but I'd really
like to do it right.

I would have thought that "from" would allow me to import just one
symbol.  Now, for all the people just chomping at the bit to tell
me about circular dependencies, would you explain to me why I get this:

  (PDB)hexdump(msg)
*** NameError: name 'hexdump' is not defined


P.S. can I get a list of all the loaded symbols and/or modules?

[toc] | [next] | [standalone]

#101969

On Jan 21, 2016 7:31 AM, "Charles T. Smith" <cts.private.yahoo@gmail.com>
wrote:
>
> What does "from (module) import (func)" do?

Approximately equivalent to:

import module
func = module.func

Except that it doesn't bind "module" to anything.

> Please don't tell me that I shouldn't ask because real programmers
> know not to have circular dependencies ...
>
> I have no idea what was imported before.  I just want to import hexdump().
> Unfortunately, this does not work:
>
>   from utilities import hexdump
>
>     ImportError: cannot import name hexdump

What is utilities? Is it a module on your sys.path?

> Now, I shouldn't have a problem because the programmers before me didn't
> understand either, and so just duplicated it everywhere, but I'd really
> like to do it right.
>
> I would have thought that "from" would allow me to import just one
> symbol.  Now, for all the people just chomping at the bit to tell
> me about circular dependencies

What makes you think this is caused by circular dependencies? It could be,
but you really haven't given us enough information about what utilities is
to diagnose that.

> would you explain to me why I get this:
>
>   (PDB)hexdump(msg)
> *** NameError: name 'hexdump' is not defined

Probably because the name 'hexdump' is not defined.

> P.S. can I get a list of all the loaded symbols and/or modules?

What do you mean by "loaded"? Bound to a name in the main module? In the
globals of the current scope? In any module? Try the "dir" or "vars"
built-in.

You can get a view of all the *cached* modules by looking in the
sys.modules dict.

[toc] | [prev] | [next] | [standalone]

#101970

On Thu, 21 Jan 2016 07:52:17 -0700, Ian Kelly wrote:

>> I have no idea what was imported before.  I just want to import
>> hexdump(). Unfortunately, this does not work:
>>
>>   from utilities import hexdump
>>
>>     ImportError: cannot import name hexdump
> 
> What is utilities? Is it a module on your sys.path?


Yes.


> What makes you think this is caused by circular dependencies? It could
> be, but you really haven't given us enough information about what
> utilities is to diagnose that.


Well, I thought that that's what causes these import problems.  I just
wish that python gave me more information, like the tree of imports that's
causing the problem.



>> would you explain to me why I get this:
>>
>>   (PDB)hexdump(msg)
>> *** NameError: name 'hexdump' is not defined
> 
> Probably because the name 'hexdump' is not defined.


If indeed it's not defined, then I wouldn't think there'd be a
problem importing the module that defines it.


>> P.S. can I get a list of all the loaded symbols and/or modules?
> 
> What do you mean by "loaded"? Bound to a name in the main module? In the
> globals of the current scope? In any module? Try the "dir" or "vars"
> built-in.
> 
> You can get a view of all the *cached* modules by looking in the
> sys.modules dict.


as in this?

  (PDB) pp dict (sys.modules)

Okay, quite good.  I have this (among others):


 'hexdump': <module 'hexdump' from '/home/user/hexdump.pyc'>,
 'int.hexdump': None,


But I suspect the first, at any rate, was loaded because of this in
my ~/.pdbrc:

  from hexdump import hexdump

which wouldn't interfere when running without the debugger (that module
in my sys.path but nowhere near my project)


I have this in my project:

  int/__init__.py

But:

  $ ls int/hexdump*
  ls: cannot access int/hexdump*: No such file or directory

So I don't really understand "int.hexdump".
I have these function definitions:

  codec/objects.py:47:def hexdump (s, l = None):
  int/struct_phy.py:26:def hexdump (s, l = None):

both in modules.

It fails to load:

  from struct_phy import hexdump

or:

    from int.struct_phy import hexdump
ImportError: cannot import name hexdump

[toc] | [prev] | [next] | [standalone]

#101979

On Thu, Jan 21, 2016 at 8:12 AM, Charles T. Smith
<cts.private.yahoo@gmail.com> wrote:
>>> would you explain to me why I get this:
>>>
>>>   (PDB)hexdump(msg)
>>> *** NameError: name 'hexdump' is not defined
>>
>> Probably because the name 'hexdump' is not defined.
>
>
> If indeed it's not defined, then I wouldn't think there'd be a
> problem importing the module that defines it.

What happens if you just do 'import utilities'. Can you then call
utilities.hexdump? Can you see anything in the utilities module?

>  'hexdump': <module 'hexdump' from '/home/user/hexdump.pyc'>,
>  'int.hexdump': None,
>
>
> But I suspect the first, at any rate, was loaded because of this in
> my ~/.pdbrc:
>
>   from hexdump import hexdump
>
> which wouldn't interfere when running without the debugger (that module
> in my sys.path but nowhere near my project)
>
>
> I have this in my project:
>
>   int/__init__.py
>
> But:
>
>   $ ls int/hexdump*
>   ls: cannot access int/hexdump*: No such file or directory
>
> So I don't really understand "int.hexdump".

The value of None in sys.modules caches a relative import miss. All it
means is that at some point something in the 'int' package tried to do
a relative import of the hexdump module and failed (presumably because
it doesn't exist).

Side observation: 'int' is a bad name for a package, because it will
shadow the name of the 'int' built-in.

[toc] | [prev] | [next] | [standalone]

#101982

On Thu, 21 Jan 2016 08:59:39 -0700, Ian Kelly wrote:

> What happens if you just do 'import utilities'. Can you then call
> utilities.hexdump? Can you see anything in the utilities module?


Yes, that works!  That's what I'm doing as a work around.
I was trying to avoid doing that because I figured it would exponentiate
my circular dependency problems and in fact, that module has no place
in the module where I need hexdump.

The obvious suggestion is to put hexdump in a file by itself, but
that's not the point, now.  The point is, how to optimally manage
(existing) complex imports.


> Side observation: 'int' is a bad name for a package, because it will
> shadow the name of the 'int' built-in.


Boy oh boy have I experienced that now!  :)

[toc] | [prev] | [next] | [standalone]

#101983

On Thu, 21 Jan 2016 16:30:30 +0000, Charles T. Smith wrote:

>> Side observation: 'int' is a bad name for a package, because it will
>> shadow the name of the 'int' built-in.
> 
> 
> Boy oh boy have I experienced that now!  :)

(it wasn't me! ;) )

[toc] | [prev] | [next] | [standalone]

#101980

On Fri, 22 Jan 2016 02:12 am, Charles T. Smith wrote:

> On Thu, 21 Jan 2016 07:52:17 -0700, Ian Kelly wrote:
> 
>>> I have no idea what was imported before.  I just want to import
>>> hexdump(). Unfortunately, this does not work:
>>>
>>>   from utilities import hexdump
>>>
>>>     ImportError: cannot import name hexdump

Charles, according to your comments further below, you have already imported
successfully hexdump using:

from hexdump import hexdump


So why not just run that instead?



>> What is utilities? Is it a module on your sys.path?
> 
> 
> Yes.

Does utilities.py contain a function, class or other object
called "hexdump"?


(1) At the interactive interpreter, run:

import utilities
dir(utilities)

Do you see a name "hexdump" listed there? (My guess is, No.)


(2) In your text editor of choice, open the utilities.py file, and search
for "hexdump". Do you see anything by that name? (My guess is No.)


If the answer to either of those questions is Yes, then:

(3) You may be looking at a different file called "utilities.py". Is it
possible that you have two such files, and that you are looking at one, and
Python has picked up the other?

(4) Or possibly you have imported utilities into Python, THEN edited the
file and added hexdump to the file. If so, Python will not see the changes
to the file until you exit the interpreter and restart it.

(You may be able to use the reload() function to see the changes, but it is
sometimes finicky to get that to work the way people expect, it is often
better just to exit and restart.)


>> What makes you think this is caused by circular dependencies? It could
>> be, but you really haven't given us enough information about what
>> utilities is to diagnose that.
> 
> Well, I thought that that's what causes these import problems.


Circular dependencies cause SOME import problems, but not all.


> I just 
> wish that python gave me more information, like the tree of imports that's
> causing the problem.

What do you mean by "the tree of imports"? I don't even know what you might
mean by that.



>>> would you explain to me why I get this:
>>>
>>>   (PDB)hexdump(msg)
>>> *** NameError: name 'hexdump' is not defined
>> 
>> Probably because the name 'hexdump' is not defined.
> 
> 
> If indeed it's not defined, then I wouldn't think there'd be a
> problem importing the module that defines it.


I don't understand this. If hexdump isn't defined, how do you expect to
import something that doesn't exist? Or exists in a place that the
interpreter cannot see, which is effectively the same thing.



>>> P.S. can I get a list of all the loaded symbols and/or modules?

In Python 2, run this:


import __builtin__
names = vars(__builtin__).keys()
names.extend(vars().keys())
print sorted(names)


In Python 3, run this:


import builtins
names = list(vars(builtins).keys())
names.extend(vars().keys())
print(sorted(names))


To see the list of modules which have been loaded from disk and stored in
the cache (but not necessarily imported into your program), run this:

import sys
print(sys.modules)



>> What do you mean by "loaded"? Bound to a name in the main module? In the
>> globals of the current scope? In any module? Try the "dir" or "vars"
>> built-in.
>> 
>> You can get a view of all the *cached* modules by looking in the
>> sys.modules dict.
> 
> 
> as in this?
> 
>   (PDB) pp dict (sys.modules)


Charles, I **strongly** suggest that for day to day interactive exploration
of the Python environment, instead of using the debugger, you use the
ordinary (and quite powerful) Python interactive interpreter. 

At the Python prompt, just type the code you want to execute, and it will be
executed interactively.

(The one major difference between the interactive interpreter and the
non-interactive one is that the interactive interpreter is quite fussy
about blank lines between blocks. For example, you need to leave a blank
line after a function when defining it:


py> def foo():
...     return 42
... x = foo()  # oops, forgot the blank line
  File "<stdin>", line 3
    x = foo()  # oops, forgot the blank line
    ^
SyntaxError: invalid syntax



and you cannot leave blank lines in the middle of a block:


py> def foo():
...     a = 42
...
py>     return a  # oops, the blank line has ended the block
  File "<stdin>", line 1
    return a  # oops, the blank line has ended the block
    ^
IndentationError: unexpected indent




> Okay, quite good.  I have this (among others):
> 
> 
>  'hexdump': <module 'hexdump' from '/home/user/hexdump.pyc'>,
>  'int.hexdump': None,

I'm confused. You have a file hexdump, another file utilities.py containing
hexdump, and now it seems you also have a package directory "int"
containing a file called "hexadump".

How do you expect to keep track of which hexdump you are using?

Also, your package "int" is going to clash with the built-in function "int".
You should rename the package.



> But I suspect the first, at any rate, was loaded because of this in
> my ~/.pdbrc:
> 
>   from hexdump import hexdump
> 
> which wouldn't interfere when running without the debugger (that module
> in my sys.path but nowhere near my project)

If it is in sys.path, then it is available to your project.



> I have this in my project:
> 
>   int/__init__.py
> 
> But:
> 
>   $ ls int/hexdump*
>   ls: cannot access int/hexdump*: No such file or directory
> 
> So I don't really understand "int.hexdump".

You can't just import functions from any random place. You can only import
them from where they actually exist.

from math import path  # fails, because there is no math.path

from os import path  # succeeds, because os.path does exist


You can't import int.hexdump if you haven't written a file int/hexdump.py.



> I have these function definitions:
> 
>   codec/objects.py:47:def hexdump (s, l = None):
>   int/struct_phy.py:26:def hexdump (s, l = None):
> 
> both in modules.
> 
> It fails to load:
> 
>   from struct_phy import hexdump
> 
> or:
> 
>     from int.struct_phy import hexdump
> ImportError: cannot import name hexdump


At this point, I'm so confused by your setup that I'm about to give up and
go to bed. 



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#101971

In <n7qpel$a3j$1@dont-email.me> "Charles T. Smith" <cts.private.yahoo@gmail.com> writes:

>   from utilities import hexdump

>     ImportError: cannot import name hexdump

The most likely explanation here is that the 'utilities' module simply
does not contain something named 'hexdump'.

Have you inspected the 'utilities' module?  Does it, in fact, contain
something named 'hexdump'?

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#101972

On Thu, 21 Jan 2016 15:31:45 +0000, John Gordon wrote:


> The most likely explanation here is that the 'utilities' module simply
> does not contain something named 'hexdump'.
> 
> Have you inspected the 'utilities' module?  Does it, in fact, contain
> something named 'hexdump'?

Yes

[toc] | [prev] | [next] | [standalone]

#101973

In <n7qu0c$a3j$3@dont-email.me> "Charles T. Smith" <cts.private.yahoo@gmail.com> writes:

> > The most likely explanation here is that the 'utilities' module simply
> > does not contain something named 'hexdump'.
> > 
> > Have you inspected the 'utilities' module?  Does it, in fact, contain
> > something named 'hexdump'?

> Yes

In that case, the problem is most likely a circular import issue, as you
mentioned.  The only way to fix it is to reorganize your modules.

How did this error come up?  Did the code work previously?  If so, what
changed?

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#101974

On Thu, 21 Jan 2016 15:44:43 +0000, John Gordon wrote:


> How did this error come up?  Did the code work previously?  If so, what
> changed?

The developers of this legacy code had this as well as other functions
duplicated throughout the system, in order to avoid confronting these
issues.  I'm trying to untangle the mess - without rewriting thousands
of lines of application code.

[toc] | [prev] | [next] | [standalone]

#101978

In <n7qugv$a3j$4@dont-email.me> "Charles T. Smith" <cts.private.yahoo@gmail.com> writes:

> > How did this error come up?  Did the code work previously?  If so, what
> > changed?

> The developers of this legacy code had this as well as other functions
> duplicated throughout the system, in order to avoid confronting these
> issues.

Yes, but did the code work previously?  If so, what changed?

> I'm trying to untangle the mess - without rewriting thousands of lines
> of application code.

At worst you'd have to move some things into a new module, and change the
statements that import those things.  You shouldn't have to rewrite any of
the actual code.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#101977

On Thu, 21 Jan 2016 15:44:43 +0000, John Gordon wrote:

> In that case, the problem is most likely a circular import issue, as you
> mentioned.  The only way to fix it is to reorganize your modules.
> 
> How did this error come up?  Did the code work previously?  If so, what
> changed?


What I need is tools to find the problems.  In particular, why doesn't
python give me more of a clue where the problem is?  It would be cool
if it would tell me exactly what module to look at, which symbol(s)
were colliding.

The suggestion of using
pp dict (sys.modules)
might be useful, I need to study it in more detail.

[toc] | [prev] | [next] | [standalone]

#101981

On Fri, 22 Jan 2016 02:53 am, Charles T. Smith wrote:

> What I need is tools to find the problems.  In particular, why doesn't
> python give me more of a clue where the problem is?  It would be cool
> if it would tell me exactly what module to look at, which symbol(s)
> were colliding.

The problem isn't that symbols are colliding, it is that you are looking for
symbols that *don't exist* in the place you tell Python to look.


If you run 

from math import hexdump

you will get an ImportError, not because of a collision, but because there
is no math.hexdump. 

If you run

from utilities import hexdump

and Python gives you an ImportError, the most likely issue is that there is
no such name "hexdump" in that file.

Are you sure you are looking at the same file? What does this tell you?


import utilities
print(utilities.__file__)


Does it match what you expect?




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#101994

On Thursday, January 21, 2016 at 7:53:07 PM UTC+5:30, Charles T. Smith wrote:
> What does "from (module) import (func)" do?
> 
> Please don't tell me that I shouldn't ask because real programmers
> know not to have circular dependencies ...
> 
> I have no idea what was imported before.  I just want to import hexdump().
> Unfortunately, this does not work:
> 
>   from utilities import hexdump
> 
>     ImportError: cannot import name hexdump
> 
> Now, I shouldn't have a problem because the programmers before me didn't
> understand either, and so just duplicated it everywhere, but I'd really
> like to do it right.
> 
> I would have thought that "from" would allow me to import just one
> symbol.  Now, for all the people just chomping at the bit to tell
> me about circular dependencies, would you explain to me why I get this:
> 
>   (PDB)hexdump(msg)
> *** NameError: name 'hexdump' is not defined
> 
> 
> P.S. can I get a list of all the loaded symbols and/or modules?

You may find this strategy useful:
https://pchiusano.github.io/2015-04-23/unison-update7.html

particularly the section "Limitations of refactoring via modifying text files in place, and what to do instead"

Note it is not python based but the explanation should be useful anyway

[toc] | [prev] | [next] | [standalone]

#101995 — Refactoring in a large code base (was: importing: what does "from" do?)

Rustom Mody <rustompmody@gmail.com> writes:

> You may find this strategy useful:
> https://pchiusano.github.io/2015-04-23/unison-update7.html
>
> particularly the section "Limitations of refactoring via modifying
> text files in place, and what to do instead"

A direct link to that section is
<URL:https://pchiusano.github.io/2015-04-23/unison-update7.html#refactoring-lessons>.

The author points out there are times when a code base is large and
complex enough that refactoring puts the programmer in a state of not
knowing whether they're making progress, because until the whole
refactoring is complete the errors just cascade and it's hard to tell
which ones are relevant.

    That’s bad for two reasons. Without this feedback, you may be
    writing code that is making things worse, not better, building
    further on faulty assumptions. But more than the technical
    difficulties, working in this state is demoralizing, and it kills
    focus and productivity.

    All right, so what do we do instead? Should we just avoid even
    considering any codebase transformations that are intractable with
    the “edit and fix errors” approach? No, that’s too conservative.
    Instead, we just have to *avoid modifying our program in place*.
    This lets us make absolutely any codebase transformation while
    keeping the codebase compiling at all times. Here’s a procedure,
    it’s quite simple […]

    <URL:https://pchiusano.github.io/2015-04-23/unison-update7.html#refactoring-lessons>

The technique is not presented as flawless, and interesting trade-offs
are discussed. Quite an interesting article.

-- 
 \       “Science and religion are incompatible in the same sense that |
  `\       the serious pursuit of knowledge of reality is incompatible |
_o__)                       with bullshit.” —Paul Z. Myers, 2010-03-14 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#101996 — Re: Refactoring in a large code base

Ben Finney <ben+python@benfinney.id.au>:

> The author points out there are times when a code base is large and
> complex enough that refactoring puts the programmer in a state of not
> knowing whether they're making progress, because until the whole
> refactoring is complete the errors just cascade and it's hard to tell
> which ones are relevant.

I've been there. I think the root problem is to have a code base that's
so large and complex.

It *could* be avoided if the engineering director only cared.


Marko

[toc] | [prev] | [next] | [standalone]

#101997 — Re: Refactoring in a large code base

On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :
> 
> > The author points out there are times when a code base is large and
> > complex enough that refactoring puts the programmer in a state of not
> > knowing whether they're making progress, because until the whole
> > refactoring is complete the errors just cascade and it's hard to tell
> > which ones are relevant.
> 
> I've been there. I think the root problem is to have a code base that's
> so large and complex.

Bizarre comment... Are you saying large and complex code-bases should non-exist?

> 
> It *could* be avoided if the engineering director only cared.

Some problems are trivially solvable... for those who have the knowhow
Some problems are inherently hard but easily detectable as such... once again for those who have the knowhow
And some are literally (and ironically trivially) unsolvable

The CS-trinity: 'normal' problems, problems in NP, undecidable problems is a classic example of this.
However applying that in real-world practice can be highly non-trivial,
requiring from specialized knowledge to intelligence to genius.

IOW "engineering director does not care" is likely true but also a gross oversimplification

[toc] | [prev] | [next] | [standalone]

#101998 — Re: Refactoring in a large code base

Rustom Mody <rustompmody@gmail.com>:

> On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
>> I've been there. I think the root problem is to have a code base
>> that's so large and complex.
>
> Bizarre comment... Are you saying large and complex code-bases should
> non-exist?

Why, yes, I am.

>> It *could* be avoided if the engineering director only cared.
>
> Some problems are trivially solvable... for those who have the knowhow
> Some problems are inherently hard but easily detectable as such...
> once again for those who have the knowhow And some are literally (and
> ironically trivially) unsolvable

The knowhow, vision and skill is apparently very rare. On the product
management side, we have the famous case of Steve Jobs, who simply told
the engineers to go back to the drawing boards when he didn't like the
user experience. Most others would have simply surrendered to the
mediocre designs and shipped the product.

We need similar code sanity management. Developers are given much too
much power to mess up the source code. That's why "legacy" is considered
a four-letter word among developers.


Marko

[toc] | [prev] | [next] | [standalone]

#102000 — Re: Refactoring in a large code base

On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> The knowhow, vision and skill is apparently very rare. On the product
> management side, we have the famous case of Steve Jobs, who simply told
> the engineers to go back to the drawing boards when he didn't like the
> user experience. Most others would have simply surrendered to the
> mediocre designs and shipped the product.
>
> We need similar code sanity management. Developers are given much too
> much power to mess up the source code. That's why "legacy" is considered
> a four-letter word among developers.

So what do you do with a huge program? Do you send it back to the
developers and say "Do this is less lines of code"?

CPython is a large and complex program. How do you propose doing it "right"?

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web