On Fri, Feb 23, 2001 at 06:30:32PM -0500, Jeremy Hylton wrote: > >>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes: > TW> On Fri, Feb 23, 2001 at 06:00:59PM -0500, Jeremy Hylton wrote: > >> Hmmmm... I'm not yet sure how to deduce indent level 0 inside > >> the parser. > TW> Uhm, why are we adding that restriction anyway, if it's hard for > TW> the parser/compiler to detect it ? I think I'd like to put them > TW> in try/except or if/else clauses, for fully portable code. > If it were allowed inside an if/else statement, the compiler, it would > become something more like a runtime flag. It sounds like you want the > feature to be enabled only if the import is actually executed. But that > can't work for compile-time directives, because the code has got to be > compiled before we find out if the statement is executed. Right, I don't really want them in if/else blocks, you're right. Try/except would be nice, though. > TW> While > TW> on the subject, a way to distinguish between '__future__ not > TW> found' and '__future__.feature not found', other than hardcoding > TW> the minimal version might be nice. > There will definitely be a difference! > Presumably all versions of Python after and including 2.1 will know > about __future__. In those cases, the compiler will complain if > feature is no defined. The complaint can be fairly specific: > "__future__ feature curly_braces is not defined." Will this be a warning, or an error/exception ? Must-stop-working-sleep-is-calling-ly y'rs, ;) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4