Relative-importing *

[Steve Holden]

rbygscrsepda at gmail.com wrote:
> On Aug 6, 12:19 am, Ben Finney <bignose+hates-s... at benfinney.id.au>
> wrote:
>> rbysam... at gmail.com 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 -------------