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

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

New user's initial thoughts / criticisms of Python

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

Contents

  New user's initial thoughts / criticisms of Python John von Horn <j.h69@btinternet.com> - 2013-11-09 07:08 -0600
    Re: New user's initial thoughts / criticisms of Python Ned Batchelder <ned@nedbatchelder.com> - 2013-11-09 05:22 -0800
    Re: New user's initial thoughts / criticisms of Python Joshua Landau <joshua@landau.ws> - 2013-11-09 13:27 +0000
      Re: New user's initial thoughts / criticisms of Python Jonathan <jtcegh@gmail.com> - 2013-11-09 14:44 -0800
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 10:29 +1100
        Re: New user's initial thoughts / criticisms of Python MRAB <python@mrabarnett.plus.com> - 2013-11-10 00:50 +0000
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 11:54 +1100
        Re: New user's initial thoughts / criticisms of Python Neil Cerutti <neilc@norwich.edu> - 2013-11-11 15:30 +0000
      Re: New user's initial thoughts / criticisms of Python Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2013-11-10 13:24 +0100
    Re: New user's initial thoughts / criticisms of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-09 13:41 +0000
    Re: New user's initial thoughts / criticisms of Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-11-09 16:24 +0200
    Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 01:27 +1100
      Sandboxing Python [was Re: New user's initial thoughts / criticisms of Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-09 15:25 +0000
        Re: Sandboxing Python [was Re: New user's initial thoughts / criticisms of Python] Chris Angelico <rosuav@gmail.com> - 2013-11-10 02:32 +1100
      Re: New user's initial thoughts / criticisms of Python Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-11-10 08:47 +0000
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 20:22 +1100
        Re: New user's initial thoughts / criticisms of Python Ian Kelly <ian.g.kelly@gmail.com> - 2013-11-10 04:39 -0700
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-10 22:43 +1100
        Re: New user's initial thoughts / criticisms of Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-11-10 12:12 -0500
        Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-11 10:29 +1100
        Re: New user's initial thoughts / criticisms of Python Terry Reedy <tjreedy@udel.edu> - 2013-11-10 19:13 -0500
    Re: New user's initial thoughts / criticisms of Python rusi <rustompmody@gmail.com> - 2013-11-09 07:38 -0800
      Re: New user's initial thoughts / criticisms of Python Roy Smith <roy@panix.com> - 2013-11-09 10:56 -0500
        Re: New user's initial thoughts / criticisms of Python rusi <rustompmody@gmail.com> - 2013-11-09 08:30 -0800
          Re: New user's initial thoughts / criticisms of Python Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-10 21:36 -0800
            Re: New user's initial thoughts / criticisms of Python Roy Smith <roy@panix.com> - 2013-11-11 09:01 -0500
              Re: New user's initial thoughts / criticisms of Python rusi <rustompmody@gmail.com> - 2013-11-11 07:14 -0800
              Re: New user's initial thoughts / criticisms of Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-11-11 21:05 -0500
              Re: New user's initial thoughts / criticisms of Python Ethan Furman <ethan@stoneleaf.us> - 2013-11-12 14:38 -0800
    Re: New user's initial thoughts / criticisms of Python John von Horn <j.h69@btinternet.com> - 2013-11-09 14:19 -0600
    Re: New user's initial thoughts / criticisms of Python Tim Chase <python.list@tim.thechases.com> - 2013-11-09 14:39 -0600
    Re: New user's initial thoughts / criticisms of Python Mark Janssen <dreamingforward@gmail.com> - 2013-11-09 12:33 -0800
      Re: New user's initial thoughts / criticisms of Python Ned Batchelder <ned@nedbatchelder.com> - 2013-11-09 12:54 -0800
        Re: New user's initial thoughts / criticisms of Python Mark Janssen <dreamingforward@gmail.com> - 2013-11-09 13:21 -0800
    Re: New user's initial thoughts / criticisms of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-09 21:01 +0000
    Re: New user's initial thoughts / criticisms of Python Tim Chase <python.list@tim.thechases.com> - 2013-11-09 15:20 -0600
    Re: New user's initial thoughts / criticisms of Python lorenzo.gatti@gmail.com - 2013-11-11 02:09 -0800
      Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-11 21:39 +1100
        Re: New user's initial thoughts / criticisms of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-11 11:17 +0000
          Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-11 22:32 +1100
          Re: New user's initial thoughts / criticisms of Python Mark Janssen <dreamingforward@gmail.com> - 2013-11-11 14:29 -0800
      Re: New user's initial thoughts / criticisms of Python Robert Kern <robert.kern@gmail.com> - 2013-11-11 11:53 +0000
      Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-11 23:07 +1100
      Re: New user's initial thoughts / criticisms of Python Joshua Landau <joshua@landau.ws> - 2013-11-11 20:50 +0000
      Re: New user's initial thoughts / criticisms of Python Chris Angelico <rosuav@gmail.com> - 2013-11-12 09:21 +1100
      Re: New user's initial thoughts / criticisms of Python Joshua Landau <joshua@landau.ws> - 2013-11-12 01:53 +0000

Page 1 of 3  [1] 2 3  Next page →

#58933 — New user's initial thoughts / criticisms of Python

Hi Everyone,

I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am 
enjoying working along to some youtube tutorials. I've done a little 
programming in the past.

I've just got a few thoughts I'd like to share and ask about:

* Why not allow floater=float(int1/int2) - rather than floater=float
(int1)/float(int2)?

Give me a float (or an error message) from evaluating everything in the 
brackets. Don't make me explicitly convert everything myself (unless I 
want to)

* No sign of a select .. case statement

Another useful tool in the programmer's toolbox

Select DayofWeek

	case "mon"

	...

end select

* Call me pedantic by why do we need a trailing comma for a list of one 
item? Keep it intuitive and allow lstShopping=[] or ["Bread"] or 
["Bread", "Milk","Hot Chocolate"] I don't like ["Bread",]. It bugs me.

Just some initial thoughts. I just wanted to know the reasoning behind 
the above, be shown the shortcomings of my ignorance, pointed in the 
right direction. Let the High Priests of Python come forth and speak wise 
words and show me the ignorance of thy ways. Let my cup be filled to 
overflowing with your kind knowledge and wisdom.

Is everyone happy with the way things are? Could anyone recommend a good, 
high level language for CGI work? Not sure if I'm going to be happy with 
Perl (ahhh, get him, he's mentioned Perl and is a heretic!) or Python. I 
would very much value any constructive criticism or insights.

And a "thank you", ["sirs","madams"] but pls, not just ["sirs",]

JvH

[toc] | [next] | [standalone]

#58934

On Saturday, November 9, 2013 8:08:25 AM UTC-5, John von Horn wrote:
> Hi Everyone,
> 
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am 
> enjoying working along to some youtube tutorials. I've done a little 
> programming in the past.
> 
> I've just got a few thoughts I'd like to share and ask about:
> 
> * Why not allow floater=float(int1/int2) - rather than floater=float
> (int1)/float(int2)?
> 
> Give me a float (or an error message) from evaluating everything in the 
> brackets. Don't make me explicitly convert everything myself (unless I 
> want to)
> 

The language has to specify what int1/int2 should evaluate to.  Python 2 says it is an int.  Once that computation is done, passing that int to float() can't bring back the lost information.  Python 3 says that int1/int2 produces a float, and you can get that behavior if you use "from __future__ import division" at the top of your Python 2.7 file.

> * No sign of a select .. case statement
> 
> Another useful tool in the programmer's toolbox
> 
> Select DayofWeek
> 
> 	case "mon"
> 
> 	...
> 
> end select
> 

This is a bit more controversial.  Python has no select statement because it has very little advantage over simply using an if/elif/elif/else ladder. In languages like C, a switch compiles to a table lookup.  In Python, all the actual comparisons would have to be done anyway, so it would simply be an alternate syntax for a number of if statements.  In the interest of not cluttering the language, the switch statement doesn't exist.

> * Call me pedantic by why do we need a trailing comma for a list of one 
> item? Keep it intuitive and allow lstShopping=[] or ["Bread"] or 
> ["Bread", "Milk","Hot Chocolate"] I don't like ["Bread",]. It bugs me.
>

You're mistaken: One-element lists are written without a trailing comma, though you are allowed to include them.  One-element tuples, though, require the trailing comma, since ("hello") is just the same as "hello".

Welcome to Python!
 
> JvH

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

#58936

On 9 November 2013 13:08, John von Horn <j.h69@btinternet.com> wrote:
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
> enjoying working along to some youtube tutorials. I've done a little
> programming in the past.
>
> I've just got a few thoughts I'd like to share and ask about:
>
> * Why not allow floater=float(int1/int2) - rather than floater=float
> (int1)/float(int2)?
>
> Give me a float (or an error message) from evaluating everything in the
> brackets. Don't make me explicitly convert everything myself (unless I
> want to)

In Python 2, `int1/int2` does integer division. So
`float(that_result)` gives a truncated float.
`int1/float(int2)` obviously avoids this by dividing by a float.

If `float(int1/int2)` were to return the same value, `float` could not
be a normal function, and would have to be magic. Magic is bad.
Fortunately, Python 3 does the sane thing and just does floating-point
division by default. Great, eh?

> * No sign of a select .. case statement
>
> Another useful tool in the programmer's toolbox
>
> Select DayofWeek
>
>         case "mon"
>
>         ...
>
> end select

`select` is quite an odd statement, in that in most cases it's just a
weaker variant of `if`. By the time you're at the point where a
`select` is actually more readable you're also at the point where a
different control flow is probably a better idea. Things like
dictionaries or a variables pointing to functions are really useful
and can be encapsulated in a class quite well. This is a bit more
advanced but largely more rigorous.

But most of the time the idea is just that an `if` is more explicit,
and it's not like a `case` statement can be optimised as it can in
lower-level languages with simpler datatypes.

> * Call me pedantic by why do we need a trailing comma for a list of one
> item? Keep it intuitive and allow lstShopping=[] or ["Bread"] or
> ["Bread", "Milk","Hot Chocolate"] I don't like ["Bread",]. It bugs me.

You don't.

You might be confused because you need to write `("hello",)`, but
that's because the *comma* makes a *tuple*, not the brackets. Imagine
if `2 * (1/2)` gave you `(0.5, 0.5)`!

> Is everyone happy with the way things are? Could anyone recommend a good,
> high level language for CGI work? Not sure if I'm going to be happy with
> Perl (ahhh, get him, he's mentioned Perl and is a heretic!) or Python. I
> would very much value any constructive criticism or insights.

I don't know squat about CGI, but I think Python can grow on anyone
open to the idea of programming at a high level. Not "high level" as
in "expert" but as in "using higher-level constructs", if you get the
meaning. Python implements these quite well. Your first two complaints
are not new, though.

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

#58972

On Saturday, November 9, 2013 8:27:02 AM UTC-5, Joshua Landau wrote:

> `select` is quite an odd statement, in that in most cases it's just a
> weaker variant of `if`. By the time you're at the point where a
> `select` is actually more readable you're also at the point where a
> different control flow is probably a better idea. Things like
> dictionaries or a variables pointing to functions are really useful
> and can be encapsulated in a class quite well. This is a bit more
> advanced but largely more rigorous.
> 
> But most of the time the idea is just that an `if` is more explicit,
> and it's not like a `case` statement can be optimised as it can in
> lower-level languages with simpler datatypes.

The C switch statement is very limited.  The select statement in the dialect of BASIC I regularly use is more flexible.   It's more concise on long if chains because it elides the "end if"s.  But the use of indentation for blocks and the "in" operator certainly reduce the need for it in Python.

In pythonic syntax:

select <expression0>:
  case <case expression>,[<case expression>],:
  ....
  ....
  case else:


where <case expression> is one of

a) <expression1>

which is equivalent to:   elif <expression0> = <expression1>:

b) <binary-operator> <expression2>

which is equivalent to:   elif <expression0> <binary-operator>

Note that:
 "elif" is actually "if" for the first case in the select.
 control exits at next case, no need for breaks.
 expression0 is only evaluated once and stored in an anonymous temporary variable.

The switch statement in (the language) go is similar, except that <expression0> defaults to true and it doesn't elide <expression0> in the case statements.

Dictionaries can't handle the uses where expression0 is constant and the case expressions are not.
Function variables beg the question.  How did you decide what to assign to the variable?

I'd use this select if it was in Python, but I don't see much need for it.

jtc

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

#58975

On Sun, Nov 10, 2013 at 9:44 AM, Jonathan <jtcegh@gmail.com> wrote:
> In pythonic syntax:
>
> select <expression0>:
>   case <case expression>,[<case expression>],:
> which is equivalent to:   elif <expression0> = <expression1>:
> which is equivalent to:   elif <expression0> <binary-operator>

Small clarification: It's more akin to assigning <expression0> to a
temporary, and then comparing that temporary against everything. It's
only evaluated once. Otherwise, yes, as you describe.

ChrisA

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

#58977

On 09/11/2013 22:44, Jonathan wrote:
> On Saturday, November 9, 2013 8:27:02 AM UTC-5, Joshua Landau wrote:
>
>> `select` is quite an odd statement, in that in most cases it's just a
>> weaker variant of `if`. By the time you're at the point where a
>> `select` is actually more readable you're also at the point where a
>> different control flow is probably a better idea. Things like
>> dictionaries or a variables pointing to functions are really useful
>> and can be encapsulated in a class quite well. This is a bit more
>> advanced but largely more rigorous.
>>
>> But most of the time the idea is just that an `if` is more explicit,
>> and it's not like a `case` statement can be optimised as it can in
>> lower-level languages with simpler datatypes.
>
> The C switch statement is very limited.  The select statement in the dialect of BASIC I regularly use is more flexible.   It's more concise on long if chains because it elides the "end if"s.  But the use of indentation for blocks and the "in" operator certainly reduce the need for it in Python.
>
> In pythonic syntax:
>
> select <expression0>:
>    case <case expression>,[<case expression>],:
>    ....
>    ....
>    case else:
>
[snip]

It's more likely that the cases would be indented the same amount as
the 'select', and you wouldn't need 'case else', just 'else'.

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

#58979

On Sun, Nov 10, 2013 at 11:50 AM, MRAB <python@mrabarnett.plus.com> wrote:
> On 09/11/2013 22:44, Jonathan wrote:
>> In pythonic syntax:
>>
>> select <expression0>:
>>    case <case expression>,[<case expression>],:
>>    ....
>>    ....
>>    case else:
>>
> [snip]
>
> It's more likely that the cases would be indented the same amount as
> the 'select', and you wouldn't need 'case else', just 'else'.

To fully bike-shed something that's not even a proposal, much less one
that's likely to happen: I would agree with Jonathan, the 'select'
block ends with a colon and gets indented.

ChrisA

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

#59082

> On Saturday, November 9, 2013 8:27:02 AM UTC-5, Joshua Landau wrote:
> The C switch statement is very limited.  The select statement
> in the dialect of BASIC I regularly use is more flexible.
> It's more concise on long if chains because it elides the "end
> if"s.  But the use of indentation for blocks and the "in"
> operator certainly reduce the need for it in Python.

It's say the C switch isn't limited enough to be a Python
resident. The default fallthrough, labels, jumps and breaks make
it a poor Python construct.

K&R have this to say: "Falling through from one case to another
is not robust, being prone to disintegration when the program is
modified."

So Python would need something simler. Once you winnow it down to
a robust feature, it provide virtually nothing you don't get with
an if/elif/else. At best it would save a temporary.

> The switch statement in (the language) go is similar, except
> that <expression0> defaults to true and it doesn't elide
> <expression0> in the case statements.

Go makes interesting use of switch statements. In addition to
what you might expect, you can also do type switches. A type
switch lets you provide a different execution path depending on
the underlying object represented by an interface.

Thus, Go carved out a useful niche for a robust switch statement.
Python used duck-typing instead of interfaces and generally
doesn't need any special syntax for type checks, hence Go's
version of switch doesn't make sense for Python, either.

Go's cases must be constants, and allows optional fallthrough
with the 'fallthrough' keyword. This forces them to provide break
semantics to break out of a switch, which makes using them to
break of an immediately outer loop messy.

> Dictionaries can't handle the uses where expression0 is
> constant and the case expressions are not. Function variables
> beg the question.  How did you decide what to assign to the
> variable?

A Python generator might take the place of that application, but
I haven't tried it for that.

> I'd use this select if it was in Python, but I don't see much
> need for it.

Same here. Perhaps the real value of a switch is that it seems to
be a more natural way of thinking about execution. The caveat to
that is most *actual* switch implementations are a mess.

-- 
Neil Cerutti

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

#59002

Am 09.11.2013 14:27 schrieb Joshua Landau:

> `select` is quite an odd statement, in that in most cases it's just a
> weaker variant of `if`. By the time you're at the point where a
> `select` is actually more readable you're also at the point where a
> different control flow is probably a better idea. Things like
> dictionaries or a variables pointing to functions are really useful
> and can be encapsulated in a class quite well. This is a bit more
> advanced but largely more rigorous.

class Switch(object):
     def __init__(self, value):
         self.value = value
         self.called = False
     def case(self, other):
         def wr(func):
             if not self.called and self.value == other:
                 self.called = True
                 return func(self.value)
         return wr
     def default(self, func):
         if not self.called:
             self.called = True
             return func(self.value)


if __name__ == '__main__':
     import random

     while 1:
         n = random.randrange(0, 5)
         sw = Switch (n)
         @sw.case(1)
         def _(n): print n, "is one"

         @sw.case(2)
         def _(n): print n, "is two"

         @sw.default
         def _(n): print n, "is something else"

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

#58937

On 09/11/2013 13:08, John von Horn wrote:
> Hi Everyone,
>
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
> enjoying working along to some youtube tutorials. I've done a little
> programming in the past.

If it's possible I'd strongly recommend Python 3.3, there's lots of 
goodies in there like vastly improved unicode handling.

>
> I've just got a few thoughts I'd like to share and ask about:
>
> * Why not allow floater=float(int1/int2) - rather than floater=float
> (int1)/float(int2)?

Surely this depends on the outcome that you actually want or am I 
missing the obvious?  Also note that integer division has been changed 
in Python 3.

>
> Give me a float (or an error message) from evaluating everything in the
> brackets. Don't make me explicitly convert everything myself (unless I
> want to)

You usually have to in Python, it's down to strong typing.

>
> * No sign of a select .. case statement

Loads of recipes online for this, ranging from specialised classes to my 
favourite which is spelt "dict".

>
> Another useful tool in the programmer's toolbox
>
> Select DayofWeek
>
> 	case "mon"
>
> 	...
>
> end select
>
> * Call me pedantic by why do we need a trailing comma for a list of one
> item? Keep it intuitive and allow lstShopping=[] or ["Bread"] or
> ["Bread", "Milk","Hot Chocolate"] I don't like ["Bread",]. It bugs me.

It should as it's not needed.  I'd guess you're confusing a tuple of one 
item with a list of one item?

>
> Just some initial thoughts. I just wanted to know the reasoning behind
> the above, be shown the shortcomings of my ignorance, pointed in the
> right direction. Let the High Priests of Python come forth and speak wise
> words and show me the ignorance of thy ways. Let my cup be filled to
> overflowing with your kind knowledge and wisdom.

Try "import this" from the Python interactive prompt for the Zen of Python.

>
> Is everyone happy with the way things are?

Yes thank you.

> Could anyone recommend a good,
> high level language for CGI work?

I can't comment as to whether or not Python is suitable for CGI work, 
I'll leave that to the experts.

> Not sure if I'm going to be happy with
> Perl (ahhh, get him, he's mentioned Perl and is a heretic!) or Python. I
> would very much value any constructive criticism or insights.

Fair enough, Python isn't for everybody.  I love it simply because it 
suits my mind set, hence I have www.python.org bookmarked as "Home Sweet 
Home".  I therefore believe it's safe to say that others hate it as it 
doesn't suit their mind sets.

>
> And a "thank you", ["sirs","madams"] but pls, not just ["sirs",]

Reread what I wrote above :)

>
> JvH
>

And check out my signature!!!

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#58941

John von Horn writes:

> Hi Everyone,
> 
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4)
> and am enjoying working along to some youtube tutorials. I've done a
> little programming in the past.
> 
> I've just got a few thoughts I'd like to share and ask about:
> 
> * Why not allow floater=float(int1/int2) - rather than floater=float
> (int1)/float(int2)?
> 
> Give me a float (or an error message) from evaluating everything in
> the brackets. Don't make me explicitly convert everything myself
> (unless I want to)

The guardians of the language agree with you and have changed this in
Python 3. You can import the change to 2.7 thus:

  >>> 31/41
  0
  >>> from __future__ import division
  >>> 31/41
  0.7560975609756098

> * No sign of a select .. case statement

I won't comment on that.

> * Call me pedantic by why do we need a trailing comma for a list of
> one item? Keep it intuitive and allow lstShopping=[] or ["Bread"] or
> ["Bread", "Milk","Hot Chocolate"] I don't like ["Bread",]. It bugs
> me.

Just write ["Bread"]. The comma is not needed.

Round brackets are used mainly for grouping expressions and calling
functions. Commas are used to separate function arguments and elements
of collections like lists, dictionaries, and sets, and to construct
tuples. The awkward case you have in mind is a one-element tuple that
has to be written with a trailing comma.

  >>> 3,
  (3,)
  >>> (3)
  3
  >>> 3,1
  (3, 1)
  >>> (3,1)
  (3, 1)

Best get used to that. It's just the optional trailing comma, but one
doesn't want just 3 or (3) interpreted as a tuple - not in Python
anyway - so in the one-element case optional becomes mandatory.

  >>> 3,1,
  (3, 1)

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

#58942

On Sun, Nov 10, 2013 at 12:08 AM, John von Horn <j.h69@btinternet.com> wrote:
> Hi Everyone,
>
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
> enjoying working along to some youtube tutorials. I've done a little
> programming in the past.

Hi! For myself, I've come from a background writing code in many other
languages (most notably C family), and I actually joined this list to
ask how to do something that turned out to be impossible[1]. Ended up
staying because the community's awesome. (Apart from a few. You know
who you are. :) )

> I've just got a few thoughts I'd like to share and ask about:
>
> * Why not allow floater=float(int1/int2) - rather than floater=float
> (int1)/float(int2)?
>
> Give me a float (or an error message) from evaluating everything in the
> brackets. Don't make me explicitly convert everything myself (unless I
> want to)

As others have said, what you're asking for is actually magic. One of
the rules of Python - one for which I'm not aware of any exceptions -
is that you can always take a subexpression out and give it a new
name:

floater = float(int1/int2)

temporary = int1/int2
floater = float(temporary

will do the exact same thing (modulo the retention of an
intermediate). This helps *HUGELY* with debugging, and it's part of a
general "no magic" policy. Sometimes there are other handy cases,
too... like that literals are nothing special, and that methods on
objects carry all the information they need:

>>> formatter = "Foo {} bar {} quux".format
>>> formatter("Asdf","Qwer")
'Foo Asdf bar Qwer quux'
>>> formatter("Hello","World")
'Foo Hello bar World quux'

I just created a function that's actually a method off a literal
string. (It returns a string. I'm doing this at the interactive
interpreter (REPL [2]), so the return values are being displayed.) As
far as the rest of the code's concerned, it's a function just like any
other. JavaScript doesn't do this. You can have closures, which carry
state about with them... but for some reason that completely escapes
my comprehension, methods aren't bound to the objects that called
them, so these two do quite different things:

document.getElementsByTagName("P");

var func = document.getElementsByTagName;
func("P");

That's magic, and IMHO not a good thing. So, getting back to your
query about floats... The only way for that to be not-magic would be
for the int-divided-by-int part to be not yet evaluated by the time
the float call happens. As others have pointed out, Python 3 has
int/int --> float, so *this specific* instance wouldn't apply. But the
same consideration applies to other types:

>>> import fractions
>>> fractions.Fraction(12345/54321)
Fraction(4093955369001953, 18014398509481984)

The division is done and results in either a float (Python 3, as shown
above) or an int (which would be 0). Either way, by the time the
Fraction constructor tries to figure out what value it's been given,
information has been lost (floats get rounded). The correct way to
create a Fraction is to pass it the numerator and denominator
separately:

>>> fractions.Fraction(12345,54321)
Fraction(4115, 18107)

This now has the exactly correct value (it cancelled the common prime
factor of 3 from both values). It's a small price to pay for a
guarantee of no-magic evaluation, and the awesome simplicity that that
gives.

> Just some initial thoughts. I just wanted to know the reasoning behind
> the above, be shown the shortcomings of my ignorance, pointed in the
> right direction. Let the High Priests of Python come forth and speak wise
> words and show me the ignorance of thy ways. Let my cup be filled to
> overflowing with your kind knowledge and wisdom.

I like that attitude: "This seems odd, so I'll ask why, because that
way I'll learn something". Some of us have worked with a large number
of different programming languages, others have a background in
mathematics (Steven D'Aprano, who'll probably post a response in this
thread before long, recently contributed a shiny new statistics module
to the Python standard library), still others have been working in
computers so long that they've become them (okay, not quite). Maybe
none of us is a High Priest of this language, but we all have our own
perspectives on what works and what doesn't, so pretty much any
question is going to get some responses. :)

> Is everyone happy with the way things are? Could anyone recommend a good,
> high level language for CGI work? Not sure if I'm going to be happy with
> Perl (ahhh, get him, he's mentioned Perl and is a heretic!) or Python. I
> would very much value any constructive criticism or insights.

No, not everyone's happy with the way things are. If we were, where
would Python 3.4 come from? :)

If by CGI you actually literally mean CGI, then most of us don't have
any experience with it. But if you mean more generally "code executed
on the fly to create a web page", there are quite a few options. Some
of us have worked with, again, a variety of languages (I just quit/got
fired from a job involving PHP; my boss couldn't understand why I so
strongly disliked PHP, despite lengthy explanations), and even within
one language there are often multiple ways to do things (Python web
frameworks are a huge thing all of their own). I would recommend
setting down more of your requirements, then going through the
languages and frameworks you know of and ticking the boxes as much as
you can. When you've finished that exercise, you might have something
like "I could use Django, except that it doesn't do XYZ for me", which
would make a perfect python-list thread, or "I could use PHP, except
that the hammer has two claws on it[3]", which wouldn't. :)

Welcome to Python, and to python-list. You'll find us all fairly
opinionated, but as long as you're willing to learn, we'll be more
than happy to explain things :)

ChrisA
[1] For the curious, I was trying to sandbox CPython and run untrusted
scripts while stopping them from accessing the OS or file system. It's
basically impossible, so we switched to embedding JavaScript instead.
[2] Read/Evaluate/Print Loop. Something I'd consider fairly standard
now for an interactive interpreter. PHP's interactive mode is a
Read/Eval Loop, so you have to explicitly print things - seems like a
trivial difference, but it affects productivity hugely, especially
when you didn't compile in GNU Readline support.
[3] http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
and when you've read that,
http://www.flickr.com/photos/raindrift/sets/72157629492908038

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

#58948 — Sandboxing Python [was Re: New user's initial thoughts / criticisms of Python]

On Sun, 10 Nov 2013 01:27:11 +1100, Chris Angelico wrote:

> I was trying to sandbox CPython and run untrusted scripts while stopping
> them from accessing the OS or file system. It's basically impossible

PyPy is supposed to come with a proper sandbox. Although even in that 
case, I think it is recommended to use a chroot jail to lock access down 
to some subset of the file system.


-- 
Steven

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

#58951 — Re: Sandboxing Python [was Re: New user's initial thoughts / criticisms of Python]

On Sun, Nov 10, 2013 at 2:25 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 10 Nov 2013 01:27:11 +1100, Chris Angelico wrote:
>
>> I was trying to sandbox CPython and run untrusted scripts while stopping
>> them from accessing the OS or file system. It's basically impossible
>
> PyPy is supposed to come with a proper sandbox. Although even in that
> case, I think it is recommended to use a chroot jail to lock access down
> to some subset of the file system.

Yeah, which means that even that wouldn't be sufficient for our
purposes (since part of the spec is that there should be fast and
efficient data transfer between the untrusted code and the main
engine, which has full FS access). That's why we switched away from
Python altogether. Though I think my boss would have benefited from
being forced to learn Python.

ChrisA

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

#58990

On Sat, 2013-11-09, Chris Angelico wrote:
> On Sun, Nov 10, 2013 at 12:08 AM, John von Horn <j.h69@btinternet.com> wrote:
...
>> * Why not allow floater=float(int1/int2) - rather than floater=float
>> (int1)/float(int2)?
>>
>> Give me a float (or an error message) from evaluating everything in the
>> brackets. Don't make me explicitly convert everything myself (unless I
>> want to)
>
> As others have said, what you're asking for is actually magic. One of
> the rules of Python - one for which I'm not aware of any exceptions -
> is that you can always take a subexpression out and give it a new
> name:

And it's not just Python: programming languages have been designed
that way since at least the 1960s.  People are used to analysing
expressions inside and out according to rules common for almost all
languages.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#58995

On Sun, Nov 10, 2013 at 7:47 PM, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Sat, 2013-11-09, Chris Angelico wrote:
>> On Sun, Nov 10, 2013 at 12:08 AM, John von Horn <j.h69@btinternet.com> wrote:
> ...
>>> * Why not allow floater=float(int1/int2) - rather than floater=float
>>> (int1)/float(int2)?
>>>
>>> Give me a float (or an error message) from evaluating everything in the
>>> brackets. Don't make me explicitly convert everything myself (unless I
>>> want to)
>>
>> As others have said, what you're asking for is actually magic. One of
>> the rules of Python - one for which I'm not aware of any exceptions -
>> is that you can always take a subexpression out and give it a new
>> name:
>
> And it's not just Python: programming languages have been designed
> that way since at least the 1960s.  People are used to analysing
> expressions inside and out according to rules common for almost all
> languages.

That's true to at least some extent, but quite a few languages have
differences here and there. In C, there's no such thing as an array
literal, only an initializer list, so:

/* This works: */
int month_days[] = {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
int this_month_days = month_days[this_month];

/* This doesn't: */
int three = {1, 2, 3, 4, 5}[2];

PHP had similar issues up until a *very* recent version (5.3 or 5.4 or
something), where you couldn't dereference an array returned by a
function:

//Works:
$arr = func();
$val = $arr[5];

//Didn't work until recently, and therefore can't be trusted for
//deployment to random systems across the internet:
$val = func()[5];

JavaScript has magic around the dot and function-call operators, as I
mentioned earlier. Lots of other languages have some little quirk
somewhere that breaks this rule; some have a LOT of quirks that break
this rule. Does Python have any? Aside from parsing oddities like
attribute access on a literal integer[1], are there any cases where
two expressions yielding the same object are in any way different?

ChrisA
[1] You can write "(1234).to_bytes(2,'big')" but omitting the parens
gives a SyntaxError because it looks like the start of a float
literal.

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

#59000

On Sun, Nov 10, 2013 at 2:22 AM, Chris Angelico <rosuav@gmail.com> wrote:
> JavaScript has magic around the dot and function-call operators, as I
> mentioned earlier. Lots of other languages have some little quirk
> somewhere that breaks this rule; some have a LOT of quirks that break
> this rule. Does Python have any? Aside from parsing oddities like
> attribute access on a literal integer[1], are there any cases where
> two expressions yielding the same object are in any way different?

I can think of one:

class Spam:
    def __init__(self):
        super().__init__()  # This works.

sup = super

class Eggs:
    def __init__(self):
        sup().__init__()  # This doesn't.

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

#59001

On Sun, Nov 10, 2013 at 10:39 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sun, Nov 10, 2013 at 2:22 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> JavaScript has magic around the dot and function-call operators, as I
>> mentioned earlier. Lots of other languages have some little quirk
>> somewhere that breaks this rule; some have a LOT of quirks that break
>> this rule. Does Python have any? Aside from parsing oddities like
>> attribute access on a literal integer[1], are there any cases where
>> two expressions yielding the same object are in any way different?
>
> I can think of one:
>
> class Spam:
>     def __init__(self):
>         super().__init__()  # This works.
>
> sup = super
>
> class Eggs:
>     def __init__(self):
>         sup().__init__()  # This doesn't.

Ah, yes, super() is magical. In that particular instance, I think the
magic is better than the alternative, but let's face it: Multiple
inheritance is an inherently hard problem, so a solution that has so
little magic and manages to achieve the goal is doing well. The only
thing that would have been better than this would be making it a piece
of special syntax rather than something that looks like a function
call, but it's too late to change now.

ChrisA

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

#59017

On Sun, 10 Nov 2013 20:22:56 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following:

>[1] You can write "(1234).to_bytes(2,'big')" but omitting the parens
>gives a SyntaxError because it looks like the start of a float
>literal.

	Ah, but...

>>> -123.bit_length()
Traceback (  File "<interactive input>", line 1
    -123.bit_length()
                  ^
SyntaxError: invalid syntax
>>> (-123).bit_length()
7
>>> -123 .bit_length()
-7

	No parens needed if a space precedes the .

	But note the order of evaluation is equivalent to

>>> -(123 .bit_length())
-7
>>> 
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#59031

On Mon, Nov 11, 2013 at 4:12 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
>>>> -123 .bit_length()
> -7
>
>         No parens needed if a space precedes the .

Heh! I would call that an inferior alternative to the parentheses
though; it's so unusual to put a space before the dot that I wouldn't
consider it something to do in normal code. Anyone coming through and
editing would see it as a mistake to be fixed.

ChrisA

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web