> subpackage1 imports the exceptions module from package1, and I do that
> like
> > this:
> >
> > from ..exceptions import MyException
> >
>
> You'll have to import that using the absolute import. It would be
> "from package1.exceptions import MyException".
>
Ah; I didn't quite see how something i
On 2/26/2011 11:32 AM, Benjamin Kaplan wrote:
On Sat, Feb 26, 2011 at 8:11 AM, Jason Swails wrote:
Hello,
I have a question I was having a difficult time finding with a quick google
search, so I figured someone on here might know. For the sake of backwards
compatibility (and supporting system
On Sat, Feb 26, 2011 at 8:11 AM, Jason Swails wrote:
> Hello,
>
> I have a question I was having a difficult time finding with a quick google
> search, so I figured someone on here might know. For the sake of backwards
> compatibility (and supporting systems whose default python is OLD), I'd like
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> I've said it many times, and I'll say it again: the only fundamentally
> new concept that has been added since Python 1.5.2 is generators.
> [...]
> All the rest is just coloured frosting
In my mind, the biggest thing since 1.5.2 is string methods. T
Tom Anderson wrote:
> How about detecting which environment you're in, then running one of two
> entirely different sets of code? Rather than trying to construct modern
> features in the antique environment, write code for each, using the local
> idioms. The trouble with this is that you end up wi
On Tue, 22 Nov 2005, Steven D'Aprano wrote:
> Are there practical idioms for solving the metaproblem "solve problem X
> using the latest features where available, otherwise fall back on older,
> less powerful features"?
>
> For instance, perhaps I might do this:
>
> try:
>built_in_feature
>
Alex Martelli wrote:
> > In the specific case of iter(), are there good
> > alternative ways of detecting an iterable without
> > consuming it?
>
> Not a problem I've had often, but when I did, if I recall correctly, I
> did something like:
>
> try:
> iter
> except NameError:
> def isiterable(
Alex Martelli wrote:
> "Consuming" didn't really come into consideration for the
> backwards compatibility part because only objects indexable with
> integers, 0 and up (and raising IndexError at some point) were usable in
> for statements in old Pythons, there was no "consuming".
Ah yes, of cour
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
...
> In the specific case of iter(), are there good
> alternative ways of detecting an iterable without
> consuming it?
Not a problem I've had often, but when I did, if I recall correctly, I
did something like:
try:
iter
except NameError:
def i
