Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #7643 > unrolled thread

Re: break in a module

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: break in a module Ethan Furman <ethan@stoneleaf.us> - 2011-06-14 16:28 -0700
    Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-14 16:51 -0700
      Re: break in a module Eric Snow <ericsnowcurrently@gmail.com> - 2011-06-14 18:51 -0600
        Re: break in a module Ben Finney <ben+python@benfinney.id.au> - 2011-06-15 11:33 +1000
          Re: break in a module Eric Snow <ericsnowcurrently@gmail.com> - 2011-06-14 20:21 -0600
            Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-16 15:09 -0700
          Re: break in a module Dave Angel <davea@ieee.org> - 2011-06-15 00:02 -0400
        Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-16 15:07 -0700
          Re: break in a module Chris Angelico <rosuav@gmail.com> - 2011-06-17 09:27 +1000
            Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-16 16:29 -0700
              Re: break in a module Eric Snow <ericsnowcurrently@gmail.com> - 2011-06-16 18:00 -0600
              Re: break in a module Chris Angelico <rosuav@gmail.com> - 2011-06-17 10:01 +1000
                Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-16 18:13 -0700
                  Re: break in a module Ethan Furman <ethan@stoneleaf.us> - 2011-06-16 19:17 -0700
                    Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-16 21:21 -0700
                      Re: break in a module Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-16 22:53 -0600
          Re: break in a module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-17 00:48 +0000
            Re: break in a module Chris Angelico <rosuav@gmail.com> - 2011-06-17 10:57 +1000
              Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-16 18:21 -0700
                Re: break in a module Ethan Furman <ethan@stoneleaf.us> - 2011-06-16 19:11 -0700
                Re: break in a module Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-16 19:58 -0600
                  Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-16 21:24 -0700
                    Re: break in a module Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-16 22:50 -0600
                      Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-16 22:20 -0700
                        Re: break in a module Chris Angelico <rosuav@gmail.com> - 2011-06-17 15:56 +1000
                        Re: break in a module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-17 06:00 +0000
                          Re: break in a module Erik Max Francis <max@alcyone.com> - 2011-06-17 00:09 -0700
                          Re: break in a module Cameron Simpson <cs@zip.com.au> - 2011-06-18 12:36 +1000
                            Re: break in a module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-18 03:50 +0000
                              Re: break in a module Chris Angelico <rosuav@gmail.com> - 2011-06-18 14:31 +1000
                                Re: break in a module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-18 04:49 +0000
                                  Re: break in a module Chris Angelico <rosuav@gmail.com> - 2011-06-18 15:06 +1000
                              Re: break in a module Cameron Simpson <cs@zip.com.au> - 2011-06-21 20:04 +1000
                        Re: break in a module Eric Snow <ericsnowcurrently@gmail.com> - 2011-06-17 00:25 -0600
      Re: break in a module Chris Angelico <rosuav@gmail.com> - 2011-06-15 11:33 +1000

Page 2 of 2 — ← Prev page 1 [2]

#7791

On Thu, Jun 16, 2011 at 7:21 PM, Erik Max Francis <max@alcyone.com> 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, etc).
>
> No, he's using `from ... import *`.  It dumps it all in the same namespace
> (which is usually why it's frowned upon, but in his example it's kind of the
> point).

The functions are defined in two separate global namespaces, though.
That means that the actual bindings visible to ham() are different
from the globals visible to spam().  Constants should be fine, but if
ham() modifies a global, then spam() won't see the change, and
vice-versa.

> 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 membership testing, because it's already in
use in the for-loop syntax.  It wouldn't be the first time Python has
reused a keyword.

[toc] | [prev] | [next] | [standalone]

#7796

Ian Kelly wrote:
> On Thu, Jun 16, 2011 at 7:21 PM, Erik Max Francis <max@alcyone.com> 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 membership testing, because it's already in
> use in the for-loop syntax.  It wouldn't be the first time Python has
> reused a keyword.

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 not a good idea to reuse keywords that really read very differently 
than their original use.  Reusing `break` (or `return`) this way would 
be rather abusive.

-- 
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
   Winners are men who have dedicated their whole lives to winning.
    -- Woody Hayes

[toc] | [prev] | [next] | [standalone]

#7798

On Thu, Jun 16, 2011 at 10:24 PM, Erik Max Francis <max@alcyone.com> 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
> not a good idea to reuse keywords that really read very differently than
> their original use.  Reusing `break` (or `return`) this way would be rather
> abusive.

Yes, using `in` to mean "break out of a block" would obviously be a
terrible choice, since the word "in" has nothing to do with breaking.
I really don't see why using `break` to mean "break out of a block" is
counter-intuitive, especially since as you point out it is already
used that way for two particular types of blocks.  The proposed usage
merely adds a third type.

I think a stronger objection might be that it disrupts the homology of
`break` and `continue`, since continuing a module is meaningless.

[toc] | [prev] | [next] | [standalone]

#7800

Ian Kelly wrote:
> On Thu, Jun 16, 2011 at 10:24 PM, Erik Max Francis <max@alcyone.com> 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
>> not a good idea to reuse keywords that really read very differently than
>> their original use.  Reusing `break` (or `return`) this way would be rather
>> abusive.
> 
> Yes, using `in` to mean "break out of a block" would obviously be a
> terrible choice, since the word "in" has nothing to do with breaking.
> I really don't see why using `break` to mean "break out of a block" is
> counter-intuitive, especially since as you point out it is already
> used that way for two particular types of blocks.  The proposed usage
> merely adds a third type.
> 
> I think a stronger objection might be that it disrupts the homology of
> `break` and `continue`, since continuing a module is meaningless.

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 earlier which you're trying to nitpick in another reply.

-- 
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
   Maybe I could see you / When this is over
    -- Scritti Politti

[toc] | [prev] | [next] | [standalone]

#7802

On Fri, Jun 17, 2011 at 3:20 PM, Erik Max Francis <max@alcyone.com> 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 though
returning a value other than None would make no sense. It would simply
be a restriction, and one that almost nobody would notice - like this:

>>> def f():
	yield 1
	yield 2
	yield 3

	
>>> a=f()
>>> a
<generator object f at 0x00FB4AA8>
>>> a.send(1)
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in <module>
    a.send(1)
TypeError: can't send non-None value to a just-started generator

ChrisA

[toc] | [prev] | [next] | [standalone]

#7803

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 earlier which you're trying to nitpick in another reply.

No offense is intended Erik, but in my experience, when people complain 
about others nitpicking, they've usually said something which is *almost* 
correct, i.e. wrong :)

Can we agree that the plain English verb "break", as in "to break out 
of", can apply to any of:

* returning from a function
* yielding from an interator or generator
* raising an exception
* jumping via a GOTO (in languages that have GOTOs)
* exiting a loop via a break
* or any other way of exiting from a code block that I may have missed

and that only the fifth applies to the Python keyword "break"?

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" strikes me as disagreeable, but not as 
disagreeable as overloading "return" or "in" :)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#7807

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 point I
>> made earlier which you're trying to nitpick in another reply.
> 
> No offense is intended Erik, but in my experience, when people complain 
> about others nitpicking, they've usually said something which is *almost* 
> correct, i.e. wrong :)
> 
> Can we agree that the plain English verb "break", as in "to break out 
> of", can apply to any of:

This is all great and all, but specific references earlier in the thread 
were made to not just the concept of "breaking out of things," but to 
the `break`, `continue` (not relevant here), and `return` keywords.  It 
was these that I was discussing.

I simply pointed out why the first and last were not good ideas for 
consistency reasons (the second was never proposed as a good idea). 
And, most importantly, why the whole idea is not that useful to start 
with; there already exist far better ways to achieve your goals that are 
already supported in the language, clear, and self-documenting if used 
properly.

-- 
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
   Do we really want to go to Mars / Do we really want to try
    -- Cassandra Wilson

[toc] | [prev] | [next] | [standalone]

#7877

On 17Jun2011 06:00, Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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" strikes me as disagreeable, but not as 
| disagreeable as overloading "return" or "in" :)

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 StopIteration".

Then the import machinery can catch it, no new keyword is needed and no
existing keyword needs feature creeping.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

And it is not our part here to take thought only for a season, or for a few
lives of Men, or for a passing age of the world.        - Gandalf the grey

[toc] | [prev] | [next] | [standalone]

#7880

On Sat, 18 Jun 2011 12:36:42 +1000, Cameron Simpson wrote:

> On 17Jun2011 06:00, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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" strikes me as disagreeable, but not as |
> disagreeable as overloading "return" or "in" :)
> 
> 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 StopIteration".
> 
> Then the import machinery can catch it, no new keyword is needed and no
> existing keyword needs feature creeping.

The only problem is that the importing module needs to catch it, or else 
you get a traceback. The importer shouldn't need to care what goes in 
inside the module.

Something like this:

spam()
if condition:
    exit  # halt, stop, whatever
ham()
cheese()


should be the equivalent to:


spam()
if not condition:
    ham()
    cheese()


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
everything under here is ignored


but I think it was a feature in search of a use.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#7884

On Sat, Jun 18, 2011 at 1:50 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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
> everything under here is ignored
>

Isn't that how Perl's __data__ keyword works? (Long time since I've
used it, it mightn't be quite __data__.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#7885

On Sat, 18 Jun 2011 14:31:51 +1000, Chris Angelico wrote:

> On Sat, Jun 18, 2011 at 1:50 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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
>> everything under here is ignored
>>
>>
> Isn't that how Perl's __data__ keyword works? (Long time since I've used
> it, it mightn't be quite __data__.)

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 end of the Perl 
program, and leave the rest of the document visible to the caller via a 
special file handle:

http://www.perl-programming.info/difference-btw-__end__-and-__data__


You know, I actually kinda like that...


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#7887

On Sat, Jun 18, 2011 at 2:49 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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 end of the Perl
> program, and leave the rest of the document visible to the caller via a
> special file handle:

Sure, but if you don't use that handle, it comes to the same thing.
It's like a function's return value when you just want its side
effects, or using re.match and ignoring all but whether it evaluates
as True or False. In REXX, you can access any part of the source file
using the sourceline() function - sometimes I've done things like
this:

/*
Usage: scriptname [arg] [arg] [arg]
arg: specifies the number of times to yell Argh
arg: specifies the type of black beast to kill you
arg: chooses an Abstract Resource Group

Use this only in cases of blargh.
*/
.
.
.
.
usage:
do i=2 to sourceline() until sourceline(i)="*/"; say sourceline(i); end

Does this mean that the comment isn't ignored? Nope. It's ignored, but
it can be retrieved through in-language means.

Anyhow, it's not uncommon to abuse language features to do different
things. I've heard that it's faster in MS-DOS Batch to put comments
with a leading colon (making them labels for goto) than to use the REM
(remark) command...

ChrisA

[toc] | [prev] | [next] | [standalone]

#8081

On 18Jun2011 03:50, Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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 StopIteration".
| > 
| > Then the import machinery can catch it, no new keyword is needed and no
| > existing keyword needs feature creeping.
| 
| The only problem is that the importing module needs to catch it, or else 
| you get a traceback. The importer shouldn't need to care what goes in 
| inside the module.

I was thinking the import mechanism itself would catch it, not the user
of the "import" statement. Just as this:

  for i in iterator:
    ...

quietly ceases the loop when the iterator raises StopIteration, the
importer would consider a module that raised StopImport during the import
to have finished its import successfully.

So the caller does an:

  import foo

as normal, with no special wrapping. And the module goes:

  spam()
  if condition:
    raise StopIteration
  ham()
  cheese()

Cheers,
-- 
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

In article <323C4DB9.6A76@ss1.csd.sc.edu>, lhartley@ss1.csd.sc.edu wrote:
| It still is true that the best touring bike is the one that you are
| riding right now.  Anything can be used for touring.  As long as you
| can travel, you are touring.
I beleive such true and profound statements are NOT allowed to be posted
in this newsgroup, and are also against the charter.  You've been warned.
        - Randy Davis DoD #0013 <randy@agames.com> in rec.moto

[toc] | [prev] | [next] | [standalone]

#7805

On Thu, Jun 16, 2011 at 11:56 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Jun 17, 2011 at 3:20 PM, Erik Max Francis <max@alcyone.com> 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 though
> returning a value other than None would make no sense. It would simply
> be a restriction, and one that almost nobody would notice - like this:
>

I'd say let's not bikeshed on the name when the merits of "breaking"
out of a module's execution haven't been established, but what's the
point.  <wink>

-eric

>>>> def f():
>        yield 1
>        yield 2
>        yield 3
>
>
>>>> a=f()
>>>> a
> <generator object f at 0x00FB4AA8>
>>>> a.send(1)
> Traceback (most recent call last):
>  File "<pyshell#7>", line 1, in <module>
>    a.send(1)
> TypeError: can't send non-None value to a just-started generator
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#7663

On Wed, Jun 15, 2011 at 10:51 AM, Eric Snow <ericsnowcurrently@gmail.com> 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:


def expensive_stuff_1():
    ...

def expensive_stuff_2():
    ...

if not condition_1:
    expensive_stuff_1()
if not condition_2:
    expensive_stuff_2()


Depending on what exactly you're doing, this might make perfect sense,
or might be a useless indentation level of its own. If the expensive
stuff divides nicely into units, where each unit is governed by one
condition, it might work out well that way; you could use the same
functions to build your 'if __main__' section too.

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web