Relative Imports, why the hell is it so hard?

CinnamonDonkey CinnamonDonkey at googlemail.com
Tue Mar 24 10:08:08 EDT 2009


Top responses guys! This has all helped increadibly.

Bearophile,

My applogies if I have offended you, but:

1. "I can't know much about you from the start" - Is kind of my point.
Perhaps it would be better to avoid jumping to conclusions and pre-
judging someones abilities simply because they are lacking knowledge
in a particular area.

Would it have been better if I had opened my thread with a copy of my
CV? I've got a Degree in Digital Systems Engineering (yes I am also an
Engineer)... I went on to do a Phd in AI and Robotics where I also
developed embedded systems. I bummed out on that after 3 years and
went on to work for a games company where I worked on 6 game titles
across 5 different platforms. I was a Lead Software Engineer for the
last 5 years. Before now moving on again.

2. I am also very much a follower of the K.I.S.S. approach, 9 times
out of 10 the simplest solution is often the best.

As an Engineer though I would also suggest that the best way to learn
is to try solving a problem being sure to constantly assess your
approach and then your final solution. By dismissing a possible avenue
you are dismissing a whole new path of knowledge. Is it not better to
try and fail than never try at all? Surely this is how we gain the
valuable experience we need.

By simply suggesting a "simple default" solution, I may never have
consider the alternatives nor understand why they are or are not
suitable.

3. I get your point about Students, sometimes there is such a thing as
too much knowledge or information overload. Whilst doing a PhD I had
to take labs and teach students... The approach I tried to take was
one off, "You may not need packages, why do you think you need
packages?" or "This is how packages would be used and why they would
be used... do you still think you need packages" or better still, for
a capable student, "This is how packages work, try solving your
problem and then tell me if you think it was a good solution."


Going with R. David Murray, perhaps I also jumped too my own
conclusion too quickly and for that I appologise.

Cheers,
Shaun





On 24 Mar, 12:37, bearophileH... at lycos.com wrote:
> CinnamonDonkey:
>
> > It is neither constructive nor educational.
>
> > It's a bit like saying "If you don't know what a function is, then
> > maybe you don't need it. ... have you tried having a single block of
> > code?"
>
> > The point of people coming to these forums is to LEARN and share
> > knowledge. Perhaps it's not the best solution for me right now but
> > without trying it I won't know when or how to apply it as a solution.
>
> > By the way, my project has about 50 files (modules) in it with a lot
> > of shared code that could be used across other projects... seems as
> > good a reason as any to try packages out ;-)
>
> I don't agree. My answer can be wrong for your situation, but I can't
> know much about you from the start, and for most people my answer was
> the right one.
>
> When a student asks me how to improve his/her usage of metaclasses I
> usually answer that metaclasses aren't required to solve that small
> problem.
>
> Generally in engineering the simplest solution is the one you have to
> try first (and often second and third), and only later, if practical
> experience shows the simple solution doesn't work, you try a more
> complex solution.
>
> So I have suggested you a simple solution by "default". If later you
> see that you have many modules and you really need packages, then it's
> easy to ignore my first answer.
>
> Bye,
> bearophile




More information about the Python-list mailing list