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


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

What is considered an "advanced" topic in Python?

Started byMike Driscoll <kyosohma@gmail.com>
First post2015-05-29 09:01 -0700
Last post2015-06-01 23:30 -0400
Articles 20 on this page of 73 — 28 participants

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


Contents

  What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 09:01 -0700
    Re: What is considered an "advanced" topic in Python? Joel Goldstick <joel.goldstick@gmail.com> - 2015-05-29 12:08 -0400
      Re: What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 09:55 -0700
    Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-30 02:09 +1000
      Re: What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 09:57 -0700
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-30 03:08 +1000
        Re: What is considered an "advanced" topic in Python? random832@fastmail.us - 2015-05-31 23:18 -0400
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-01 13:43 +1000
        Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 09:58 +0200
          Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 12:36 +0300
            Zero [was Re: What is considered an "advanced" topic in Python?] Steven D'Aprano <steve@pearwood.info> - 2015-06-01 22:07 +1000
              Re: Zero [was Re: What is considered an "advanced" topic in Python?] Laura Creighton <lac@openend.se> - 2015-06-01 14:52 +0200
              Re: Zero [was Re: What is considered an "advanced" topic in Python?] Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-06-01 13:56 +0100
                Re: Zero [was Re: What is considered an "advanced" topic in Python?] Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-01 08:14 -0500
                  Re: Zero [was Re: What is considered an "advanced" topic in Python?] Dave Farrance <df@see.replyto.invalid> - 2015-06-01 15:39 +0100
                Re: Zero [was Re: What is considered an "advanced" topic in Python?] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-01 18:35 +0100
                Re: Zero [was Re: What is considered an "advanced" topic in Python?] Terry Reedy <tjreedy@udel.edu> - 2015-06-01 17:32 -0400
              Re: Zero [was Re: What is considered an "advanced" topic in Python?] Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 16:18 +0300
                Re: Zero [was Re: What is considered an "advanced" topic in Python?] random832@fastmail.us - 2015-06-01 09:32 -0400
          Re: What is considered an "advanced" topic in Python? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-06-01 11:44 +0100
            Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 13:54 +0300
          Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-06-01 22:33 -0700
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-01 19:45 +1000
        Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 12:28 +0200
          Re: What is considered an "advanced" topic in Python? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-01 14:22 +0100
        Re: What is considered an "advanced" topic in Python? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-01 11:34 +0100
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-01 20:36 +1000
        Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 13:00 +0200
        Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 13:24 +0200
          Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 14:57 +0300
            Re: What is considered an "advanced" topic in Python? BartC <bc@freeuk.com> - 2015-06-01 13:27 +0100
            Re: What is considered an "advanced" topic in Python? MRAB <python@mrabarnett.plus.com> - 2015-06-01 13:27 +0100
            Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 17:07 +0200
              Re: What is considered an "advanced" topic in Python? alister <alister.nospam.ware@ntlworld.com> - 2015-06-01 15:26 +0000
                Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 17:51 +0200
                Re: What is considered an "advanced" topic in Python? MRAB <python@mrabarnett.plus.com> - 2015-06-01 18:06 +0100
                  Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 20:14 +0300
              Re: What is considered an "advanced" topic in Python? BartC <bc@freeuk.com> - 2015-06-01 16:42 +0100
                Re: What is considered an "advanced" topic in Python? Grant Edwards <invalid@invalid.invalid> - 2015-06-01 17:02 +0000
                  Re: What is considered an "advanced" topic in Python? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-01 18:45 +0100
                    Re: What is considered an "advanced" topic in Python? Grant Edwards <invalid@invalid.invalid> - 2015-06-01 18:23 +0000
          Re: What is considered an "advanced" topic in Python? BartC <bc@freeuk.com> - 2015-06-01 13:24 +0100
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-01 23:52 +1000
          Re: What is considered an "advanced" topic in Python? BartC <bc@freeuk.com> - 2015-06-01 16:17 +0100
            Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-02 02:10 +1000
              Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-06-01 21:46 -0700
    Re: What is considered an "advanced" topic in Python? Skip Montanaro <skip.montanaro@gmail.com> - 2015-05-29 11:39 -0500
      Re: What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 09:58 -0700
    Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-30 02:50 +1000
    Re: What is considered an "advanced" topic in Python? Todd <toddrjen@gmail.com> - 2015-05-29 19:02 +0200
    Re: What is considered an "advanced" topic in Python? sohcahtoa82@gmail.com - 2015-05-29 10:03 -0700
      Re: What is considered an "advanced" topic in Python? Ethan Furman <ethan@stoneleaf.us> - 2015-05-29 10:17 -0700
        Re: What is considered an "advanced" topic in Python? sohcahtoa82@gmail.com - 2015-05-29 14:06 -0700
          Re: What is considered an "advanced" topic in Python? Jason Swails <jason.swails@gmail.com> - 2015-05-29 17:28 -0400
          Re: What is considered an "advanced" topic in Python? Ethan Furman <ethan@stoneleaf.us> - 2015-05-29 14:39 -0700
          Re: What is considered an "advanced" topic in Python? Ethan Furman <ethan@stoneleaf.us> - 2015-05-29 14:44 -0700
      Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-05-29 20:24 +0300
    Re: What is considered an "advanced" topic in Python? Todd <toddrjen@gmail.com> - 2015-05-29 19:03 +0200
    Re: What is considered an "advanced" topic in Python? Steven D'Aprano <steve@pearwood.info> - 2015-05-30 03:55 +1000
      Re: What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 13:38 -0700
    Re: What is considered an "advanced" topic in Python? Sturla Molden <sturla.molden@gmail.com> - 2015-05-30 12:15 +0000
    Re: What is considered an "advanced" topic in Python? jonathon <jonathon.blake@gmail.com> - 2015-05-30 19:32 +0000
    Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-31 08:24 +1000
    Re: What is considered an "advanced" topic in Python? "C.D. Reimer" <chris@cdreimer.com> - 2015-05-30 18:28 -0700
    Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-05-30 20:30 -0700
      Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-31 14:25 +1000
        Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-05-30 21:46 -0700
          Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-31 14:58 +1000
            Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-05-30 22:18 -0700
    Re: What is considered an "advanced" topic in Python? Gene Heskett <gheskett@wdtv.com> - 2015-06-01 09:49 -0400
    Re: What is considered an "advanced" topic in Python? Denis McMahon <denismfmcmahon@gmail.com> - 2015-06-01 15:30 +0000
    Re: What is considered an "advanced" topic in Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-06-01 20:33 -0400
    Re: What is considered an "advanced" topic in Python? Gene Heskett <gheskett@wdtv.com> - 2015-06-01 23:30 -0400

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


#91705

FromGrant Edwards <invalid@invalid.invalid>
Date2015-06-01 18:23 +0000
Message-ID<mki7v3$hii$1@reader1.panix.com>
In reply to#91703
On 2015-06-01, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 01/06/2015 18:02, Grant Edwards wrote:
>> On 2015-06-01, BartC <bc@freeuk.com> wrote:
>>
>>> At one time the choice was integer or floating point in many languages,
>>> unless you were specifically using a business language such as Cobol.
>>
>> My recollection in the early days of home computers is that many BASIC
>> implementations had BCD floating point instead of binary.  Back then
>> most CPUs had instructions specifcally for dealing with BCD
>> represented with 4-bits per digit.  Dunno if they still do, I can't
>> even remember the last time I did calculations in BCD.
>>
>>> I think the Sinclair computer barely had integer types so the choice
>>> was even narrower.
>
> Didn't Turbo C have compiler options to allow either BCD or fp?

Probably.  BCD support was pretty widespread in the Pascal compilers I
remember for DOS and CP/M.  Binary floating point didn't get very
popular until HW support for it became more common.

-- 
Grant Edwards               grant.b.edwards        Yow! Now we can become
                                  at               alcoholics!
                              gmail.com            

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


#91661

FromBartC <bc@freeuk.com>
Date2015-06-01 13:24 +0100
Message-ID<X9Yax.570951$nQ7.16389@fx42.am4>
In reply to#91656
On 01/06/2015 12:24, Laura Creighton wrote:

> Maybe _your_ brain needs some resetting, too. :)  You know too much so
> have lost the grasp of how the world looks to the new programmer.

Maybe the new programmer should learn then that binary floating point 
might not perform as they might expect.

I'm sure it wasn't long after I first started programming that I 
discovered the reason why code such as:

  for i:=0.0 until 10.0 step 0.1 ...     # (Algol 60)

might not always work properly.

I don't think using decimal magically solves all problems either:

  a=decimal.Decimal('0.0')
  b=decimal.Decimal('1.0')/decimal.Decimal('3.0')
  c=decimal.Decimal('10.0')

  while a<=c:
	print (a)
	a=a+b

This prints 9.999... as the final value rather than 10.0. And if changed to:

  while a!=c:
      .....

then this doesn't terminate.

> I want to use a computer to add up a whole lot of money amounts so I can
> figure out how much money to send some place.
>
> This is an absolute, dead simple first computer program newbies write.
> For a lot of people, this used to be the whole reason they bought a
> computer in the first place.

How many people who buy phones are actually going to write their own 
programs? Rather than download an app written by people who can code (or 
use the built-in calculator). (How do you even code in Python on a 
smartphone anyway?)

> And they immediately grab floating point numbers, and since adding
> a whole lot of them in range of 'prices for stuff at the supermarket'
> is one of the best ways to guarantee your will not get the correct,
> exact amount you want for your answer, they don't get it.

Also, how many items need to be added up before even 64-bit floating 
point values show a discrepancy, after rounding to whole cents? Or are 
we adding up billions of dollars and expecting a result to the exact cent?

> But I am a bad arguer.
>
> When incompatibilites were going into Python 3.0 I wanted
>
> y = 1.3  to give you a decimal, not a float.

1.3 yielding floating point is fairly universal. Probably there would be 
bigger problems if 1.3 silently gave you a decimal type.

> But, hell, I write accounting and bookkeeping systems.  Your milage
> may vary. :)

You can emulate decimal floating point with binary floating point, if 
the latter has some spare precision. Or an easy fix for the shopping 
problem is to work in whole cents, using either integer or floating 
point (although the latter limits you to some $50 trillion dollars for 
the total, which might be a problem if we ever get hyper-inflation again).

But if the numeric representation is crucial to your application, then 
surely you just create a custom type or class for that? (I think Python 
is quite good at this sort of customising; I lot of Python code I see 
now seems to consist of nothing else!)

-- 
Bartc

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


#91674

FromChris Angelico <rosuav@gmail.com>
Date2015-06-01 23:52 +1000
Message-ID<mailman.290.1433166769.5151.python-list@python.org>
In reply to#91479
On Mon, Jun 1, 2015 at 9:24 PM, Laura Creighton <lac@openend.se> wrote:
> In a message of Mon, 01 Jun 2015 20:36:14 +1000, Chris Angelico writes:
>>The problem isn't the decimal separator, though, because floats can
>>have problems even without it (and can have no problems with a decimal
>>separator). If you want to distinguish "computer numbers" from "real
>>numbers", you'd do better to pick a different set of symbols for them
>>- or at least a different numerical base. If all literals were written
>>in octal, people would understand that there's something special going
>>on here. But would that really help?
>
> Maybe _your_ brain needs some resetting, too. :)  You know too much so
> have lost the grasp of how the world looks to the new programmer.
>
> Problem:
> I want to use a computer to add up a whole lot of money amounts so I can
> figure out how much money to send some place.
>
> And they immediately grab floating point numbers...

That part I do understand; floating-point is the one obvious way to do
these sorts of things. I'm fairly sure we agree that a novice *will*,
for better or for worse, stumble upon floats - in pretty much any
language.

The question is, what part of float is wrong? I don't think the
problem is with the decimal separator, and therefore laying them out
as "whole part, colon, fractional part" won't necessarily help. And it
can potentially hurt, by teaching people that computers are just
weird, and you have to speak a weird language to talk to them -
without understanding that there's a real difference behind this. It's
like the eternal debate about assignment and whether "x = x + 1" is
nonsense, with advocates preferring "x := x + 1" as being somehow
fundamentally different. It isn't. It's just a notational change, and
not even a huge one. (Though I do see the line of argument that it
should be "x <- x + 1" or something else that looks like an arrow.)

ChrisA

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


#91683

FromBartC <bc@freeuk.com>
Date2015-06-01 16:17 +0100
Message-ID<rI_ax.603294$PJ4.511481@fx26.am4>
In reply to#91674
On 01/06/2015 14:52, Chris Angelico wrote:
 > It's
> like the eternal debate about assignment and whether "x = x + 1" is
> nonsense, with advocates preferring "x := x + 1" as being somehow
> fundamentally different. It isn't. It's just a notational change, and
> not even a huge one. (Though I do see the line of argument that it
> should be "x <- x + 1" or something else that looks like an arro'w.)

'x <- x + 1' already means something as an expression (whether x is less 
than (-x+1). 'x <= x + 1' has the same problem.

But I have used "=>" before,  for left-to-right assignment. (Mostly I 
use ":=")

-- 
Bartc

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


#91691

FromChris Angelico <rosuav@gmail.com>
Date2015-06-02 02:10 +1000
Message-ID<mailman.4.1433175021.13271.python-list@python.org>
In reply to#91683
On Tue, Jun 2, 2015 at 1:17 AM, BartC <bc@freeuk.com> wrote:
> On 01/06/2015 14:52, Chris Angelico wrote:
>> It's
>>
>> like the eternal debate about assignment and whether "x = x + 1" is
>> nonsense, with advocates preferring "x := x + 1" as being somehow
>> fundamentally different. It isn't. It's just a notational change, and
>> not even a huge one. (Though I do see the line of argument that it
>> should be "x <- x + 1" or something else that looks like an arro'w.)
>
>
> 'x <- x + 1' already means something as an expression (whether x is less
> than (-x+1). 'x <= x + 1' has the same problem.
>
> But I have used "=>" before,  for left-to-right assignment. (Mostly I use
> ":=")

In Python it does, yes; I'm talking about the language design
advocates. Some recommend a two-character ASCII notation like "<-" or
"<=", others prefer a single-character symbol eg "←" or "⇦", but
whatever it is, it will have no meaning in that language other than
assignment. And yes, I can see the value of using an arrow to indicate
assignment... but I don't really see a huge problem with using "=" to
mean assignment, given that people from a mathematical background will
have to grok the entire concept of temporal truth anyway. Whatever
symbol you use, it has to be explained.

ChrisA

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


#91789

FromRustom Mody <rustompmody@gmail.com>
Date2015-06-01 21:46 -0700
Message-ID<dea5462a-4904-4f86-a1a6-9caa0ee2c8c9@googlegroups.com>
In reply to#91691
On Monday, June 1, 2015 at 9:40:39 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Jun 2, 2015 at 1:17 AM, BartC wrote:
> > On 01/06/2015 14:52, Chris Angelico wrote:
> >> It's
> >>
> >> like the eternal debate about assignment and whether "x = x + 1" is
> >> nonsense, with advocates preferring "x := x + 1" as being somehow
> >> fundamentally different. It isn't. It's just a notational change, and
> >> not even a huge one. (Though I do see the line of argument that it
> >> should be "x <- x + 1" or something else that looks like an arro'w.)
> >
> >
> > 'x <- x + 1' already means something as an expression (whether x is less
> > than (-x+1). 'x <= x + 1' has the same problem.
> >
> > But I have used "=>" before,  for left-to-right assignment. (Mostly I use
> > ":=")
> 
> In Python it does, yes; I'm talking about the language design
> advocates. Some recommend a two-character ASCII notation like "<-" or
> "<=", others prefer a single-character symbol eg "←" or "⇦", but
> whatever it is, it will have no meaning in that language other than
> assignment. And yes, I can see the value of using an arrow to indicate
> assignment... but I don't really see a huge problem with using "=" to
> mean assignment, given that people from a mathematical background will
> have to grok the entire concept of temporal truth anyway. Whatever
> symbol you use, it has to be explained.

Its not merely temporal truth but truth vs action and their wanton overloading.

In every (natural) language that I know (of)¹ declarative and imperative moods
are distinguished.  It does not require a PhD in English to see that
"Please sit down."
and
"It is raining."
differ in mood.
Imperative languages after Pascal (specially C and following) use a locution from
the one to denote a semantics in the other and make pickle of beginners' brains.

---------
¹ Except perhaps magic/mystic-speak wherein pronouncing a spell makes the heavens thunder.
Maybe I am just too old to have noticed that imperative programming is a paradigm of magic

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


#91474

FromSkip Montanaro <skip.montanaro@gmail.com>
Date2015-05-29 11:39 -0500
Message-ID<mailman.195.1432917598.5151.python-list@python.org>
In reply to#91468

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 29, 2015 at 11:01 AM, Mike Driscoll <kyosohma@gmail.com> wrote:
> ... I was wondering what the community considers to be "intermediate" or
"advanced".

Just about any topic on which Dave Beazley has given a keynote talk
<https://www.google.com/search?q=Dave+Beazley+keynote&oq=Dave+Beazley+keynote&aqs=chrome..69i57.5895j0j7&sourceid=chrome&es_sm=122&ie=UTF-8#q=Dave+Beazley+keynote&tbm=vid>.
:-)

Skip

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


#91480

FromMike Driscoll <kyosohma@gmail.com>
Date2015-05-29 09:58 -0700
Message-ID<ab88b589-6503-4473-990a-520fd74fea84@googlegroups.com>
In reply to#91474
On Friday, May 29, 2015 at 11:40:11 AM UTC-5, Skip Montanaro wrote:
> On Fri, May 29, 2015 at 11:01 AM, Mike Driscoll <kyos...@gmail.com> wrote:
> > ... I was wondering what the community considers to be "intermediate" or "advanced".
> 
> Just about any topic on which Dave Beazley has given a keynote talk. :-)
> 
> 
> Skip

I've always enjoyed reading Beazley's blog...and his presentations are always neat too. Good idea. 

Thanks,
Mike

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


#91477

FromChris Angelico <rosuav@gmail.com>
Date2015-05-30 02:50 +1000
Message-ID<mailman.198.1432918206.5151.python-list@python.org>
In reply to#91468
On Sat, May 30, 2015 at 2:39 AM, Skip Montanaro
<skip.montanaro@gmail.com> wrote:
> On Fri, May 29, 2015 at 11:01 AM, Mike Driscoll <kyosohma@gmail.com> wrote:
>> ... I was wondering what the community considers to be "intermediate" or
>> "advanced".
>
> Just about any topic on which Dave Beazley has given a keynote talk. :-)

Hehe. First hit is this one, with its awesome slide...

https://youtu.be/l_HBRhcgeuQ?t=3m34s

I showed that to my parents and siblings, most of whom are not
particularly adept with Python, and they found it highly amusing. As a
participant in python-ideas, I found it hilarious... and absolutely
right.

ChrisA

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


#91482

FromTodd <toddrjen@gmail.com>
Date2015-05-29 19:02 +0200
Message-ID<mailman.199.1432918943.5151.python-list@python.org>
In reply to#91468

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 29, 2015 at 6:01 PM, Mike Driscoll <kyosohma@gmail.com> wrote:

> Hi,
>
> I've been asked on several occasions to write about intermediate or
> advanced topics in Python and I was wondering what the community considers
> to be "intermediate" or "advanced". I realize we're all growing in our
> abilities with the language, so this is going to be very subjective, but I
> am still curious what my fellow Python developers think about this topic.
>
> Thanks,
> Mike
> --
> https://mail.python.org/mailman/listinfo/python-list
>

The ast module and AST hacking
The dist module and understanding the interpreter.
Code objects

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


#91483

Fromsohcahtoa82@gmail.com
Date2015-05-29 10:03 -0700
Message-ID<33b7ab62-8cc2-4a27-b229-64c94bce16b6@googlegroups.com>
In reply to#91468
On Friday, May 29, 2015 at 9:02:06 AM UTC-7, Mike Driscoll wrote:
> Hi,
> 
> I've been asked on several occasions to write about intermediate or advanced topics in Python and I was wondering what the community considers to be "intermediate" or "advanced". I realize we're all growing in our abilities with the language, so this is going to be very subjective, but I am still curious what my fellow Python developers think about this topic.
> 
> Thanks,
> Mike

Metaclasses.

I've read about them.  I still don't understand them, why you would want them, and what you gain from them.

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


#91486

FromEthan Furman <ethan@stoneleaf.us>
Date2015-05-29 10:17 -0700
Message-ID<mailman.202.1432919880.5151.python-list@python.org>
In reply to#91483
On 05/29/2015 10:03 AM, sohcahtoa82@gmail.com wrote:
> On Friday, May 29, 2015 at 9:02:06 AM UTC-7, Mike Driscoll wrote:

>> I've been asked on several occasions to write about intermediate or advanced topics
>>  in Python and I was wondering what the community considers to be "intermediate" or
>>  "advanced". I realize we're all growing in our abilities with the language, so this
>>  is going to be very subjective, but I am still curious what my fellow Python
>>  developers think about this topic.
>
> Metaclasses.
>
> I've read about them.  I still don't understand them, why you would want them, and what you gain from them.

Metaclasses change the way a class behaves.

For example, the new (in 3.4) Enum class uses a metaclass.

   class SomeEnum(Enum):
      first = 1
      second = 2
      third = 3

The metaclass changes normal class behavior to:

   - support iterating: list(SomeEnum) --> [SomeEnum.first, SomeEnum.second, SomeEnum.third]
   - support a length:  len(SomeEnum) --> 3
   - not allow new instances to be created:  --> SomeEnum(1) is SomeEnum(1)  # True

--
~Ethan~

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


#91502

Fromsohcahtoa82@gmail.com
Date2015-05-29 14:06 -0700
Message-ID<656488c4-e706-4fea-ab45-3d1454e35a7f@googlegroups.com>
In reply to#91486
On Friday, May 29, 2015 at 10:18:29 AM UTC-7, Ethan Furman wrote:
> On 05/29/2015 10:03 AM, sohcahtoa82@gmail.com wrote:
> > On Friday, May 29, 2015 at 9:02:06 AM UTC-7, Mike Driscoll wrote:
> 
> >> I've been asked on several occasions to write about intermediate or advanced topics
> >>  in Python and I was wondering what the community considers to be "intermediate" or
> >>  "advanced". I realize we're all growing in our abilities with the language, so this
> >>  is going to be very subjective, but I am still curious what my fellow Python
> >>  developers think about this topic.
> >
> > Metaclasses.
> >
> > I've read about them.  I still don't understand them, why you would want them, and what you gain from them.
> 
> Metaclasses change the way a class behaves.
> 
> For example, the new (in 3.4) Enum class uses a metaclass.
> 
>    class SomeEnum(Enum):
>       first = 1
>       second = 2
>       third = 3
> 
> The metaclass changes normal class behavior to:
> 
>    - support iterating: list(SomeEnum) --> [SomeEnum.first, SomeEnum.second, SomeEnum.third]
>    - support a length:  len(SomeEnum) --> 3
>    - not allow new instances to be created:  --> SomeEnum(1) is SomeEnum(1)  # True
> 
> --
> ~Ethan~

Regarding the first two, you can implement __iter__ and __len__ functions to create that functionality, though those functions would operate on an instance of the class, not the class itself.

As for the third, can't you override the __new__ function to make attempts to create a new instance just return a previously created instance?

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


#91503

FromJason Swails <jason.swails@gmail.com>
Date2015-05-29 17:28 -0400
Message-ID<mailman.207.1432934931.5151.python-list@python.org>
In reply to#91502

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 29, 2015 at 5:06 PM, <sohcahtoa82@gmail.com> wrote:

>
> > For example, the new (in 3.4) Enum class uses a metaclass.
> >
> >    class SomeEnum(Enum):
> >       first = 1
> >       second = 2
> >       third = 3
> >
> > The metaclass changes normal class behavior to:
> >
> >    - support iterating: list(SomeEnum) --> [SomeEnum.first,
> SomeEnum.second, SomeEnum.third]
> >    - support a length:  len(SomeEnum) --> 3
> >    - not allow new instances to be created:  --> SomeEnum(1) is
> SomeEnum(1)  # True
> >
> > --
> > ~Ethan~
>
> Regarding the first two, you can implement __iter__ and __len__ functions
> to create that functionality, though those functions would operate on an
> instance of the class, not the class itself.
>
> As for the third, can't you override the __new__ function to make attempts
> to create a new instance just return a previously created instance?
>

​Of course, but with metaclasses you don't *have* to (in fact, that's the
type of thing that the metaclass could do behind the scenes).

​In this case, any Enum subclass should *always* behave as Ethan described
-- without metaclasses that wouldn't necessarily be true (e.g., if the
person creating an Enum subclass didn't bother to correctly implement
__new__, __iter__, and __len__ for their subclass).

By using metaclasses, you can declare an Enum subclass as simply as Ethan
showed, since the metaclass does all of the dirty work implementing the
desired behavior at the time the class object is constructed (subclasses
inherit their parent class's metaclass).

In this use-case, you can think of it as a kind of "implicit class
factory".  Suppose you have a prescription for how you modify a class
definition (i.e., by implementing certain behavior in __new__ or __init__)
that you wrap up into some function "tweak_my_class".  The metaclass would
allow the class definition to be the equivalent of something like:

class MyClass(SubClass):
    # whatever

MyClass = tweak_my_class(MyClass)

Or as a class decorator

@tweak_my_class
class MyClass(SubClass):
    # whatever

(In fact, the `six` module allows you to implement metaclasses as
decorators to work with both Python 2 and Python 3, but I think metaclasses
are more powerful in Py3 than they are in Py2).​
​
They are cool ideas, and I've used them in my own code, but they do have a
kind of magic-ness to them -- especially in codes that you didn't write but
are working on.  As a result, I've recently started to prefer alternatives,
but in some rare cases (like Enum, for example), they are just the best
solution.

All the best,
Jason

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


#91504

FromEthan Furman <ethan@stoneleaf.us>
Date2015-05-29 14:39 -0700
Message-ID<mailman.208.1432935608.5151.python-list@python.org>
In reply to#91502
On 05/29/2015 02:06 PM, sohcahtoa82@gmail.com wrote:
> On Friday, May 29, 2015 at 10:18:29 AM UTC-7, Ethan Furman wrote:
>>
>> Metaclasses change the way a class behaves.
>>
>> For example, the new (in 3.4) Enum class uses a metaclass.
>>
>>     class SomeEnum(Enum):
>>        first = 1
>>        second = 2
>>        third = 3
>>
>> The metaclass changes normal class behavior to:
>>
>>     - support iterating: list(SomeEnum) --> [SomeEnum.first, SomeEnum.second, SomeEnum.third]
>>     - support a length:  len(SomeEnum) --> 3
>>     - not allow new instances to be created:  --> SomeEnum(1) is SomeEnum(1)  # True
>>
>> --
>> ~Ethan~
>
> Regarding the first two, you can implement __iter__ and __len__ functions to create that functionality, though those functions would operate on an instance of the class, not the class itself.

Hence the need for a metaclass, as the point is to operate on the class, not the instance.

> As for the third, can't you override the __new__ function to make attempts to create a new instance just return a previously created instance?

Yes.  In the case of Enum, however, it takes any user-defined __new__, which is needed for creating the original instances, and replaces it with a __new__ that only returns the already defined ones.

--
~Ethan~

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


#91505

FromEthan Furman <ethan@stoneleaf.us>
Date2015-05-29 14:44 -0700
Message-ID<mailman.209.1432935863.5151.python-list@python.org>
In reply to#91502
On 05/29/2015 02:28 PM, Jason Swails wrote:

> ​[...] e.g., if the person creating an Enum subclass didn't bother to correctly
> implement [...] __iter__, and __len__ for their subclass

For __iter__ and __len__ to work on the Enum /class/ it must be defined in the metaclass.

--
~Ethan~

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


#91488

FromMarko Rauhamaa <marko@pacujo.net>
Date2015-05-29 20:24 +0300
Message-ID<87zj4nb8lg.fsf@elektro.pacujo.net>
In reply to#91483
sohcahtoa82@gmail.com:

> Metaclasses.
>
> I've read about them. I still don't understand them, why you would
> want them, and what you gain from them.

I don't think you would ever want them.


Marko

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


#91484

FromTodd <toddrjen@gmail.com>
Date2015-05-29 19:03 +0200
Message-ID<mailman.200.1432919049.5151.python-list@python.org>
In reply to#91468

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 29, 2015 at 7:02 PM, Todd <toddrjen@gmail.com> wrote:

> On Fri, May 29, 2015 at 6:01 PM, Mike Driscoll <kyosohma@gmail.com> wrote:
>
>> Hi,
>>
>> I've been asked on several occasions to write about intermediate or
>> advanced topics in Python and I was wondering what the community considers
>> to be "intermediate" or "advanced". I realize we're all growing in our
>> abilities with the language, so this is going to be very subjective, but I
>> am still curious what my fellow Python developers think about this topic.
>>
>> Thanks,
>> Mike
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
> The ast module and AST hacking
> The dist module and understanding the interpreter.
> Code objects
>

Sorry, miss-typed. I meant the "dis" module, not the "dist" module.

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


#91491

FromSteven D'Aprano <steve@pearwood.info>
Date2015-05-30 03:55 +1000
Message-ID<5568a81a$0$12976$c3e8da3$5496439d@news.astraweb.com>
In reply to#91468
On Sat, 30 May 2015 02:01 am, Mike Driscoll wrote:

> Hi,
> 
> I've been asked on several occasions to write about intermediate or
> advanced topics in Python and I was wondering what the community considers
> to be "intermediate" or "advanced". I realize we're all growing in our
> abilities with the language, so this is going to be very subjective, but I
> am still curious what my fellow Python developers think about this topic.


I would consider these advanced topics:


Metaclasses.
Descriptors.
Futures.
Asynchronous processing, including multiprocessing and threads.
Writing C or Fortran extensions.
Function/code object internals.
Byte-code hacking.
Manipulating ASTs.
OS-specific features like the os.exec* functions, os.fork, daemons, etc.
Multiple inheritance, mixins, traits, etc.
Coroutines.
Dynamic programming.
Neural nets.
Distributed processing, including remote procedure calls.
Fuzz testing.


I would consider these intermediate topics:


Closures.
Using classes and functions as first-class values.
Second-order functions.
Decorators.
Functional idioms (map, filter, reduce).
Viewing byte-code using the dis module.
Unicode, code pages, codecs and encodings.
Regular expressions.
SQL and dealing with databases.
The complexities of floating point, including Decimal.
Writing your own context managers.
Generators and iterators.
Unit testing, doctests, etc.
Code generation and metaprogramming.
Writing your own classes.
State machines.
The structure of URLs (they're more than just "http://blahblah.com").
Anything to do with HTTP (client or server).
Commandline argument processing (argparse, optparse, etc.)

Some of the intermediate topics start at an intermediate level, but can go
on to include more advanced uses.



-- 
Steven

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


#91500

FromMike Driscoll <kyosohma@gmail.com>
Date2015-05-29 13:38 -0700
Message-ID<71fe4ca4-1db0-4fdd-9e8c-0210501f41fd@googlegroups.com>
In reply to#91491
Hi Steven,

On Friday, May 29, 2015 at 12:55:48 PM UTC-5, Steven D'Aprano wrote:
> On Sat, 30 May 2015 02:01 am, Mike Driscoll wrote:
> 
> > Hi,
> > 
> > I've been asked on several occasions to write about intermediate or
> > advanced topics in Python and I was wondering what the community considers
> > to be "intermediate" or "advanced". I realize we're all growing in our
> > abilities with the language, so this is going to be very subjective, but I
> > am still curious what my fellow Python developers think about this topic.
> 
> 
> I would consider these advanced topics:
> 
> 
> Metaclasses.
> Descriptors.
> Futures.
> Asynchronous processing, including multiprocessing and threads.
> Writing C or Fortran extensions.
> Function/code object internals.
> Byte-code hacking.
> Manipulating ASTs.
> OS-specific features like the os.exec* functions, os.fork, daemons, etc.
> Multiple inheritance, mixins, traits, etc.
> Coroutines.
> Dynamic programming.
> Neural nets.
> Distributed processing, including remote procedure calls.
> Fuzz testing.
> 
> 
> I would consider these intermediate topics:
> 
> 
> Closures.
> Using classes and functions as first-class values.
> Second-order functions.
> Decorators.
> Functional idioms (map, filter, reduce).
> Viewing byte-code using the dis module.
> Unicode, code pages, codecs and encodings.
> Regular expressions.
> SQL and dealing with databases.
> The complexities of floating point, including Decimal.
> Writing your own context managers.
> Generators and iterators.
> Unit testing, doctests, etc.
> Code generation and metaprogramming.
> Writing your own classes.
> State machines.
> The structure of URLs (they're more than just "http://blahblah.com").
> Anything to do with HTTP (client or server).
> Commandline argument processing (argparse, optparse, etc.)
> 
> Some of the intermediate topics start at an intermediate level, but can go
> on to include more advanced uses.
> 
> 
> 
> -- 
> Steven

That's a really good list of topics. Thanks so much for sharing your ideas.

Mike

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


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

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


csiph-web