On Aug 6, 12:19 am, Ben Finney <[EMAIL PROTECTED]>
wrote:
> [EMAIL PROTECTED] writes:
> > (In addition, it probably would make the program somewhat slower to
> > have an internal class inside every module, and performance is
> > important to me, as I'm planning to use this project in a future
> > game.
>
> This is known as "premature optimisation", and it's harmful. It's
> folly to avoid a core part of the language because you're worried
> about hypothetical performance issues.
>
> Instead, write your program so that it's easy to understand and
> maintain; then, if it's noticeably slow, *measure* the performance
> using profiling so you know exactly what is slow; then, and only then,
> work on speeding up the slow parts.
>
> > These modules are not going to have full-fledged object construction
> > and so forth. I don't want to construct and use objects at all
>
> If that's truly what you desire, you're using the wrong
> language. Everything inPythonis an object, even if you don't use
> object-oriented programming.
>
> > it seems like a waste of time and memory to me to inherit __new__,
> > __del__, and so on.
>
> You've stated that you're a beginner to programming, so you probably
> are unaware that this statement has no basis in how class inheritance
> actually works. The point is that inherited behaviour is implemented
> in *one* place, not that it's repeated everywhere.
>
> Moreover, this is a further expression of your tendency for premature
> optimisation. You should aim instead to write code naturally (learning
> what's natural when you're a beginner), and only once you have
> something that *works* should you think about performance issues.
>
> > All that I want these modules to do is to encapsulate varying
> > information and behavior for /other/ objects to use.)
>
> This sounds like an ideal case for seeting up a class hierarchy for
> this move behaviour.
>
> > But regardless of if it's the "right thing to do", do you all think
> > it's an unintended bug?
>
> Do we think what is an unintended bug?
>
> I think if you go out of your way to avoid the class inheritance
> system for implementing what looks strongly like a hierarchy of
> behaviour, you will have design bugs. Hopefully now that you're
> reading this thread, they won't be *unintended* bugs; whether you
> *intentionally* proceed with a buggy design is up to you :-)
>
> --
> \ "With Lisp or Forth, a master programmer has unlimited power |
> `\ and expressiveness. WithPython, even a regular guy can reach |
> _o__) for the stars." -- Raymond Hettinger |
> Ben Finney
I understand what you're saying; thank you for the advice. :) But
unfortunately, my original question wasn't completely answered.
I wasn't asking about if my own program had a bug, in the first place.
I was asking if the error I talked about in the first post was a bug
in the Python compiler itself. It's undocumented, and so it seems
unintended--especially since importing * is a feature built in to
Python on purpose, whether or not it's easily abused or if it's
useful.
Here's the error again--whenever you try to import * from a relative
package like ., .., .sibling, ..cousin, and any other package name
starting with "*", you get an error.
Specifically, in Python 1.5, all of the following generate the error
below:
from . import *
from .sibiling_package import *
from .. import *
from ..cousin_package import *
SyntaxError: 'import *' not allowed with 'from .'
Importing * is a feature, but this seems like an artificial
inconsistency to me. It's as if the compiler raises an error when it
tries to import * as soon as it sees "from .", regardless of what
comes after it. So is this a bug in python? And if it happens to be a
bug, how can I alert the developers of the python compiler?
Again, thank you! :)
--
http://mail.python.org/mailman/listinfo/python-list
