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

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

Using the Python Interpreter as a Reference

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

Contents

  Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-20 16:46 -0800
    Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-21 13:33 +1100
      Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-21 05:44 +0000
        Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-21 17:48 +1100
        Re: Using the Python Interpreter as a Reference Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-11-21 10:03 -0800
        Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-21 16:07 -0800
    Re: Using the Python Interpreter as a Reference Alan Meyer <ameyer2@yahoo.com> - 2011-11-22 13:37 -0500
      Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-25 02:55 -0800
        Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-25 22:10 +1100
    Re: Using the Python Interpreter as a Reference rusi <rustompmody@gmail.com> - 2011-11-25 09:11 -0800
      RE: Using the Python Interpreter as a Reference "Sells, Fred" <fred.sells@adventistcare.org> - 2011-11-25 23:22 -0500
      Re: Using the Python Interpreter as a Reference Matt Joiner <anacrolix@gmail.com> - 2011-11-26 23:19 +1100
    Re: Using the Python Interpreter as a Reference Alec Taylor <alec.taylor6@gmail.com> - 2011-11-27 05:46 +1100
    Re: Using the Python Interpreter as a Reference Rick Johnson <rantingrickjohnson@gmail.com> - 2011-11-26 10:53 -0800
      Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-27 06:34 +1100
        Re: Using the Python Interpreter as a Reference Rick Johnson <rantingrickjohnson@gmail.com> - 2011-11-26 13:15 -0800
      Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-27 14:21 -0800
        Re: Using the Python Interpreter as a Reference Colin Higwell <colinh@somewhere.invalid> - 2011-11-27 23:02 +0000
        Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-27 23:55 +0000
          Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-28 11:26 +1100
          Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 10:03 -0800
          Re: Using the Python Interpreter as a Reference Ian Kelly <ian.g.kelly@gmail.com> - 2011-11-28 12:32 -0700
            Re: Using the Python Interpreter as a Reference Neil Cerutti <neilc@norwich.edu> - 2011-11-28 20:20 +0000
              Re: Using the Python Interpreter as a Reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-11-29 09:48 +1300
                Re: Using the Python Interpreter as a Reference Neil Cerutti <neilc@norwich.edu> - 2011-11-28 21:11 +0000
            Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 13:34 -0800
            Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-28 22:24 +0000
              Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 09:48 +1100
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 18:42 -0800
                Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 13:57 +1100
                  Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-29 08:12 +0000
                    Re: Using the Python Interpreter as a Reference Dave Angel <d@davea.name> - 2011-11-29 03:53 -0500
                Re: Using the Python Interpreter as a Reference Ian Kelly <ian.g.kelly@gmail.com> - 2011-11-28 21:56 -0700
          Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-11-28 16:54 -0800
            Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-11-28 16:59 -0800
            Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 12:49 +1100
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 19:00 -0800
              Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-29 08:04 +0000
                Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-12-01 10:03 -0800
                  Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-02 00:43 +0000
                    Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-12-02 13:02 +1100
                    RE: Using the Python Interpreter as a Reference "Sells, Fred" <fred.sells@adventistcare.org> - 2011-12-02 15:29 -0500
                    Re: Using the Python Interpreter as a Reference Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-02 15:58 -0500
        Re: Using the Python Interpreter as a Reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-11-29 09:40 +1300
          Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 13:29 -0800
            Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 08:57 +1100
            Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-28 22:57 +0000
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 18:57 -0800

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

#16518

On Fri, Dec 2, 2011 at 11:43 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Why would you want to encourage coders to write deeply indented code?
>
> In my opinion, if your code is indented four or more levels, you should
> start to think about refactorising your code; if you reach six levels,
> your code is probably a mess.

So... would it be a bad thing to wrap up all my code into a single
massive expression that returns a single integer for success/failure?
Oh wait, the only time I ever saw code do that was in the IOCCC.
Still, it WAS pretty awesome code!

IOCCC is a code perfume factory. Cloying smell.

ChrisA

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

#16569

Steven, that's probably the most elegant explanation of the "pythonic"
way I've ever seen.  I'm saving it for the next time upper management
want to use Java again.

-----Original Message-----
From: python-list-bounces+frsells=adventistcare.org@python.org
[mailto:python-list-bounces+frsells=adventistcare.org@python.org] On
Behalf Of Steven D'Aprano
Sent: Thursday, December 01, 2011 7:43 PM
To: python-list@python.org
Subject: Re: Using the Python Interpreter as a Reference

On Thu, 01 Dec 2011 10:03:53 -0800, DevPlayer wrote:

[...]
> Well, that may be a little hyperbolic. But with 2 spaces you can
> encourage coders to get very deep, indentially, and still fit 80
chars.

Why would you want to encourage coders to write deeply indented code?

In my opinion, if your code is indented four or more levels, you should 
start to think about refactorising your code; if you reach six levels, 
your code is probably a mess.

class K:
    def spam():
        if x:
            for a in b:
                # This is about as deep as comfortable
                while y:
                    # Code is starting to smell
                    try:
                        # Code smell is now beginning to reek
                        with z as c:
                            # And now more of a stench
                            try:
                                # A burning, painful stench
                                if d:
                                    # Help! I can't breathe!!!
                                    for e in f:
                                        # WTF are you thinking?
                                        try:
                                            # DIE YOU M***********ER!!!
                                            while g:
                                                # gibbers quietly
                                                ...


The beauty of languages like Python where indentation is significant is 
that you can't hide from the ugliness of this code. 

class K: {
  # Code looks okay to a casual glance.
  def spam():{
   if x: { for a in b:{
     while y:{ try:{ with z as c:{
       try:{ if d:{ for e in f:{ try:{
         while g:{ ... }}}}
       }}}}
     }}}}

Deeply indented code *is* painful, it should *look* painful.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

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

#16570

> In my opinion, if your code is indented four or more levels, you should
> start to think about refactorising your code; if you reach six levels,
> your code is probably a mess.

Here's some code I encountered while grading assignments from
first-year CS students:

        if 'not' in temp_holder:
            for item in (range(len(ial))):
                for key in (range(len(ial[item]))):
                    if type(ial[item][key]) == str:
                       if temp[term].find(ial[item][key]) > 0:
                          for value in range(len(ial[item][1])):
                              if ial[item][1][value] in images:
                                 while ial[item][1][value] in images:
                                       images.remove(ial[item][1][value])

I think after some point of nesting, not only can we conclude that the
code is difficult to read, we can probably conclude the author wasn't
thinking very clearly about what he or she was doing.

Devin

On Thu, Dec 1, 2011 at 7:43 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 01 Dec 2011 10:03:53 -0800, DevPlayer wrote:
>
> [...]
>> Well, that may be a little hyperbolic. But with 2 spaces you can
>> encourage coders to get very deep, indentially, and still fit 80 chars.
>
> Why would you want to encourage coders to write deeply indented code?
>
> In my opinion, if your code is indented four or more levels, you should
> start to think about refactorising your code; if you reach six levels,
> your code is probably a mess.
>
> class K:
>    def spam():
>        if x:
>            for a in b:
>                # This is about as deep as comfortable
>                while y:
>                    # Code is starting to smell
>                    try:
>                        # Code smell is now beginning to reek
>                        with z as c:
>                            # And now more of a stench
>                            try:
>                                # A burning, painful stench
>                                if d:
>                                    # Help! I can't breathe!!!
>                                    for e in f:
>                                        # WTF are you thinking?
>                                        try:
>                                            # DIE YOU M***********ER!!!
>                                            while g:
>                                                # gibbers quietly
>                                                ...
>
>
> The beauty of languages like Python where indentation is significant is
> that you can't hide from the ugliness of this code.
>
> class K: {
>  # Code looks okay to a casual glance.
>  def spam():{
>   if x: { for a in b:{
>     while y:{ try:{ with z as c:{
>       try:{ if d:{ for e in f:{ try:{
>         while g:{ ... }}}}
>       }}}}
>     }}}}
>
> Deeply indented code *is* painful, it should *look* painful.
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list

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

#16352

Travis Parks wrote:
> I thinking tabs are
> out-of-date. Even the MAKE community wishes that the need for tabs
> would go away

The situation with make is a bit different, because it
*requires* tabs in certain places -- spaces won't do.
Python lets you choose which to use as long as you don't
mix them up, and I like it that way.

> let Parse = public static method (value: String)
> throws(FormatException UnderflowException OverflowException)

Checked exceptions? I fear you're repeating a huge mistake
going down that route...

-- 
Greg

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

#16360

On Nov 28, 3:40 pm, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote:
> Travis Parks wrote:
> > I thinking tabs are
> > out-of-date. Even the MAKE community wishes that the need for tabs
> > would go away
>
> The situation with make is a bit different, because it
> *requires* tabs in certain places -- spaces won't do.
> Python lets you choose which to use as long as you don't
> mix them up, and I like it that way.
>
> > let Parse = public static method (value: String)
> > throws(FormatException UnderflowException OverflowException)
>
> Checked exceptions? I fear you're repeating a huge mistake
> going down that route...
>
> --
> Greg
>
>

Exception handling is one of those subjects few understand and fewer
can implement properly in modern code. Languages that don't support
exceptions as part of their signature lead to capturing generic
Exception all throughout code. It is one of those features I wish .NET
had. At the same time, with my limited experience with Java, it has
been a massive annoyance. Perhaps something to provide or just shut
off via a command line parameter. What indications have there been
that this has been a flaw? I can see it alienating a large group of up-
and-coming developers.

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

#16362

On Tue, Nov 29, 2011 at 8:29 AM, Travis Parks <jehugaleahsa@gmail.com> wrote:
> Languages that don't support
> exceptions as part of their signature lead to capturing generic
> Exception all throughout code. It is one of those features I wish .NET
> had. At the same time, with my limited experience with Java, it has
> been a massive annoyance.

In Java, it mainly feels like syntactic salt. There's still a class of
RuntimeExceptions that aren't listed in the signature, so you still
have to concern yourself with the possibility that unexpected
exceptions will propagate; and you're forced to decorate every method
with the list of what it might propagate up, other than that.

It's like const-decorating a series of functions in C++, only far less
consequential and requiring far more typing.

ChrisA

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

#16365

On Mon, 28 Nov 2011 13:29:06 -0800, Travis Parks wrote:

> Exception handling is one of those subjects few understand and fewer can
> implement properly in modern code. Languages that don't support
> exceptions as part of their signature lead to capturing generic
> Exception all throughout code. It is one of those features I wish .NET
> had. At the same time, with my limited experience with Java, it has been
> a massive annoyance. Perhaps something to provide or just shut off via a
> command line parameter. What indications have there been that this has
> been a flaw? I can see it alienating a large group of up- and-coming
> developers.

http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html

Note also that Bruce Eckel repeats a rumour that checked exceptions were 
*literally* an experiment snuck into the Java language while James 
Gosling was away on holiday.

http://www.mindview.net/Etc/Discussions/UnCheckedExceptionComments

Even if that is not true, checked exceptions are a feature that *in 
practice* seems to lead to poor exception handling and cruft needed only 
to satisfy the compiler:

http://www.alittlemadness.com/2008/03/12/checked-exceptions-failed-experiment/#comment-219143

and other annoyances. It's main appeal, it seems to me, is to give a 
false sense of security to Java developers who fail to realise that under 
certain circumstances Java will raise certain checked exceptions *even if 
they are not declared*. E.g. null pointer exceptions.

See also:

http://java.dzone.com/articles/checked-exceptions-i-love-you

and note especially the comment from the coder who says that he simply 
declares his functions to throw Exception (the most generic checked 
exception), thus defeating the whole point of checked exceptions.


-- 
Steven

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

#16372

On Nov 28, 5:57 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Mon, 28 Nov 2011 13:29:06 -0800, Travis Parks wrote:
> > Exception handling is one of those subjects few understand and fewer can
> > implement properly in modern code. Languages that don't support
> > exceptions as part of their signature lead to capturing generic
> > Exception all throughout code. It is one of those features I wish .NET
> > had. At the same time, with my limited experience with Java, it has been
> > a massive annoyance. Perhaps something to provide or just shut off via a
> > command line parameter. What indications have there been that this has
> > been a flaw? I can see it alienating a large group of up- and-coming
> > developers.
>
> http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html
>
> Note also that Bruce Eckel repeats a rumour that checked exceptions were
> *literally* an experiment snuck into the Java language while James
> Gosling was away on holiday.
>
> http://www.mindview.net/Etc/Discussions/UnCheckedExceptionComments
>
> Even if that is not true, checked exceptions are a feature that *in
> practice* seems to lead to poor exception handling and cruft needed only
> to satisfy the compiler:
>
> http://www.alittlemadness.com/2008/03/12/checked-exceptions-failed-ex...
>
> and other annoyances. It's main appeal, it seems to me, is to give a
> false sense of security to Java developers who fail to realise that under
> certain circumstances Java will raise certain checked exceptions *even if
> they are not declared*. E.g. null pointer exceptions.
>
> See also:
>
> http://java.dzone.com/articles/checked-exceptions-i-love-you
>
> and note especially the comment from the coder who says that he simply
> declares his functions to throw Exception (the most generic checked
> exception), thus defeating the whole point of checked exceptions.
>
> --
> Steven

I think all of the examples you listed referred specifically to most
programmers finding ways around the annoyance. I have heard about
throwing generic Exception or inheriting all custom exception types
from RuntimeException. I did this quite often myself.

In general, unchecked exceptions shouldn't be caught. They occur
because of bad code and insufficient testing. Checked exceptions occur
because of downed databases, missing files, network problems - things
that may become available later without code changes.

One day, I went through about 10,000 lines of code and moved argument
checking code outside of try blocks because I realized I was handling
some of them by accident. Here is the program: if me == idiot: exit().

People don't think about this, but the exceptions thrown by a module
are part of that module's interface. Being able to make sure only what
you expect to come out is important. Unlike Java, Unit requires you to
opt in to using throws clauses. If you don't list one, one is
generated for you automatically. The benefit: you can see what a
function throws and protect yourself without all the babysitting.

A lack of exception handling is big problem in .NET. I have had
libraries from big names including Novell and Oracle throw
NullReferenceExceptions because _they_ didn't know what would happen
in cases where a DLL is missing or a dependency isn't installed. They
could have done better testing, but if the biggest names in
development can't manage to figure it, I say leave it up to the
compiler. Returning nulls or special value in cases of failures takes
us back to the days of C and Fortran.

[toc] | [prev] | [standalone]

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

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

csiph-web