[EMAIL PROTECTED] wrote: > 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! :) >
Well, since the error message is quite explicit I think we can rule out any thought that the compiler is behaving in an unintended way. In other words, it's *not* a bug, but an intentional device to keep the naughty such as yourself on the straight and narrow. There is a quite explicit syntax check in ast.c precisely to exclude the possibility of "from ... import *" with relative module names, so you are going to have to live with that. It looks like the answer to a change request is going to be same as from __future__ import braces which I recommend you try ;-) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --------------- Asciimercial ------------------ Get on the web: Blog, lens and tag the Internet Many services currently offer free registration ----------- Thank You for Reading ------------- -- http://mail.python.org/mailman/listinfo/python-list
