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

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

Promoting Python

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

  Promoting Python "Gordon( Hotmail )" <sionet3344@hotmail.co.uk> - 2016-04-05 06:48 +0100
    Re: Promoting Python Rustom Mody <rustompmody@gmail.com> - 2016-04-05 00:31 -0700
      Re: Promoting Python Joel Goldstick <joel.goldstick@gmail.com> - 2016-04-05 08:06 -0400
        Re: Promoting Python alister <alister.ware@ntlworld.com> - 2016-04-05 18:02 +0000
          Re: Promoting Python BartC <bc@freeuk.com> - 2016-04-05 19:47 +0100
            Re: Promoting Python alister <alister.ware@ntlworld.com> - 2016-04-05 19:38 +0000
      Re: Promoting Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-05 08:13 -0400
        Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-05 15:31 +0300
    Re: Promoting Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-06 20:52 +1200
      Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 12:12 +0300
    Re: Promoting Python BartC <bc@freeuk.com> - 2016-04-06 12:06 +0100
      Re: Promoting Python Ned Batchelder <ned@nedbatchelder.com> - 2016-04-06 04:38 -0700
        Re: Promoting Python BartC <bc@freeuk.com> - 2016-04-06 14:21 +0100
      Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 14:46 +0300
        Re: Promoting Python Michael Selik <michael.selik@gmail.com> - 2016-04-06 13:33 +0000
          Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 17:14 +0300
            Re: Promoting Python Chris Angelico <rosuav@gmail.com> - 2016-04-07 00:20 +1000
              Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 21:23 +0300
                Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 21:50 +0300
                Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 22:30 +0300
            Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 22:22 +0300
              Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 22:59 +0300
                Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 23:39 +0300
                  Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-07 01:03 +0300
                    Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-07 09:30 +0300
                      Re: Promoting Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-04-07 00:56 -0600
                        Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-07 10:19 +0300
                          Re: Promoting Python Steven D'Aprano <steve@pearwood.info> - 2016-04-08 16:09 +1000
            Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 23:05 +0300
        Re: Promoting Python BartC <bc@freeuk.com> - 2016-04-06 14:54 +0100
          Re: Promoting Python Marko Rauhamaa <marko@pacujo.net> - 2016-04-06 17:08 +0300
            Re: Promoting Python Larry Martell <larry.martell@gmail.com> - 2016-04-06 10:36 -0400
          Re: Promoting Python Chris Angelico <rosuav@gmail.com> - 2016-04-07 00:14 +1000
          Re: Promoting Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-04-06 15:20 +0100
            Re: Promoting Python Ned Batchelder <ned@nedbatchelder.com> - 2016-04-06 07:34 -0700
              Re: Promoting Python Ned Batchelder <ned@nedbatchelder.com> - 2016-04-06 10:55 -0700
                Re: Promoting Python BartC <bc@freeuk.com> - 2016-04-06 23:24 +0100
            Re: Promoting Python BartC <bc@freeuk.com> - 2016-04-06 18:04 +0100
      Re: Promoting Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-06 08:04 -0400
      Re: Promoting Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-04-06 13:39 +0100
      Re: Promoting Python Steven D'Aprano <steve@pearwood.info> - 2016-04-07 03:40 +1000

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

#106596

Ian Kelly <ian.g.kelly@gmail.com>:

> On Wed, Apr 6, 2016 at 8:14 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Now, if Python had an unlimited range() iterator/iterable, you could use
>> a "for" statement to emulate "while".
>
> You can already do this.
>
>>>> class While:
> ...     def __init__(self, predicate):
> ...         self._predicate = predicate
> ...         self._exited = False
> ...     def __iter__(self):
> ...         return self
> ...     def __next__(self):
> ...         if self._exited or not self._predicate():
> ...             self._exited = True
> ...             raise StopIteration
> ...
>>>> i = 0
>>>> for _ in While(lambda: i < 10):
> ...     print(i)
> ...     i += 1
> ...
> 0
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9

Impressive!

>> As it stands, Python without "while" could only compute
>> primitive-recursive functions. However, you only need "while" a
>> maximum of one time in your whole program to perform an arbitrary
>> computation.
>
> So this is wrong.

I stand corrected.

However, BartC's No-Buzzword Python doesn't have classes... If he
allowed for types.SimpleNamespace, we could have:

========================================================================
import types

def While(predicate):
    def __iter__():
        return thingy
    def __next__():
        if thingy._exited or not predicate():
            thingy._exited = True
            raise StopIteration
    thingy = types.SimpleNamespace(
        _exited=False, __iter__=__iter__, __next__=__next__)
    return thingy
========================================================================

However, that results in:

    TypeError: 'types.SimpleNamespace' object is not iterable

Where's my bug? Or is CPython buggy? Or is it the documentation:

    The iterator objects themselves are required to support the
    following two methods, which together form the iterator protocol:

    iterator.__iter__()

    [...]

    iterator.__next__()

    <URL: https://docs.python.org/3/library/stdtypes.html#typeiter>

Why is a SimpleNamespace object not an iterator even though it provides
__iter__ and __next__?


Marko

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

#106600

Ian Kelly <ian.g.kelly@gmail.com>:

> On Wed, Apr 6, 2016 at 1:22 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Why is a SimpleNamespace object not an iterator even though it
>> provides __iter__ and __next__?
>
> Because Python expects those methods to be defined in the class dict,
> not the instance dict.

The documentation does state: 

   these are used to allow user-defined classes to support iteration

although the rest of it only refers to objects.

It seems to me CPython is being a bit too picky here. Why should it care
if the method is a class method or an object method?

Anyway, that leaves the clever iterator trick out of No-Buzzword Python.


Marko

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

#106604

Ian Kelly <ian.g.kelly@gmail.com>:

> On Wed, Apr 6, 2016 at 1:59 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> It seems to me CPython is being a bit too picky here. Why should it
>> care if the method is a class method or an object method?
>
> Because the purpose of a class is to define the behavior of its
> instances. A function stored in an object attribute technically isn't
> a method at all. It's just a function that happens to be stored in an
> object attribute, i.e. *data*. Why should the behavior of a
> SimpleNamespace change just because somebody decided they wanted to
> store something under the name "__iter__" (or worse,
> "__getattribute__")?
>
> Also, because not having to check the instance dict for the presence
> of dunder methods is faster.

Not convinced. Probably just an oversight.

For example, file-like objects have no such reservations:

    import sys
    import types
    import xml.dom.minidom

    filelike = types.SimpleNamespace()
    def write(s):
        for c in s:
            sys.stdout.write("{{{}}}".format(c))
    filelike.write = write
    filelike.close = lambda: None
    doc = xml.dom.minidom.getDOMImplementation().createDocument(
        None, "tag", None).writexml(filelike)
    sys.stdout.write("\n")



Marko

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

#106605

Ian Kelly <ian.g.kelly@gmail.com>:

> On Wed, Apr 6, 2016 at 2:39 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Not convinced. Probably just an oversight.
>
> It's documented here:
> https://docs.python.org/3/reference/datamodel.html#special-method-lookup

Ok, not an oversight but some inherent trouble with the way object
methods are related with their prototypes in the class. An unexpected
deficiency in the object-class relationship of sorts.

> The minidom implementation is probably just calling
> filelike.write('blah'). That will succeed in calling either a method
> or a function-in-an-attribute. Note that the write function you
> defined in this example has no self argument. This points to the fact
> that it's not truly a method.

No true Scotsman, there?

Once you look up an object method, it doesn't have a self argument. The
self argument is cooked up for the benefit of the function definition in
the class.

IOW, if I have this class:

    class A:
        def f(self):
            print("f")

and this object:

    a = A()

then,

    a.f

is a function that doesn't have a self argument. That function is
generated on the fly, and it delegates to A.f, providing it with self
argument.

However, a.f itself is just a function that doesn't accept any
arguments.

Defining:

    def f():
        print("f")
    a.f = f

simply short-circuits the attribute lookup process; no need to consult
the class when the attribute (method!) is right there in the object's
dict.


Marko

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

#106613

Rolf Camps <rolf@roce.be>:

> Op 07-04-16 om 00:03 schreef Marko Rauhamaa:
>> IOW, if I have this class:
>>
>>      class A:
>>          def f(self):
>>              print("f")
>>
>> and this object:
>>
>>      a = A()
>>
>> then,
>>
>>      a.f
>>
>> is a function that doesn't have a self argument. That function is
>> generated on the fly, and it delegates to A.f, providing it with self
>> argument.
> a.f is not a function, A.f is a function.
> a.f is an instance method. The function is not generated on the fly,
> when the method is called, it calls the function A.f with an extra
> argument __self__ (the instance a) inserted before the argument list the
> instance method was called with.

What you call an instance method *is* a function, meaning it is bound to
a callable object that in almost no outward way differs from any other
function.

It is generated on the fly:

   >>> id(a.f)
   140059683793288
   >>> id(a.f)
   140059683793864
   >>> a.f is a.f
   False

You are correct that the generated function is a simple trampoline that
supplies a self argument and delegates to A.f.

Or:

   When a class attribute reference (for class C, say) would yield a
   class method object, it is transformed into an instance method object
   whose __self__ attributes is C.
   <URL: https://docs.python.org/3/reference/datamodel.html?highlight=__g
   etattr__#the-standard-type-hierarchy>

So the only difference between a regular function and an instance method
object is the fact that the latter has a __self__ attribute set.

Although even that small difference can be paved over:

    def g():
        print("g")
    g.__self__ = a
    a.f = g


Marko

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

#106617

On Thu, Apr 7, 2016 at 12:30 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Or:
>
>    When a class attribute reference (for class C, say) would yield a
>    class method object, it is transformed into an instance method object
>    whose __self__ attributes is C.
>    <URL: https://docs.python.org/3/reference/datamodel.html?highlight=__g
>    etattr__#the-standard-type-hierarchy>
>
> So the only difference between a regular function and an instance method
> object is the fact that the latter has a __self__ attribute set.
>
> Although even that small difference can be paved over:
>
>     def g():
>         print("g")
>     g.__self__ = a
>     a.f = g

What is this example supposed to accomplish?  Functions don't merely
not have a __self__ attribute set. The __self__ attribute has no
meaning on a function.

Let's take a different example.


class Dialog(Window):

    def __init__(self, parent, title, ok_callback):
        super().__init__(parent, title)
        self._ok_callback = ok_callback
        self._ok_button = Button(self, 'Ok')
        self._ok_button.bind(self._ok_callback)

def f(event):
    print("Hello world")

dialog = Dialog(None, "Example", f)
dialog.show()


Are you suggesting that dialog._ok_callback should be considered a
method of Dialog, despite the fact that the implementation of Dialog
and the implementation of f are entirely unrelated? If so, then I
think that most OOP practitioners would disagree with you.

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

#106619

Ian Kelly <ian.g.kelly@gmail.com>:

> Let's take a different example.
>
> class Dialog(Window):
>
>     def __init__(self, parent, title, ok_callback):
>         super().__init__(parent, title)
>         self._ok_callback = ok_callback
>         self._ok_button = Button(self, 'Ok')
>         self._ok_button.bind(self._ok_callback)
>
> def f(event):
>     print("Hello world")
>
> dialog = Dialog(None, "Example", f)
> dialog.show()
>
> Are you suggesting that dialog._ok_callback should be considered a
> method of Dialog, despite the fact that the implementation of Dialog
> and the implementation of f are entirely unrelated? If so, then I
> think that most OOP practitioners would disagree with you.

First, terminology disputes are pointless.

No, I would never call f a method of Dialog. I might call it a method of
dialog, though.

A method is simply a callable attribute:

   Procedures in object-oriented programming are known as methods
   <URL: https://en.wikipedia.org/wiki/Object-oriented_programming>

(Now, in CLOS, GOOPS etc, methods are not attributes at all, but that's
another story.)


Marko

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

#106649

On Thu, 7 Apr 2016 05:19 pm, Marko Rauhamaa wrote:

> First, terminology disputes are pointless.

I agree! There's nothing I like more than sitting in front of a blazing open
fire (or even just a warm heater) on a cold winter's evening, drinking a
nice mug of piping hot terminology dispute. Sometimes I put marshmallows in
it. That makes it even more pointless.

I have to be careful around my wife though, she's life-threateningly
allergic to all dispute products. (Technically, she can eat white dispute,
so long as it is 100% cocoa-free, but she doesn't see the point.)

.
.
.
.


Having trouble understanding what the hell I'm talking about? That's what
happens when somebody in a conversation is using unexpected terminology. To
the extent that terminology disputes resolve misuses and misunderstandings
about terminology, they simplify communication and make it easier to
communicate, not harder. The very opposite of pointless.


-- 
Steven

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

#106601

Terry Reedy <tjreedy@udel.edu>:

> On 4/6/2016 10:14 AM, Marko Rauhamaa wrote:
>
>> Seriously, Python wouldn't be, couldn't be Turing-complete without
>> "while" (mainly because it doesn't support tail-recursion
>> elimination).
>>
>> Now, if Python had an unlimited range() iterator/iterable, you could
>> use a "for" statement to emulate "while".
>
> For practical purposes, this equals 'while True: pass'
>
> for i in itertools.count: pass
>
> This is equivalent, regardless of memory.
>
> class whiletrue:
>     def __iter__(self): return self
>     def __next__(self): return None
>
> for none in whiletrue(): pass

By George, she's got it!

    i = 0
    for _ in itertools.count():
        if i >= 10:
            break
        print(i)
        i += 1

That is, assuming "break" is allowed.


Marko

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

#106578

On 06/04/2016 12:46, Marko Rauhamaa wrote:
> BartC <bc@freeuk.com>:

>> It'll cope with ordinary coding as well, although such programs seem
>> to be frowned upon here; they are not 'Pythonic'.
>
> I wonder what is left of Python after your list of exclusions.

There are plenty of features that /I/ consider must-have, which Python 
doesn't have. It has to emulate them, unsatisfactorily, with variables 
or classes or functions, or do without.

But you're right in that little is actually essential. Basic has shown that.

You need expressions, IF, GOTO, variables and assignments, and some 
means of doing I/O.

Pretty much every language has (had) those, although it's fashionable 
now to do away with GOTO, and some are getting rid of (rewritable) 
variables too! Others seem intent on doing away with control flow 
altogether, just having expressions. Apparently they think coding should 
become more elitist with only mathematicians allowed to participate.

I have the opposite view.


-- 
Bartc

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

#106579

BartC <bc@freeuk.com>:

> But you're right in that little is actually essential. Basic has shown
> that.
>
> You need expressions, IF, GOTO, variables and assignments, and some
> means of doing I/O.
>
> Pretty much every language has (had) those, although it's fashionable
> now to do away with GOTO, and some are getting rid of (rewritable)
> variables too! Others seem intent on doing away with control flow
> altogether, just having expressions. Apparently they think coding
> should become more elitist with only mathematicians allowed to
> participate.

Oh, I'm also in the minimalist camp. Let me introduce you to the
simplest imaginable fully-featured programming language, iota:

   <URL: http://semarch.linguistics.fas.nyu.edu/barker/Iota/>

When I first ran into iota, my mind was blown. Also, follow the link to
zot:

   <URL: http://semarch.linguistics.fas.nyu.edu/barker/Iota/zot.html>


Marko

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

#106586

On Wed, Apr 6, 2016 at 10:08 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> BartC <bc@freeuk.com>:
>
>> But you're right in that little is actually essential. Basic has shown
>> that.
>>
>> You need expressions, IF, GOTO, variables and assignments, and some
>> means of doing I/O.
>>
>> Pretty much every language has (had) those, although it's fashionable
>> now to do away with GOTO, and some are getting rid of (rewritable)
>> variables too! Others seem intent on doing away with control flow
>> altogether, just having expressions. Apparently they think coding
>> should become more elitist with only mathematicians allowed to
>> participate.
>
> Oh, I'm also in the minimalist camp. Let me introduce you to the
> simplest imaginable fully-featured programming language, iota:
>
>    <URL: http://semarch.linguistics.fas.nyu.edu/barker/Iota/>
>
> When I first ran into iota, my mind was blown. Also, follow the link to
> zot:
>
>    <URL: http://semarch.linguistics.fas.nyu.edu/barker/Iota/zot.html>

https://en.wikipedia.org/wiki/INTERCAL

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

#106581

On Wed, Apr 6, 2016 at 11:54 PM, BartC <bc@freeuk.com> wrote:
> There are plenty of features that /I/ consider must-have, which Python
> doesn't have. It has to emulate them, unsatisfactorily, with variables or
> classes or functions, or do without.

Blub's Paradox epitomized.

> But you're right in that little is actually essential. Basic has shown that.

Actually, BASIC has a lot that isn't essential. A Turing-complete
language can be implemented with just three tokens, although that's
slightly cheating; they form eight opcodes (by being used in pairs).

http://www.dangermouse.net/esoteric/ook.html

> You need expressions, IF, GOTO, variables and assignments, and some means of
> doing I/O.

Depending on your meaning of "language", I would say that I/O does
*not* have to be an intrinsic part of it - it can be implemented far
more cleanly with built-in functions. Python 2 gave good syntactic
support to printing to the console, and messy syntactic support to
printing elsewhere, but Python 3 proved that it's not only
unnecessary, but counter-productive - it's better to push that to
regular functions.

Technically, expressions aren't required. However, a modern imperative
language will normally have expression support because it's so, well,
expressive.

Variable assignment, yes. And you need some form of flow control
(either 'if' or 'while').

> Pretty much every language has (had) those, although it's fashionable now to
> do away with GOTO, and some are getting rid of (rewritable) variables too!
> Others seem intent on doing away with control flow altogether, just having
> expressions. Apparently they think coding should become more elitist with
> only mathematicians allowed to participate.
>
> I have the opposite view.

Or maybe they think that coding should become more accessible to
people with a strong mathematical background. There was a time when
programming was a thing that only programmers did; that time is no
more. A brilliant physicist who sets up synchrotron experiments should
be able to learn enough Python to tinker with his simulation code; a
mathematician who devises cryptographic algorithms should be able to
transfer the algebraic notes directly into code. A language that makes
it easier to translate algebra into executable code is *easier*, not
harder, for those kinds of people. It might be harder *for you*, but
that just proves that, once again, you don't like what you don't
understand, and it scares you, and this feature is mysterious at
least. [1] Also, languages with no mutable state and everything
implemented as expressions lend themselves well to massive
parallelization; the compiler can look at the code and see easily that
these two subexpressions are entirely independent, and evaluate them
in parallel. That's pretty powerful.

Welcome to Blub's Paradox, once again.

ChrisA

[1] https://youtu.be/xCENkwPiuU0?t=1m59s

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

#106584

On 06/04/2016 14:54, BartC wrote:
> On 06/04/2016 12:46, Marko Rauhamaa wrote:
>> BartC <bc@freeuk.com>:
>
>>> It'll cope with ordinary coding as well, although such programs seem
>>> to be frowned upon here; they are not 'Pythonic'.
>>
>> I wonder what is left of Python after your list of exclusions.
>
> There are plenty of features that /I/ consider must-have, which Python
> doesn't have. It has to emulate them, unsatisfactorily, with variables
> or classes or functions, or do without.

Please list all these features.  Precisely what is unsatisfactory about 
the emulation?  Please state why you're still here if Python is such a 
poorly designed language that it doesn't fit your needs.  Or is it 
simply that your mindset cannot get to grips with something that is 
different to that you've previously used?

>
> But you're right in that little is actually essential. Basic has shown
> that.
>
> You need expressions, IF, GOTO, variables and assignments, and some
> means of doing I/O.

Are you suggesting that 21st century programming should return to the 
era of spaghetti code?

>
> Pretty much every language has (had) those, although it's fashionable
> now to do away with GOTO, and some are getting rid of (rewritable)
> variables too!

It's 50 years to my knowledge since the first paper stating that GOTO 
isn't needed, hardly "fashionable now".  I get a very strong impression 
that you've never had to maintain appalingly written code.  The overuse 
of GOTO will certainly help in that area.  How does it go, something 
like "always consider that the person maintaining your code in six 
months time is a homicidal maniac armed with an axe"?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#106585

On Wednesday, April 6, 2016 at 10:25:13 AM UTC-4, Mark Lawrence wrote:
> On 06/04/2016 14:54, BartC wrote:
> > On 06/04/2016 12:46, Marko Rauhamaa wrote:
> >> BartC <bc@freeuk.com>:
> >
> >>> It'll cope with ordinary coding as well, although such programs seem
> >>> to be frowned upon here; they are not 'Pythonic'.
> >>
> >> I wonder what is left of Python after your list of exclusions.
> >
> > There are plenty of features that /I/ consider must-have, which Python
> > doesn't have. It has to emulate them, unsatisfactorily, with variables
> > or classes or functions, or do without.
> 
> Please list all these features.  Precisely what is unsatisfactory about 
> the emulation?  Please state why you're still here if Python is such a 
> poorly designed language that it doesn't fit your needs.  Or is it 
> simply that your mindset cannot get to grips with something that is 
> different to that you've previously used?

No, please, let's not ask BartC to list these features.  We've already
well established Bart's point of view, let's not revisit this debate.
He prefers very different languages than Python.  We get it.  We don't
have to try to convince him to like Python, it's been tried, it doesn't
work.

--Ned.

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

#106592

On Wednesday, April 6, 2016 at 10:40:36 AM UTC-4, Mark Lawrence wrote:
> On 06/04/2016 15:34, Ned Batchelder wrote:
> > No, please, let's not ask BartC to list these features.  We've already
> > well established Bart's point of view, let's not revisit this debate.
> > He prefers very different languages than Python.  We get it.  We don't
> > have to try to convince him to like Python, it's been tried, it doesn't
> > work.
> >
> > --Ned.
> >
> 
> So why isn't he politely told to shove off as he's not welcome on this 
> Python list?

Because there's no purity test for membership here.  You can dislike Python,
and still participate. Bart is not unwelcome.

I did take issue with his mischaracterization of Python's terminology, and
it worked out fine.

It took us a while to understand where Bart was coming from, but now we
understand, and we don't have to go around in circles.

> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.

You can be welcoming and understanding.

--Ned.

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

#106606

On 06/04/2016 21:38, Mark Lawrence wrote:

> No it didn't, it was quite clear from the beginning that he knew squat,
> and since then he's admitted that he knows squat.  About Python.

I see. According to you:

(1) To have an opinion about a language, you have to know everything in 
it 100%, inside out and backwards.

(2) It's impossible for someone who's coded for decades to switch to a 
different language, just by familiarising themselves with the 
'controls', as people do when driving a different vehicle

(3) The only people who can give advice to newcomers in a language are 
complete experts in it, and not those who have experienced some of the 
same problems.


> On the
> main Python list.

I'm posting to a usenet group. I haven't subscribed to any list.

AFAIK this is a public group where anyone can post.

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

#106589

On 06/04/2016 15:20, Mark Lawrence wrote:
> On 06/04/2016 14:54, BartC wrote:

>Please state why you're still here if Python is such a
> poorly designed language that it doesn't fit your needs.

I was replying to the OP who was being put off the language. The vast 
majority have to choose an off-the-shelf language, and in that 
situation, Python is probably one of the best choices for someone 
progressing from Basic.

It might have been difficult to tell, but I was /for/ Python in that 
post, not against it. But I'm not afraid to mention cons as well as pros.

 > Or is it
 > simply that your mindset cannot get to grips with something that is
 > different to that you've previously used?

(I've actually implemented versions of 3 or 4 of the 8 things I listed. 
Coming up with and implementing this stuff is fun (and I can see how 
languages and libraries can end up brimming full of every possible 
feature you can think of). But ending up with a new must-have feature 
that is used all the time is harder.)

>> Pretty much every language has (had) those, although it's fashionable
>> now to do away with GOTO, and some are getting rid of (rewritable)
>> variables too!
>
> It's 50 years to my knowledge since the first paper stating that GOTO
> isn't needed, hardly "fashionable now".

I mean for it it to disappear completely from languages.

> I get a very strong impression
> that you've never had to maintain appalingly written code.  The overuse
> of GOTO will certainly help in that area.

(I've not defending its use, but there are good reasons for retaining it.

Suppose you had the job of translating language X to Y. X contains 
control structures that don't exist in Y. Or it maybe it just uses GOTO. 
Would the task be easier if Y had GOTO, or without?)

-- 
Bartc

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

#106568

On Wed, 6 Apr 2016 12:06:10 +0100, BartC <bc@freeuk.com> declaimed the
following:


>Last time I looked, there seemed to be around 250 dialects of Basic, and 
>with wildly differing implementations from pure interpreters to full 
>compilers, from GWBASIC to .NET. (Is there even an official standard?)
>
	If one trusts Wikipedia -- there are two: "minimal BASIC" and "full
BASIC"... I don't intend to fork over the money to get a copy though.
Though they haven't been updated in some time: minimal is 1978, and full is
1987. Believe they are based on K&K/Dartmouth BASIC. Probably require line
numbers and have no graphics.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#106570

On 06/04/2016 12:06, BartC wrote:
> On 05/04/2016 06:48, Gordon( Hotmail ) wrote:
>> I am struggling to understand the basic principles of Python having
>> spent many years as a pure Amateur tinkering with a variety of BASIC
>
> Last time I looked, there seemed to be around 250 dialects of Basic, and
> with wildly differing implementations from pure interpreters to full
> compilers, from GWBASIC to .NET. (Is there even an official standard?)
>
> With Python there are two dialects, and it's often already installed on
> a system (probably not on Windows though). There are a few different
> implementations too, but code I think is largely compatible across them.
>
>> The problem I am finding is most of the sites claiming to help
>> understand Python devote
>> far too much space bragging about the wonders of Python instead of...

See if you can find one or more here 
http://noeticforce.com/best-free-tutorials-to-learn-python-pdfs-ebooks-online-interactive 
that suits.

>
> I fully agree. But you don't have to use classes, exceptions,
> decorators, generators, iterators, closures, comprehensions, meta
> classes, ... the list of meaningless buzzwords just goes on.

You were five days late.

>
> It'll cope with ordinary coding as well, although such programs seem to
> be frowned upon here; they are not 'Pythonic'.
>

How can you (plural) write Python code when you don't know Python?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

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

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

csiph-web