> 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
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 pyth
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
to rewrite some code to be compliant with Pythons as o
On Wed, Oct 8, 2008 at 9:14 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> The documentation for the ast module states that it "helps to find out
>> programmatically what the current grammar looks like". I can't find
>> any reference (even when reading the code) on how you should go about
>> t
> My confusion starts with the fact that I'm not sure if all Python 2.4
> code is going to be syntactically valid 2.6 code.
That's not so much a matter of confusion, but of careful research.
I *think* all code that is syntactically correct in 2.4 is also
syntactically correct in 2.6 - but only be
> The documentation for the ast module states that it "helps to find out
> programmatically what the current grammar looks like". I can't find
> any reference (even when reading the code) on how you should go about
> this, other than checking the sys.version number and reading up on the
> changes.
Orestis Markou wrote:
On Tue, Oct 7, 2008 at 5:39 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
Orestis Markou wrote:
Hello,
I'm the developer of PySmell ( http://github.com/orestis/pysmell ), a
static analysis/intellisense provider for Python. I am targeting
Python 2.4 code so I'm using the comp
On Tue, Oct 7, 2008 at 5:39 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Orestis Markou wrote:
>>
>> Hello,
>>
>> I'm the developer of PySmell ( http://github.com/orestis/pysmell ), a
>> static analysis/intellisense provider for Python. I am targeting
>> Python 2.4 code so I'm using the compiler pa
Orestis Markou wrote:
Hello,
I'm the developer of PySmell ( http://github.com/orestis/pysmell ), a
static analysis/intellisense provider for Python. I am targeting
Python 2.4 code so I'm using the compiler package.
I've been toying around yesterday with the ast module in Python 2.6
and it seems
Hello,
I'm the developer of PySmell ( http://github.com/orestis/pysmell ), a
static analysis/intellisense provider for Python. I am targeting
Python 2.4 code so I'm using the compiler package.
I've been toying around yesterday with the ast module in Python 2.6
and it seems much more cleaner. One
"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
>
;t be available in 2.0 any more than
> iter would. "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 o
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
;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". The tests here
are not 100% reli
ns of Python?
>
>
> python 2.1 doesn't support iterators, so that question doesn't
> make much sense.
The _question_ doesn't make much sense? I could
understand you saying that backwards-compatibility is
"not important [to me]" but to say that the very
que
18 matches
Mail list logo
