On 21Jun2011 20:04, I wrote:
| So the caller does an:
|
| import foo
|
| as normal, with no special wrapping. And the module goes:
|
| spam()
| if condition:
| raise StopIteration
| ham()
| cheese()
Of course, that should be StopImport, not StopIteration.
Cheers,
--
Cameron Simp
On 18Jun2011 03:50, Steven D'Aprano
wrote:
| On Sat, 18 Jun 2011 12:36:42 +1000, Cameron Simpson wrote:
| > Just to throw another approach into the mix (because I was thinking
| > about the "finally" word), what about:
| >
| > raise StopImport
| >
| > along the lines of generators' "raise Sto
On Sat, Jun 18, 2011 at 2:49 PM, Steven D'Aprano
wrote:
> Not quite. In my config language, "ignored" means ignored. There was no
> way of accessing the rest of the file, short of guessing the file name,
> opening it and reading it as text.
>
> In Perl, the __END__ and __DATA__ keywords mark the e
On Sat, 18 Jun 2011 14:31:51 +1000, Chris Angelico wrote:
> On Sat, Jun 18, 2011 at 1:50 PM, Steven D'Aprano
> wrote:
>> I don't think the use-case for this is convincing enough to need it,
>> but it's an interesting concept. I once played around with a
>> mini-language for config files that incl
On Sat, Jun 18, 2011 at 1:50 PM, Steven D'Aprano
wrote:
> I don't think the use-case for this is convincing enough to need it, but
> it's an interesting concept. I once played around with a mini-language
> for config files that included a "STOP" command, so that:
>
> key = value
> STOP
> everythin
On Sat, 18 Jun 2011 12:36:42 +1000, Cameron Simpson wrote:
> On 17Jun2011 06:00, Steven D'Aprano
> wrote: | If we were to have a
> "exit this module early, but without exiting Python | altogether"
> statement, I'd consider "exit" to be the most descriptive | name,
> although it would clash with e
On 17Jun2011 06:00, Steven D'Aprano
wrote:
| If we were to have a "exit this module early, but without exiting Python
| altogether" statement, I'd consider "exit" to be the most descriptive
| name, although it would clash with existing uses of the word, e.g.
| sys.exit(). Overloading "break" s
Steven D'Aprano wrote:
On Thu, 16 Jun 2011 22:20:50 -0700, Erik Max Francis wrote:
[...]
Yes, which could be rephrased as the fact that `break` and `continue`
are restricted to looping control structures, so reusing `break` in this
context would be a bad idea. You know, kind of like the exact
On Thu, Jun 16, 2011 at 11:56 PM, Chris Angelico wrote:
> On Fri, Jun 17, 2011 at 3:20 PM, Erik Max Francis wrote:
>> Yes, which could be rephrased as the fact that `break` and `continue` are
>> restricted to looping control structures, so reusing `break` in this context
>> would be a bad idea.
>
On Thu, 16 Jun 2011 22:20:50 -0700, Erik Max Francis wrote:
[...]
> Yes, which could be rephrased as the fact that `break` and `continue`
> are restricted to looping control structures, so reusing `break` in this
> context would be a bad idea. You know, kind of like the exact point I
> made earli
On Fri, Jun 17, 2011 at 3:20 PM, Erik Max Francis wrote:
> Yes, which could be rephrased as the fact that `break` and `continue` are
> restricted to looping control structures, so reusing `break` in this context
> would be a bad idea.
Which is why I believe 'return' would be a better choice, even
Ian Kelly wrote:
On Thu, Jun 16, 2011 at 10:24 PM, Erik Max Francis wrote:
True. So let's use `in` to represent breaking out of the top-level code of
a module. Why not, it's not the first time a keyword has been reused,
right?
The point is, if it's not obvious already from that facetious pro
On Thu, Jun 16, 2011 at 10:21 PM, Erik Max Francis wrote:
> Ethan Furman wrote:
>>
>> The Context:
>>
>> "It's quite consistent on which control structures you can break out of"
>>
>> Hmmm Nope, nothing there to suggest you were talking about the 'break'
>> keyword.
>
> That's what I wrote, al
On Thu, Jun 16, 2011 at 10:24 PM, Erik Max Francis wrote:
> True. So let's use `in` to represent breaking out of the top-level code of
> a module. Why not, it's not the first time a keyword has been reused,
> right?
>
> The point is, if it's not obvious already from that facetious proposal, it's
Ian Kelly wrote:
On Thu, Jun 16, 2011 at 7:21 PM, Erik Max Francis wrote:
Neither makes sense. `break` exits out of looping structures, which the
top-level code of a module most certainly is not.
Why does that matter? It seems a bit like arguing that the `in`
keyword can't be used for membe
Ethan Furman wrote:
The Context:
"It's quite consistent on which control structures you can break out of"
Hmmm Nope, nothing there to suggest you were talking about the
'break' keyword.
That's what I wrote, all right, but not its context. I suspect you're
just being difficult.
--
Eri
Erik Max Francis wrote:
Chris Angelico wrote:
On Fri, Jun 17, 2011 at 9:29 AM, Erik Max Francis
wrote:
Chris Angelico wrote:
On Fri, Jun 17, 2011 at 8:07 AM, Erik Max Francis
wrote:
It's quite consistent on which control structures you can break out
of --
it's the looping ones.
Plus funct
On Thu, Jun 16, 2011 at 7:21 PM, Erik Max Francis wrote:
>> This would, if I understand imports correctly, have ham() operate in
>> one namespace and spam() in another. Depending on what's being done,
>> that could be quite harmless, or it could be annoying (no sharing
>> module-level constants, e
Erik Max Francis wrote:
Chris Angelico wrote:
On Fri, Jun 17, 2011 at 10:48 AM, Steven D'Aprano
wrote:
Perhaps the most sensible alternative is conditional importing:
# === module extras.py ===
def ham(): pass
def cheese(): pass
def salad(): pass
# === module other.py ===
def spam(): pass
Chris Angelico wrote:
On Fri, Jun 17, 2011 at 10:48 AM, Steven D'Aprano
wrote:
Perhaps the most sensible alternative is conditional importing:
# === module extras.py ===
def ham(): pass
def cheese(): pass
def salad(): pass
# === module other.py ===
def spam(): pass
if not some_condition:
Chris Angelico wrote:
On Fri, Jun 17, 2011 at 9:29 AM, Erik Max Francis wrote:
Chris Angelico wrote:
On Fri, Jun 17, 2011 at 8:07 AM, Erik Max Francis wrote:
It's quite consistent on which control structures you can break out of --
it's the looping ones.
Plus functions.
No:
def f():
...
On Fri, Jun 17, 2011 at 10:48 AM, Steven D'Aprano
wrote:
> Perhaps the most sensible alternative is conditional importing:
>
> # === module extras.py ===
>
> def ham(): pass
> def cheese(): pass
> def salad(): pass
>
>
> # === module other.py ===
>
> def spam(): pass
>
> if not some_condition: fro
On Thu, 16 Jun 2011 15:07:23 -0700, Erik Max Francis wrote:
> Eric Snow wrote:
>>
>> The only ways that I know of to accomplish this currently is either by
>> putting everything inside if-else blocks, or raise some kind of
>> ImportBreak exception and catch it in an import hook.
>
> You're still
On Fri, Jun 17, 2011 at 9:29 AM, Erik Max Francis wrote:
> Chris Angelico wrote:
>>
>> On Fri, Jun 17, 2011 at 8:07 AM, Erik Max Francis wrote:
>>>
>>> It's quite consistent on which control structures you can break out of --
>>> it's the looping ones.
>>
>> Plus functions.
>
> No:
>
def f()
On Thu, Jun 16, 2011 at 5:29 PM, Erik Max Francis wrote:
> Chris Angelico wrote:
>>
>> On Fri, Jun 17, 2011 at 8:07 AM, Erik Max Francis wrote:
>>>
>>> It's quite consistent on which control structures you can break out of --
>>> it's the looping ones.
>>
>> Plus functions.
>
> No:
>
def f()
On Tue, Jun 14, 2011 at 4:57 PM, MRAB wrote:
> To me, the obvious choice would be "return", not "break".
No, "return" returns a value. Modules do not return values.
Therefore "return" would be inappropriate. If this feature were
deemed desirable, "break" would make more sense to me.
--
http://
Chris Angelico wrote:
On Fri, Jun 17, 2011 at 8:07 AM, Erik Max Francis wrote:
It's quite consistent on which control structures you can break out of --
it's the looping ones.
Plus functions.
No:
>>> def f():
... break
...
File "", line 2
SyntaxError: 'break' outside loop
--
Erik Max F
On Fri, Jun 17, 2011 at 8:07 AM, Erik Max Francis wrote:
> It's quite consistent on which control structures you can break out of --
> it's the looping ones.
Plus functions.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Eric Snow wrote:
Like I said, my main motivation is to reduce my levels of indentation
somewhat. I was trying to see if I could apply a pattern I use in
functions and loops to modules.
If your sole goal here is to reduce clutter, then turn a repeated
if/elif/else case into a dictionary lookup
Eric Snow wrote:
On Tue, Jun 14, 2011 at 5:51 PM, Erik Max Francis wrote:
Ethan Furman wrote:
To me, too -- too bad it doesn't work:
c:\temp>\python32\python early_abort.py
File "early_abort.py", line 7
return
^
SyntaxError: 'return' outside function
Nor should it. There's nothing
On 01/-10/-28163 02:59 PM, Eric Snow wrote:
Unfortunately not. Most of this line of thinking is the result of
looking at import functionality in different ways, including with
regards to the problem of modules getting imported twice (once as
__main__). I've been doing work on multi-file modul
On 14Jun2011 18:51, Eric Snow wrote:
| On Tue, Jun 14, 2011 at 5:51 PM, Erik Max Francis wrote:
| > Ethan Furman wrote:
| >>
| >> To me, too -- too bad it doesn't work:
| >>
| >> c:\temp>\python32\python early_abort.py
| >> File "early_abort.py", line 7
| >> return
| >> ^
| >> SyntaxErr
On Tue, Jun 14, 2011 at 7:33 PM, Ben Finney wrote:
>
> I have never seen code that needs this, and can't imagine why the above
> would be a good design for a module. Is there real code online somewhere
> that we can see which serves as a real example for your use case?
>
Unfortunately not. Most
Eric Snow writes:
> I apologize if my example was unclear. I kept it pretty simple.
That's a good goal, but unfortunately in this case it means the purpose
is opaque.
> In general it would be nice to do some checks up front and decide
> whether or not to continue executing the module, rather t
On Wed, Jun 15, 2011 at 10:51 AM, Eric Snow wrote:
> if condition_1:
> ...
> return
> if condition_2:
> ...
> return
>
> # now do my expensive module stuff
>
> # finally handle being run as a script
> if __name__ == "__main__":
> ...
>
The best way I can think of is:
On Tue, Jun 14, 2011 at 5:51 PM, Erik Max Francis wrote:
> Ethan Furman wrote:
>>
>> To me, too -- too bad it doesn't work:
>>
>> c:\temp>\python32\python early_abort.py
>> File "early_abort.py", line 7
>> return
>> ^
>> SyntaxError: 'return' outside function
>
> Nor should it. There's
Eric Snow writes:
> When you want to stop execution of a statement body early, for flow
> control, there is a variety ways you can go, depending on the context.
> Loops have break and continue. Functions have return. Generators
> have yield (which temporarily stops execution). Exceptions sort
Ethan Furman wrote:
MRAB wrote:
On 14/06/2011 23:28, Eric Snow wrote:
I would rather have something like this:
"""some module"""
import sys
import importlib
import util # some utility module somewhere...
if __name__ == "__main__":
name = util.get_module_name(sys.module
Eric Snow wrote:
With modules I sometimes have code at the beginning to do some small
task if a certain condition is met, and otherwise execute the rest of
the module body. Here's my main use case:
"""some module"""
import sys
import importlib
import util # some utility module somewhe
MRAB wrote:
On 14/06/2011 23:28, Eric Snow wrote:
I would rather have something like this:
"""some module"""
import sys
import importlib
import util # some utility module somewhere...
if __name__ == "__main__":
name = util.get_module_name(sys.modules[__name__])
m
On 14/06/2011 23:28, Eric Snow wrote:
[snip]
With modules I sometimes have code at the beginning to do some small
task if a certain condition is met, and otherwise execute the rest of
the module body. Here's my main use case:
"""some module"""
import sys
import importlib
import uti
When you want to stop execution of a statement body early, for flow
control, there is a variety ways you can go, depending on the context.
Loops have break and continue. Functions have return. Generators
have yield (which temporarily stops execution). Exceptions sort of
work for everything, but
42 matches
Mail list logo
