From javier at candeira.com Sun Sep 1 14:15:39 2013 From: javier at candeira.com (Javier Candeira) Date: Sun, 1 Sep 2013 22:15:39 +1000 Subject: [melbourne-pug] MPUG Meeting Tomorrow - September 2, 6PM - Inspire 9, 41 Stewart St Message-ID: Hi Melbourne Python peoples, There is a meeting tomorrow! There will be pizza ($10, collected before the meeting) but the Inspire9 people have informed us that we no longer have access to the beer fridge. So it's BYO until someone finds a better solution. Also, there are talks! # Richard Jones -- Don't do this! In which Richard will tell you about some things you should never (probably ever) do to or in Python. Warranties may be voided. # Ryan Kelly -- PyPy.js: towards a fast and compliant python shell for your browser Ryan says: "This talk will highlight my experiments in porting PyPy to the web platform: the what, the how, and the why-on-earth-would-you-do-that." Javier & the MPUG organists. From javier at candeira.com Tue Sep 3 01:43:16 2013 From: javier at candeira.com (Javier Candeira) Date: Tue, 3 Sep 2013 09:43:16 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward Message-ID: Hi fellow pythonistas, Yesterday at Inspire 9 we had an attendance of 25 people for three talks: Richard showed us what not to do with Python, Ryan talked about PyPy.js, and Lars showed offf his Great Language Game project. - http://www.youtube.com/watch?v=H2yfXnUb1S4 - http://rfk.id.au/blog/entry/pypy-js-poc-jit/ - https://speakerdeck.com/larsyencken/the-great-language-game Thanks all three, and thanks also to everybody who attended. We also discussed some organisational points: - suggesting new topics of interest in the list and editing the wiki to reflect them. This thread is open. - maybe have some tutorial sessions based on the community's suggested topics. - BOF sessions based on common interests (I suggested testing in the context of devops, someone suggested tkinter and GUI programming). - beer at sessions: Inspire9 have said they can't provide it anymore, if anybody wants to step up, I'm sure we'll all be very thankful. - somewhere in the meetup page it says "we don't meet that often anymore", and someone at the session even aksed if MPUG was a splinter group. We're fixing that. Next session will be on 7 October. We already have two talks: Clare Slogget on Python for Bioinformatics, and Lex Hider on Devops with Salt. There is space for short talks, and if you have a longer one, please also come forward and help us fill the pipeline. Cheers everyone, Javier From javier at candeira.com Tue Sep 3 14:39:18 2013 From: javier at candeira.com (Javier Candeira) Date: Tue, 3 Sep 2013 22:39:18 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: Oh, yesterday we forgot to talk about http://www.belowtheline.org.au/ ! Below The Line is a service by MPUG's own Benno Rice (with Michael Pearson and data from the Australian Electoral Commission) to help citizens know what they are voting for when they vote for a party's preference ticket instead of voting below the line. As a new citizen, I find all of this as daunting as it's fascinating. And as a daunted voter, I find Below The Line an incredibly useful resource to help me navigate my voting choices. Thanks, Benno! J From dan.peade at gmail.com Wed Sep 4 01:37:47 2013 From: dan.peade at gmail.com (dan) Date: Wed, 4 Sep 2013 09:37:47 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: Slightly off topic but don't worry you're not the only one who finds it daunting: http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822 It's obviously broken and needs to be fixed but awesome that there's a tool to help work around it in the interim. On 3 September 2013 22:39, Javier Candeira wrote: > Oh, yesterday we forgot to talk about http://www.belowtheline.org.au/ ! > > Below The Line is a service by MPUG's own Benno Rice (with Michael > Pearson and data from the Australian Electoral Commission) to help > citizens know what they are voting for when they vote for a party's > preference ticket instead of voting below the line. > > As a new citizen, I find all of this as daunting as it's fascinating. > And as a daunted voter, I find Below The Line an incredibly useful > resource to help me navigate my voting choices. > > Thanks, Benno! > > J > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > -- Peace! Dan Homer's Brain: Use reverse psychology. Homer: Oh, that sounds too complicated. Homer's Brain: Okay, don't use reverse psychology. Homer: Okay, I will! -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier at candeira.com Wed Sep 4 02:04:25 2013 From: javier at candeira.com (Javier Candeira) Date: Wed, 4 Sep 2013 10:04:25 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: On Wed, Sep 4, 2013 at 9:37 AM, dan wrote: > Slightly off topic but don't worry you're not the only one who finds it > daunting: > http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822 > > It's obviously broken and needs to be fixed but awesome that there's a tool > to help work around it in the interim. Trying to keep the offtopic on-topic, there is an interesting parallell between the cognitve loads associated with preferential voting and the type of direct democracy practiced in California (where they have many ballots at each election for with particular laws or "initiative") and the micromanaging of types, access modifiers etc. in enterprisey languages such as Java. There are tradeoffs everywhere. More control means more mental load. Lower mental load means less control. Coming from a country where Parliament is picked by closed lists, I appreciate the added control of preference ranking for Parliament here. But it certainly adds a mental toll. Coming from a language like Python 2, some people appreciate type annotations in Python 3, so they don't have to perform guards in their code at runtime. At Monash we're already running our first semester of Data Structures and Algorithms using Python instead of Java. I'm now translating sample code for students's pracs, and I find myself having to decide at every point whether to let some type errors (like comparisons of uncomparables types) pass to be caught by the Python runtime, or to catch them and do something myself. All of those are errors that would be caught by the Java compiler. It's interesting to see the student forums, because most of the errors the students get stuck at are type errors (looking at a Node object instead of extracting the item, assigning a variable from a function that returns None), and all of those would have been previously caught by their IDE. Now they have do debug on the run, and use their brain instead of leveraging better tools. Tradeoffs. J From gracer at blueseastech.com.au Wed Sep 4 03:22:32 2013 From: gracer at blueseastech.com.au (Grace Roberts) Date: Wed, 4 Sep 2013 11:22:32 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: <23561C58-C807-4CC8-82BE-7F2E5AE13C96@blueseastech.com.au> Nice recovery to get back to a python topic! I was almost tempted to start venting about the election. :-) PS. Thanks Benno. On 04/09/2013, at 10:04 AM, Javier Candeira wrote: > On Wed, Sep 4, 2013 at 9:37 AM, dan wrote: >> Slightly off topic but don't worry you're not the only one who finds it >> daunting: >> http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822 >> >> It's obviously broken and needs to be fixed but awesome that there's a tool >> to help work around it in the interim. > > Trying to keep the offtopic on-topic, there is an interesting > parallell between the cognitve loads associated with preferential > voting and the type of direct democracy practiced in California (where > they have many ballots at each election for with particular laws or > "initiative") and the micromanaging of types, access modifiers etc. in > enterprisey languages such as Java. > > There are tradeoffs everywhere. More control means more mental load. > Lower mental load means less control. Coming from a country where > Parliament is picked by closed lists, I appreciate the added control > of preference ranking for Parliament here. But it certainly adds a > mental toll. > > Coming from a language like Python 2, some people appreciate type > annotations in Python 3, so they don't have to perform guards in their > code at runtime. > > At Monash we're already running our first semester of Data Structures > and Algorithms using Python instead of Java. I'm now translating > sample code for students's pracs, and I find myself having to decide > at every point whether to let some type errors (like comparisons of > uncomparables types) pass to be caught by the Python runtime, or to > catch them and do something myself. All of those are errors that would > be caught by the Java compiler. > > It's interesting to see the student forums, because most of the errors > the students get stuck at are type errors (looking at a Node object > instead of extracting the item, assigning a variable from a function > that returns None), and all of those would have been previously caught > by their IDE. Now they have do debug on the run, and use their brain > instead of leveraging better tools. > > Tradeoffs. > > J > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug From claresloggett at gmail.com Wed Sep 4 11:09:25 2013 From: claresloggett at gmail.com (Clare Sloggett) Date: Wed, 4 Sep 2013 19:09:25 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: <23561C58-C807-4CC8-82BE-7F2E5AE13C96@blueseastech.com.au> References: <23561C58-C807-4CC8-82BE-7F2E5AE13C96@blueseastech.com.au> Message-ID: You have fine-grained control but are not obliged to use it (you can vote very simply if you like), which is an excellent solution I think! Lack of types are the cause of most of my python issues too. Maybe we need types that you don't HAVE to declare if you don't want :) On 4 September 2013 11:22, Grace Roberts wrote: > > Nice recovery to get back to a python topic! I was almost tempted to > start venting about the election. :-) > > PS. Thanks Benno. > > > On 04/09/2013, at 10:04 AM, Javier Candeira wrote: > > > On Wed, Sep 4, 2013 at 9:37 AM, dan wrote: > >> Slightly off topic but don't worry you're not the only one who finds it > >> daunting: > >> > http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822 > >> > >> It's obviously broken and needs to be fixed but awesome that there's a > tool > >> to help work around it in the interim. > > > > Trying to keep the offtopic on-topic, there is an interesting > > parallell between the cognitve loads associated with preferential > > voting and the type of direct democracy practiced in California (where > > they have many ballots at each election for with particular laws or > > "initiative") and the micromanaging of types, access modifiers etc. in > > enterprisey languages such as Java. > > > > There are tradeoffs everywhere. More control means more mental load. > > Lower mental load means less control. Coming from a country where > > Parliament is picked by closed lists, I appreciate the added control > > of preference ranking for Parliament here. But it certainly adds a > > mental toll. > > > > Coming from a language like Python 2, some people appreciate type > > annotations in Python 3, so they don't have to perform guards in their > > code at runtime. > > > > At Monash we're already running our first semester of Data Structures > > and Algorithms using Python instead of Java. I'm now translating > > sample code for students's pracs, and I find myself having to decide > > at every point whether to let some type errors (like comparisons of > > uncomparables types) pass to be caught by the Python runtime, or to > > catch them and do something myself. All of those are errors that would > > be caught by the Java compiler. > > > > It's interesting to see the student forums, because most of the errors > > the students get stuck at are type errors (looking at a Node object > > instead of extracting the item, assigning a variable from a function > > that returns None), and all of those would have been previously caught > > by their IDE. Now they have do debug on the run, and use their brain > > instead of leveraging better tools. > > > > Tradeoffs. > > > > J > > _______________________________________________ > > melbourne-pug mailing list > > melbourne-pug at python.org > > https://mail.python.org/mailman/listinfo/melbourne-pug > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonslists at gmail.com Wed Sep 4 12:09:51 2013 From: noonslists at gmail.com (Noon Silk) Date: Wed, 4 Sep 2013 20:09:51 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: <23561C58-C807-4CC8-82BE-7F2E5AE13C96@blueseastech.com.au> Message-ID: On Wed, Sep 4, 2013 at 7:09 PM, Clare Sloggett wrote: > > You have fine-grained control but are not obliged to use it (you can vote > very simply if you like), which is an excellent solution I think! > > Lack of types are the cause of most of my python issues too. Maybe we need > types that you don't HAVE to declare if you don't want :) > Apparently this exists: -- Noon Silk -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at yencken.org Wed Sep 4 02:31:46 2013 From: lars at yencken.org (Lars Yencken) Date: Wed, 4 Sep 2013 10:31:46 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: (completely on the programming side) I haven't mastered it, but there seems to be an art to testing your type assumptions early in Python. For example, if you are expecting to be passed in a list that you're going to append to, or some compatible duck type, you might add a statement to the top of your function: def f(l): append = l.append ... append(v) at the top of your code. If you get some other incompatible type, it fails early rather than in the bowels of your program. These kinds of things really help you to be productive and safe in a duck-typing world. On 4 September 2013 10:04, Javier Candeira wrote: > On Wed, Sep 4, 2013 at 9:37 AM, dan wrote: > > Slightly off topic but don't worry you're not the only one who finds it > > daunting: > > > http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822 > > > > It's obviously broken and needs to be fixed but awesome that there's a > tool > > to help work around it in the interim. > > Trying to keep the offtopic on-topic, there is an interesting > parallell between the cognitve loads associated with preferential > voting and the type of direct democracy practiced in California (where > they have many ballots at each election for with particular laws or > "initiative") and the micromanaging of types, access modifiers etc. in > enterprisey languages such as Java. > > There are tradeoffs everywhere. More control means more mental load. > Lower mental load means less control. Coming from a country where > Parliament is picked by closed lists, I appreciate the added control > of preference ranking for Parliament here. But it certainly adds a > mental toll. > > Coming from a language like Python 2, some people appreciate type > annotations in Python 3, so they don't have to perform guards in their > code at runtime. > > At Monash we're already running our first semester of Data Structures > and Algorithms using Python instead of Java. I'm now translating > sample code for students's pracs, and I find myself having to decide > at every point whether to let some type errors (like comparisons of > uncomparables types) pass to be caught by the Python runtime, or to > catch them and do something myself. All of those are errors that would > be caught by the Java compiler. > > It's interesting to see the student forums, because most of the errors > the students get stuck at are type errors (looking at a Node object > instead of extracting the item, assigning a variable from a function > that returns None), and all of those would have been previously caught > by their IDE. Now they have do debug on the run, and use their brain > instead of leveraging better tools. > > Tradeoffs. > > J > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben+python at benfinney.id.au Thu Sep 5 01:52:38 2013 From: ben+python at benfinney.id.au (Ben Finney) Date: Thu, 05 Sep 2013 09:52:38 +1000 Subject: [melbourne-pug] Data type assumptions in Python (was: Yesterday's MPUG session and going forward) References: Message-ID: <7w8uzcuou1.fsf_-_@benfinney.id.au> Lars Yencken writes: > I haven't mastered it, but there seems to be an art to testing your type > assumptions early in Python. The art is: Don't test data type assumptions in the code. Rather, use EAFP and duck typing, and only test type assumptions in unit tests. Duck typing means that you stop caring about the type of objects given to you, and care only about how they behave. ?If it looks like a duck, and quacks like a duck, we may as well treat it like a duck until it demonstrates otherwise?. EAFP means it is Easier to Ask Forgiveness than Permission. (This is contrasted with Look Before You Leap, which is discouraged in Python.) Just use the object you're given as though it will behave the way you want. If it does, great! If it doesn't an exception is raised and it's up to the *caller* to deal with that exception since they didn't pass your code an object with the correct behaviour. Both these approaches allow polymorphism, a powerful language capability: Your code will accept any object that behaves the right way, regardless of where the object fits in the type hierarchy, without needing to special-case each different type. If you need a file-like object, you don't need the object to inherit from ?file?. You only need it to implement some subset of the expected behaviour of ?file? ? and you do that by just using the object like a file. If, instead, you have a narrow set of types and check to see the object fits in that set, then you thwart polymorphism: no-one can implement the behaviour you expect on an object from elsewhere in the hierarchy (such as an ?io.StringIO? object, which does not inherit from ?file? at all but implements a large subset of the behaviour). Your code that checks object types will be needlessly rejecting objects which it could use, and your callers will not be able to do things they could do in the absence of those needless restrictions. Use duck typing, and make your callers responsible for passing objects that behave correctly. Likewise, if instead you LBYL in your code, you are attempting to handle type problems at the wrong location. It should be the caller's responsibility, not yours, to pass objects that implement the right behaviour. Your LBYL code will grow more and more error checking, obscuring the actual functionality that you should be writing. Use EAFP, and your code will trigger exceptions when those objects don't behave correctly: it's then the caller's responsibility to handle it. How, then, do you know that your code will behave correctly? Write unit tests that exercise your functions ? which, if you're doing it right, are small and loosely coupled with narrow interfaces ? by throwing objects of various types at them, making sure they use them correctly and that exceptions are raised where the objects are unsuitable. What about letting your callers know the expected behaviour? That's what the docstring is for. Describe your parameters by their behaviour. Don't say ?foo is a list of widgets?, if you only need it to be iterable. ?foo is an iterable of widgets? tells the reader what they need to pass. -- \ ?[Freedom of speech] isn't something somebody else gives you. | `\ That's something you give to yourself.? ?_Hocus Pocus_, Kurt | _o__) Vonnegut | Ben Finney From rasjidw at openminddev.net Thu Sep 5 02:08:35 2013 From: rasjidw at openminddev.net (Rasjid Wilcox) Date: Thu, 05 Sep 2013 10:08:35 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: <23561C58-C807-4CC8-82BE-7F2E5AE13C96@blueseastech.com.au> Message-ID: <5227CB83.3080000@openminddev.net> On 4/09/2013 8:09 PM, Noon Silk wrote: > On Wed, Sep 4, 2013 at 7:09 PM, Clare Sloggett > > wrote: > > > You have fine-grained control but are not obliged to use it (you > can vote very simply if you like), which is an excellent solution > I think! > > Lack of types are the cause of most of my python issues too. Maybe > we need types that you don't HAVE to declare if you don't want :) > > > Apparently this exists: > Not quite Python, but Cobra (http://cobra-language.com/) also has optional types, as does Google's Dart. Cheers, Rasjid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier at candeira.com Thu Sep 5 04:27:03 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 12:27:03 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: Yes, but it's a hack, isn't it? I used to do this with the sorted lists and binary sort trees for my students. For instance, I would put in a "try: new_element > first_element; except: TypeError" to make sure the type of the new element was comparable with those in the data structure. Then I realised that I could let Python raise the error, and all I had to do was surround the actual insert call with a try/except guard. I don't know, it felt more pythonic. Then I wondered again whether the exception shouldn't be caught inside the data structure's method. But what should it do? It's going to throw a TypeError anyway, because in Python 3 you can't compare a string to an int, for instance, so you can't insert a string in a bst or sorted list that's full of ints so far. I like your solution, I might do it from now on. Put first an unguarded expression that might go boom, so it goes boom early. Brilliant. It's still a hack. Java is boring and bureaucratic about types, but this kind of problems is caught much earlier, by the compiler. So, tradeoffs. Could be that statically typed languages with type inference and duck-type generics is what it's at. On Wed, Sep 4, 2013 at 10:31 AM, Lars Yencken wrote: > (completely on the programming side) > > I haven't mastered it, but there seems to be an art to testing your type > assumptions early in Python. > > For example, if you are expecting to be passed in a list that you're going > to append to, or some compatible duck type, you might add a statement to the > top of your function: > > def f(l): > append = l.append > ... > append(v) > > at the top of your code. If you get some other incompatible type, it fails > early rather than in the bowels of your program. These kinds of things > really help you to be productive and safe in a duck-typing world. > > > On 4 September 2013 10:04, Javier Candeira wrote: >> >> On Wed, Sep 4, 2013 at 9:37 AM, dan wrote: >> > Slightly off topic but don't worry you're not the only one who finds it >> > daunting: >> > >> > http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822 >> > >> > It's obviously broken and needs to be fixed but awesome that there's a >> > tool >> > to help work around it in the interim. >> >> Trying to keep the offtopic on-topic, there is an interesting >> parallell between the cognitve loads associated with preferential >> voting and the type of direct democracy practiced in California (where >> they have many ballots at each election for with particular laws or >> "initiative") and the micromanaging of types, access modifiers etc. in >> enterprisey languages such as Java. >> >> There are tradeoffs everywhere. More control means more mental load. >> Lower mental load means less control. Coming from a country where >> Parliament is picked by closed lists, I appreciate the added control >> of preference ranking for Parliament here. But it certainly adds a >> mental toll. >> >> Coming from a language like Python 2, some people appreciate type >> annotations in Python 3, so they don't have to perform guards in their >> code at runtime. >> >> At Monash we're already running our first semester of Data Structures >> and Algorithms using Python instead of Java. I'm now translating >> sample code for students's pracs, and I find myself having to decide >> at every point whether to let some type errors (like comparisons of >> uncomparables types) pass to be caught by the Python runtime, or to >> catch them and do something myself. All of those are errors that would >> be caught by the Java compiler. >> >> It's interesting to see the student forums, because most of the errors >> the students get stuck at are type errors (looking at a Node object >> instead of extracting the item, assigning a variable from a function >> that returns None), and all of those would have been previously caught >> by their IDE. Now they have do debug on the run, and use their brain >> instead of leveraging better tools. >> >> Tradeoffs. >> >> J >> >> _______________________________________________ >> melbourne-pug mailing list >> melbourne-pug at python.org >> https://mail.python.org/mailman/listinfo/melbourne-pug > > > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > From javier at candeira.com Thu Sep 5 04:35:35 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 12:35:35 +1000 Subject: [melbourne-pug] Data type assumptions in Python (was: Yesterday's MPUG session and going forward) In-Reply-To: <7w8uzcuou1.fsf_-_@benfinney.id.au> References: <7w8uzcuou1.fsf_-_@benfinney.id.au> Message-ID: Hi, Ben, unit test is not the problem. I have a sorted list. I can put in all numeric or all strs, or any type that's orderable to all the others: >>> sorted_list(1, 3, 5.0, 7, 6, 4, 2.0) [1, 2.0, 3, 4, 5.0, 6, 7] >>> sorted_list('a', 'c', 'e', 'd', 'b') ['a', 'b', 'c', 'd', 'e'] But if I put in an incompatible/unorderable type, I get a TypeError: not comparable. I'm going to get it somewhere, because >>> 1 > 'a' Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: int() > str() So the question is whether I let the exception be raised by the comparison in the functional code itself (after all it's duck typed, so Python throws the exception for me when it finds it can't pull a comparison), whether I put in a guard and then raise the exception manually or, like Lars says, put in a comparison at the beginning of my block so the exception is raised before the complicated code logic. The tests give the same result in all three cases: the exception must be raised! Actually, a try/except at the beginning allows me to put in my own message: TypeError: str() can't be ordered with the int() types in this list But otherwise, duck typing doesn't help. J On Thu, Sep 5, 2013 at 9:52 AM, Ben Finney wrote: > Lars Yencken writes: > >> I haven't mastered it, but there seems to be an art to testing your type >> assumptions early in Python. > > The art is: Don't test data type assumptions in the code. > > Rather, use EAFP and duck typing, and only test type assumptions in unit > tests. > > > Duck typing means that you stop caring about the type of objects given > to you, and care only about how they behave. ?If it looks like a duck, > and quacks like a duck, we may as well treat it like a duck until it > demonstrates otherwise?. > > EAFP means it is Easier to Ask Forgiveness than Permission. (This is > contrasted with Look Before You Leap, which is discouraged in Python.) > Just use the object you're given as though it will behave the way you > want. If it does, great! If it doesn't an exception is raised and it's > up to the *caller* to deal with that exception since they didn't pass > your code an object with the correct behaviour. > > > Both these approaches allow polymorphism, a powerful language > capability: Your code will accept any object that behaves the right way, > regardless of where the object fits in the type hierarchy, without > needing to special-case each different type. If you need a file-like > object, you don't need the object to inherit from ?file?. You only need > it to implement some subset of the expected behaviour of ?file? ? and > you do that by just using the object like a file. > > If, instead, you have a narrow set of types and check to see the object > fits in that set, then you thwart polymorphism: no-one can implement the > behaviour you expect on an object from elsewhere in the hierarchy (such > as an ?io.StringIO? object, which does not inherit from ?file? at all > but implements a large subset of the behaviour). > > Your code that checks object types will be needlessly rejecting objects > which it could use, and your callers will not be able to do things they > could do in the absence of those needless restrictions. Use duck typing, > and make your callers responsible for passing objects that behave > correctly. > > Likewise, if instead you LBYL in your code, you are attempting to handle > type problems at the wrong location. It should be the caller's > responsibility, not yours, to pass objects that implement the right > behaviour. Your LBYL code will grow more and more error checking, > obscuring the actual functionality that you should be writing. Use EAFP, > and your code will trigger exceptions when those objects don't behave > correctly: it's then the caller's responsibility to handle it. > > > How, then, do you know that your code will behave correctly? Write unit > tests that exercise your functions ? which, if you're doing it right, > are small and loosely coupled with narrow interfaces ? by throwing > objects of various types at them, making sure they use them correctly > and that exceptions are raised where the objects are unsuitable. > > What about letting your callers know the expected behaviour? That's what > the docstring is for. Describe your parameters by their behaviour. Don't > say ?foo is a list of widgets?, if you only need it to be iterable. ?foo > is an iterable of widgets? tells the reader what they need to pass. > > -- > \ ?[Freedom of speech] isn't something somebody else gives you. | > `\ That's something you give to yourself.? ?_Hocus Pocus_, Kurt | > _o__) Vonnegut | > Ben Finney > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug From miked at dewhirst.com.au Thu Sep 5 04:44:28 2013 From: miked at dewhirst.com.au (Mike Dewhirst) Date: Thu, 05 Sep 2013 12:44:28 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: <5227F00C.20606@dewhirst.com.au> On 5/09/2013 12:27pm, Javier Candeira wrote: > Put first an > unguarded expression that might go boom, so it goes boom early. > Brilliant. It's still a hack. So what if your method only cared about a particular attribute of whatever object is passed in? Then maybe ... assert(obj.attribute is not None) ... which reminds me of Eiffel Mike From javier at candeira.com Thu Sep 5 05:53:46 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 13:53:46 +1000 Subject: [melbourne-pug] gaining performance by moving from C++ to Python Message-ID: devblog.moz.com/2013/08/mozscape-leap-from-c-to-python/ J From ben+python at benfinney.id.au Thu Sep 5 06:37:34 2013 From: ben+python at benfinney.id.au (Ben Finney) Date: Thu, 05 Sep 2013 14:37:34 +1000 Subject: [melbourne-pug] Data type assumptions in Python References: <7w8uzcuou1.fsf_-_@benfinney.id.au> Message-ID: <7wppsnlw8h.fsf@benfinney.id.au> Javier Candeira writes: > I have a sorted list. What do you mean? Is this a Python builtin list that you have sorted? If not, where did this ?sorted_list? come from? > I can put in all numeric or all strs, or any type that's orderable to > all the others: > > >>> sorted_list(1, 3, 5.0, 7, 6, 4, 2.0) > [1, 2.0, 3, 4, 5.0, 6, 7] > >>> sorted_list('a', 'c', 'e', 'd', 'b') > ['a', 'b', 'c', 'd', 'e'] > > But if I put in an incompatible/unorderable type, I get a TypeError: > not comparable. Who is ?I? in all this? There are multiple points of responsibility being discussed, and I don't know which one you're identifying with by ?I?. -- \ ?Dare to be na?ve.? ?Richard Buckminster Fuller, personal motto | `\ | _o__) | Ben Finney From ben+python at benfinney.id.au Thu Sep 5 06:48:57 2013 From: ben+python at benfinney.id.au (Ben Finney) Date: Thu, 05 Sep 2013 14:48:57 +1000 Subject: [melbourne-pug] Data type assumptions in Python (was: Yesterday's MPUG session and going forward) References: Message-ID: <7wk3ivlvpi.fsf_-_@benfinney.id.au> Lars Yencken writes: > For example, if you are expecting to be passed in a list that you're > going to append to, or some compatible duck type There's a misunderstanding here. ?Duck typing? refers to a *principle* to be followed in the practice of programming; it is not an attribute of types themselves. It makes no sense to say that a type is ?some compatible duck type?. That is, a list is not ?a duck type?, nor is a list ?not a duck type?. The program code that *uses* the object is either following the principle of duck typing ? i.e. testing an object's type only by watching how the object behaves ? or is not following that principle. The type of the object doesn't matter for that term. > you might add a statement to the top of your function: > > def f(l): > append = l.append > ... > append(v) > > at the top of your code. If you get some other incompatible type, it > fails early rather than in the bowels of your program. These kinds of > things really help you to be productive and safe in a duck-typing > world. Why is it a problem for the exception to be raised within the bowels of your program? I'm not saying there can't be a reason, but you haven't said what the problem is. In many cases, it is quite helpful that the bowels of your program is where you want the exception raised from. Without knowing what trouble this causes you, I don't know what to say. From javier at candeira.com Thu Sep 5 07:03:30 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 15:03:30 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: <7wppsnlw8h.fsf@benfinney.id.au> References: <7w8uzcuou1.fsf_-_@benfinney.id.au> <7wppsnlw8h.fsf@benfinney.id.au> Message-ID: On Thu, Sep 5, 2013 at 2:37 PM, Ben Finney wrote: > Javier Candeira writes: >> I have a sorted list. > > What do you mean? Is this a Python builtin list that you have sorted? If > not, where did this ?sorted_list? come from? Yes, sorry, it's my own SortedList where I have overloaded __init__() and append() so contents have a 'sorted order' invariant. I thought it was clear, because I had written earlier that this typing issue crops up when writing the following simple year 1 data structures for my students: binary search tree, ordered list, heap, etc... >> But if I put in an incompatible/unorderable type, I get a TypeError: >> not comparable. > > Who is ?I? in all this? There are multiple points of responsibility > being discussed, and I don't know which one you're identifying with by > ?I?. "I" there is the user of the list. I was describing how the list works. Better said: whoever uses the list will get a "TypeError: unorderable types" exception if they attempt to put into the same instance of SortedList, for instance, a tuple and a string. Or an int and a list. Or any pair of items belonging to types that don't have a well defined reciprocal ordering. At risk of repeating myself: - in the naive implementation, the TypeError will arise on insertion, when the first functional comparison is made: if newitem > existingitem. - in the guarded implementation, the code checks that, if there already items in the list, at least the new item is orderable with regards to the one in li[0], and then raises its own TypeError exception manually (allowing for a structure-specific error message like "TypeError: unorderable types in sorted list:"). - in the Lars implementation, there is a comparison at the top of the method, that way the error is raised by Python, but at a part where it's not confusing because it's not down in the guts of the method, so it can't be any other type of functional bug. I don't think there's any way for an OrderedList.insert(self, item) method not to throw a TypeError exception in these circumstances. Testing may tell you how not to raise TypeErrors when *using* this SortedList, but it doesn't tell you which of the options to choose when *coding* a SortedList. Sorry for the confusing "I", I hope this makes my point clearer. J From lars at yencken.org Thu Sep 5 07:14:50 2013 From: lars at yencken.org (Lars Yencken) Date: Thu, 5 Sep 2013 15:14:50 +1000 Subject: [melbourne-pug] gaining performance by moving from C++ to Python In-Reply-To: References: Message-ID: I can happily recommend gevent. The language game that I briefly presented on Monday is running of gevent and Flask. As of Monday it only had a handful of users each day, but It took off the next day. It's hit 100,000 visitors and 2.5 million pageviews since then, and gevent's handled things pretty well. On 5 September 2013 13:53, Javier Candeira wrote: > devblog.moz.com/2013/08/mozscape-leap-from-c-to-python/ > > J > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at yencken.org Thu Sep 5 07:35:44 2013 From: lars at yencken.org (Lars Yencken) Date: Thu, 5 Sep 2013 15:35:44 +1000 Subject: [melbourne-pug] Data type assumptions in Python (was: Yesterday's MPUG session and going forward) In-Reply-To: <7wk3ivlvpi.fsf_-_@benfinney.id.au> References: <7wk3ivlvpi.fsf_-_@benfinney.id.au> Message-ID: On 5 September 2013 14:48, Ben Finney wrote: > Lars Yencken writes: > > > For example, if you are expecting to be passed in a list that you're > > going to append to, or some compatible duck type > > There's a misunderstanding here. ?Duck typing? refers to a *principle* > to be followed in the practice of programming; it is not an attribute of > types themselves. It makes no sense to say that a type is ?some > compatible duck type?. > There's no misunderstanding, though perhaps I'm slightly abusing terminology. When I say "a list or compatible duck type", I mean a list or something that quacks like a list, in that it meets the list-like interface we're actually using in the method. > > you might add a statement to the top of your function: > > > > def f(l): > > append = l.append > > ... > > append(v) > > > > at the top of your code. If you get some other incompatible type, it > > fails early rather than in the bowels of your program. These kinds of > > things really help you to be productive and safe in a duck-typing > > world. > > Why is it a problem for the exception to be raised within the bowels of > your program? I'm not saying there can't be a reason, but you haven't > said what the problem is. > > In many cases, it is quite helpful that the bowels of your program is > where you want the exception raised from. Without knowing what trouble > this causes you, I don't know what to say. I'll give two examples: 1. Large batch scientific jobs, where you might encounter a runtime error after 30 mins (or worse, hours) of partial computation. Even having to wait five minutes to generate an error is not that great. When we have the option, failing earlier is definitely better here. For some top-level methods, failing at the start is much better than failing in the middle. 2. Unicode, unicode, unicode. If you've had to debug code which accepted a mix of strings and unicode, you'll know what a pain it is to get a unicode error deep in the bowels of your app -- essentially the stacktrace is useless, it doesn't explain well enough how the error got there. By capturing assumptions about the input at the border of your stack, instead of throughout it, you can save yourself a lot of pain. I imagine cases like this were a big driver for the revamped string type in Python 3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben+python at benfinney.id.au Thu Sep 5 08:19:33 2013 From: ben+python at benfinney.id.au (Ben Finney) Date: Thu, 05 Sep 2013 16:19:33 +1000 Subject: [melbourne-pug] Data type assumptions in Python References: <7wk3ivlvpi.fsf_-_@benfinney.id.au> Message-ID: <7wsixj94ei.fsf@benfinney.id.au> Lars Yencken writes: > On 5 September 2013 14:48, Ben Finney wrote: > > Why is it a problem for the exception to be raised within the bowels > > of your program? I'm not saying there can't be a reason, but you > > haven't said what the problem is. > > > > In many cases, it is quite helpful that the bowels of your program > > is where you want the exception raised from. Without knowing what > > trouble this causes you, I don't know what to say. > > I'll give two examples: > > 1. Large batch scientific jobs, where you might encounter a runtime error > after 30 mins (or worse, hours) of partial computation. Right. This is an argument for capturing errors at a high level, and reporting them with high-level context. > 2. Unicode, unicode, unicode. If you've had to debug code which > accepted a mix of strings and unicode, you'll know what a pain it is > to get a unicode error deep in the bowels of your app -- essentially > the stacktrace is useless, it doesn't explain well enough how the > error got there. Isn't the exact function of a call stack to show in detail how the interpreter got to the point of an exception? What information about ?how it got there? are you expecting that isn't provided by a stack trace? > By capturing assumptions about the input at the border of your stack, > instead of throughout it, you can save yourself a lot of pain. Yes. Again, this is an argument for capturing errors at a high enough level to provide context. Neither of these is an argument for doing type checking deep within the code, as you seemt o advocate. Instead, these are arguments for allowing low-level exceptions to propagate up to the caller until they reach a point of responsibility where there is enough context to handle the exception. -- \ ?The generation of random numbers is too important to be left | `\ to chance.? ?Robert R. Coveyou | _o__) | Ben Finney From jbarham at gmail.com Thu Sep 5 08:21:06 2013 From: jbarham at gmail.com (John Barham) Date: Thu, 5 Sep 2013 16:21:06 +1000 Subject: [melbourne-pug] gaining performance by moving from C++ to Python In-Reply-To: References: Message-ID: Lars is too modest to mention that one of the reasons traffic to the Great Language Game took off is that it made the front page of Hacker News: https://news.ycombinator.com/item?id=6318634 On Thu, Sep 5, 2013 at 3:14 PM, Lars Yencken wrote: > I can happily recommend gevent. The language game that I briefly presented > on Monday is running of gevent and Flask. > > As of Monday it only had a handful of users each day, but It took off the > next day. It's hit 100,000 visitors and 2.5 million pageviews since then, > and gevent's handled things pretty well. > > > On 5 September 2013 13:53, Javier Candeira wrote: >> >> devblog.moz.com/2013/08/mozscape-leap-from-c-to-python/ >> >> J >> _______________________________________________ >> melbourne-pug mailing list >> melbourne-pug at python.org >> https://mail.python.org/mailman/listinfo/melbourne-pug > > > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > From tobias.sargeant at gmail.com Thu Sep 5 08:42:07 2013 From: tobias.sargeant at gmail.com (Tobias Sargeant) Date: Thu, 5 Sep 2013 16:42:07 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: <7wsixj94ei.fsf@benfinney.id.au> References: <7wk3ivlvpi.fsf_-_@benfinney.id.au> <7wsixj94ei.fsf@benfinney.id.au> Message-ID: I would also add that if you need to check runtime constraints in your code, then the right mechanism is an assert. There are a few reasons for my belief. IMO, runtime constraints should: * be side effect free * be able to be optimized away * clearly convey information to readers of your code Binding l.append (as an example) doesn't fulfill any of these criteria. It makes namespace changes, it looks like an optimization, rather than a type constraint. It confuses the reading of code which calls the bound append (is it a function? A bound method? What object is it affecting?). It's also not idiomatic (how would you convey that you expect an integer? or one of a selection of types?) which means that someone else can't clearly mentally separate code from annotation. Sorry to be strident about this, but I think these are important points. You could (and I would) argue that optional type annotation is a useful syntactic sugar for this common use case for assertions, with the side-effect of providing information for a JIT. You could also argue that none of this is necessary, and the best solution is to write a comprehensive test suite. I think there's something to be said for both positions. Toby. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben+python at benfinney.id.au Thu Sep 5 08:48:16 2013 From: ben+python at benfinney.id.au (Ben Finney) Date: Thu, 05 Sep 2013 16:48:16 +1000 Subject: [melbourne-pug] Data type assumptions in Python References: <7w8uzcuou1.fsf_-_@benfinney.id.au> <7wppsnlw8h.fsf@benfinney.id.au> Message-ID: <7wmwnr932n.fsf@benfinney.id.au> Javier Candeira writes: > On Thu, Sep 5, 2013 at 2:37 PM, Ben Finney wrote: > > Javier Candeira writes: > >> I have a sorted list. > > > > What do you mean? Is this a Python builtin list that you have > >sorted? If not, where did this ?sorted_list? come from? > > Yes, sorry, it's my own SortedList where I have overloaded __init__() > and append() so contents have a 'sorted order' invariant. Okay. If you are implementing a type with its own invariants, then checking whether those invariants are true is necessary. That is, if your code implements the invariant ?every item in this collection is comparable with each other item?, then of course you need something in your code that's going to fail when attempting to add an item that would violate the invariant. I wouldn't call it ?LBYL checking? (?I'm about to try something, will it cause an error??) or ?type checking? (?Is this object of a specific narrow set of types??). Both of those make for poor code, and are not needed for the purpose you describe. You're still best advised to use EAFP and duck typing. So, instead of checking the type of the new item, or testing whether there's going to be an error before doing something with it, you just go ahead and do it. To ensure your invariant, you have no option but to compare the new item against all existing items ? you're testing behaviour, by just doing what you need to do instead of asking permission first. This means that adding an item to your collection will be an O(n) operation, but invariants like you describe have a cost and this appears to be one. Myself, I try to avoid promising an invariant like that :-) and just tell the reader what the code expects its arguments to do. > - in the naive implementation, the TypeError will arise on insertion, > when the first functional comparison is made: if newitem > > existingitem. What's wrong with that, then? You can combine it with the approach you describe below: > [?] then raises its own TypeError exception manually (allowing for a > structure-specific error message like "TypeError: unorderable types in > sorted list:"). Good, but better to do it as a chained exception:: self.collection.insert(item) try: self.collection.sort() except TypeError as exc: raise TypeError("unorderable types in sorted list") from exc (I'm sure Javier already knows about chained exceptions, but I hope other readers will benefit from learning about this Python 3 feature.) > - in the Lars implementation, there is a comparison at the top of the > method, that way the error is raised by Python, but at a part where > it's not confusing because it's not down in the guts of the method, so > it can't be any other type of functional bug. I think it's a good idea to minimise the amount of code in a ?try? block, for the reason you point out: you want to narrow down exactly what could be causing an exception to be raised. I don't think that's an argument for making additional checks at the top of a function. > I don't think there's any way for an OrderedList.insert(self, item) > method not to throw a TypeError exception in these circumstances. Of course! I think raising a TypeError is the right thing to do, when one tries to *use* an object in a manner incompatible with its type. But this is not *checking* the type ? it is a type keeping its promises about how its instances will behave. That way, no one needs to check the type, because false assumptions will lead to an appropriate exception :-) -- \ ?With Lisp or Forth, a master programmer has unlimited power | `\ and expressiveness. With Python, even a regular guy can reach | _o__) for the stars.? ?Raymond Hettinger | Ben Finney From javier at candeira.com Thu Sep 5 09:02:15 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 17:02:15 +1000 Subject: [melbourne-pug] gaining performance by moving from C++ to Python In-Reply-To: References: Message-ID: I use gevent and gevent.monkey.patch() to asynch-ronize (if that means anything) my provisioning scripts for rackspace hosts. The script can launch several provisioning operations in parallell with a couple of very simple additions to what, otherwise, is a straight one-instruction-after-another piece of code. Which makes me think that maybe we should make a small presentation of gevent one day. J On Thu, Sep 5, 2013 at 3:14 PM, Lars Yencken wrote: > I can happily recommend gevent. The language game that I briefly presented > on Monday is running of gevent and Flask. > > As of Monday it only had a handful of users each day, but It took off the > next day. It's hit 100,000 visitors and 2.5 million pageviews since then, > and gevent's handled things pretty well. > > > On 5 September 2013 13:53, Javier Candeira wrote: >> >> devblog.moz.com/2013/08/mozscape-leap-from-c-to-python/ >> >> J >> _______________________________________________ >> melbourne-pug mailing list >> melbourne-pug at python.org >> https://mail.python.org/mailman/listinfo/melbourne-pug > > > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > From javier at candeira.com Thu Sep 5 09:07:05 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 17:07:05 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: <7wmwnr932n.fsf@benfinney.id.au> References: <7w8uzcuou1.fsf_-_@benfinney.id.au> <7wppsnlw8h.fsf@benfinney.id.au> <7wmwnr932n.fsf@benfinney.id.au> Message-ID: Ben, I think we're saying the same things in a different accent. Just one thing. Comparability is transitive, so I don't have to test comparability of the new element with all existing elements. I only have to check whether it's comparable to the first or root item in the structure. So that test is O(1), not O(n). And all this came from a discussion on tradeoffs. Java generics guarantee this invariant by putting the onus on the compiler. They also make some manners of polymorphism more difficult, or at least much more verbose. Tradeoffs! J On Thu, Sep 5, 2013 at 4:48 PM, Ben Finney wrote: > Javier Candeira writes: > >> On Thu, Sep 5, 2013 at 2:37 PM, Ben Finney wrote: >> > Javier Candeira writes: >> >> I have a sorted list. >> > >> > What do you mean? Is this a Python builtin list that you have >> >sorted? If not, where did this ?sorted_list? come from? >> >> Yes, sorry, it's my own SortedList where I have overloaded __init__() >> and append() so contents have a 'sorted order' invariant. > > Okay. If you are implementing a type with its own invariants, then > checking whether those invariants are true is necessary. > > That is, if your code implements the invariant ?every item in this > collection is comparable with each other item?, then of course you need > something in your code that's going to fail when attempting to add an > item that would violate the invariant. > > I wouldn't call it ?LBYL checking? (?I'm about to try something, will it > cause an error??) or ?type checking? (?Is this object of a specific > narrow set of types??). Both of those make for poor code, and are not > needed for the purpose you describe. You're still best advised to use > EAFP and duck typing. > > So, instead of checking the type of the new item, or testing whether > there's going to be an error before doing something with it, you just go > ahead and do it. To ensure your invariant, you have no option but to > compare the new item against all existing items ? you're testing > behaviour, by just doing what you need to do instead of asking > permission first. > > This means that adding an item to your collection will be an O(n) > operation, but invariants like you describe have a cost and this appears > to be one. > > Myself, I try to avoid promising an invariant like that :-) and just > tell the reader what the code expects its arguments to do. > >> - in the naive implementation, the TypeError will arise on insertion, >> when the first functional comparison is made: if newitem > >> existingitem. > > What's wrong with that, then? You can combine it with the approach you > describe below: > >> [?] then raises its own TypeError exception manually (allowing for a >> structure-specific error message like "TypeError: unorderable types in >> sorted list:"). > > Good, but better to do it as a chained exception:: > > self.collection.insert(item) > try: > self.collection.sort() > except TypeError as exc: > raise TypeError("unorderable types in sorted list") from exc > > (I'm sure Javier already knows about chained exceptions, but I hope > other readers will benefit from learning about this Python 3 feature.) > >> - in the Lars implementation, there is a comparison at the top of the >> method, that way the error is raised by Python, but at a part where >> it's not confusing because it's not down in the guts of the method, so >> it can't be any other type of functional bug. > > I think it's a good idea to minimise the amount of code in a ?try? > block, for the reason you point out: you want to narrow down exactly > what could be causing an exception to be raised. > > I don't think that's an argument for making additional checks at the top > of a function. > >> I don't think there's any way for an OrderedList.insert(self, item) >> method not to throw a TypeError exception in these circumstances. > > Of course! I think raising a TypeError is the right thing to do, when > one tries to *use* an object in a manner incompatible with its type. But > this is not *checking* the type ? it is a type keeping its promises > about how its instances will behave. > > That way, no one needs to check the type, because false assumptions will > lead to an appropriate exception :-) > > -- > \ ?With Lisp or Forth, a master programmer has unlimited power | > `\ and expressiveness. With Python, even a regular guy can reach | > _o__) for the stars.? ?Raymond Hettinger | > Ben Finney > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug From john.larooy at gmail.com Thu Sep 5 09:07:25 2013 From: john.larooy at gmail.com (John La Rooy) Date: Thu, 5 Sep 2013 17:07:25 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: I think it's better to use def (L): assert isinstance(L, list) ... This has a few of advantages. You can remove the overhead by running with "python -O". IDEs such as wingide use it as a helper for type inference. Just checking that there is an append attribute really doesn't reassure me that it's even a method. PEP8 strongly discourages using l as a variable name John La Rooy On Wed, Sep 4, 2013 at 10:31 AM, Lars Yencken wrote: > (completely on the programming side) > > I haven't mastered it, but there seems to be an art to testing your type > assumptions early in Python. > > For example, if you are expecting to be passed in a list that you're going > to append to, or some compatible duck type, you might add a statement to > the top of your function: > > def f(l): > append = l.append > ... > append(v) > > at the top of your code. If you get some other incompatible type, it fails > early rather than in the bowels of your program. These kinds of things > really help you to be productive and safe in a duck-typing world. > > > On 4 September 2013 10:04, Javier Candeira wrote: > >> On Wed, Sep 4, 2013 at 9:37 AM, dan wrote: >> > Slightly off topic but don't worry you're not the only one who finds it >> > daunting: >> > >> http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822 >> > >> > It's obviously broken and needs to be fixed but awesome that there's a >> tool >> > to help work around it in the interim. >> >> Trying to keep the offtopic on-topic, there is an interesting >> parallell between the cognitve loads associated with preferential >> voting and the type of direct democracy practiced in California (where >> they have many ballots at each election for with particular laws or >> "initiative") and the micromanaging of types, access modifiers etc. in >> enterprisey languages such as Java. >> >> There are tradeoffs everywhere. More control means more mental load. >> Lower mental load means less control. Coming from a country where >> Parliament is picked by closed lists, I appreciate the added control >> of preference ranking for Parliament here. But it certainly adds a >> mental toll. >> >> Coming from a language like Python 2, some people appreciate type >> annotations in Python 3, so they don't have to perform guards in their >> code at runtime. >> >> At Monash we're already running our first semester of Data Structures >> and Algorithms using Python instead of Java. I'm now translating >> sample code for students's pracs, and I find myself having to decide >> at every point whether to let some type errors (like comparisons of >> uncomparables types) pass to be caught by the Python runtime, or to >> catch them and do something myself. All of those are errors that would >> be caught by the Java compiler. >> >> It's interesting to see the student forums, because most of the errors >> the students get stuck at are type errors (looking at a Node object >> instead of extracting the item, assigning a variable from a function >> that returns None), and all of those would have been previously caught >> by their IDE. Now they have do debug on the run, and use their brain >> instead of leveraging better tools. >> >> Tradeoffs. >> >> J >> _______________________________________________ >> melbourne-pug mailing list >> melbourne-pug at python.org >> https://mail.python.org/mailman/listinfo/melbourne-pug >> > > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.larooy at gmail.com Thu Sep 5 09:10:07 2013 From: john.larooy at gmail.com (John La Rooy) Date: Thu, 5 Sep 2013 17:10:07 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: <5227F00C.20606@dewhirst.com.au> References: <5227F00C.20606@dewhirst.com.au> Message-ID: On Thu, Sep 5, 2013 at 12:44 PM, Mike Dewhirst wrote: > On 5/09/2013 12:27pm, Javier Candeira wrote: > >> Put first an >> unguarded expression that might go boom, so it goes boom early. >> Brilliant. It's still a hack. >> > > So what if your method only cared about a particular attribute of whatever > object is passed in? > > Then maybe ... > > assert(obj.attribute is not None) > > ... which reminds me of Eiffel > > Mike > > What if obj.attribute is allowed to be None? assert(obj.attribute) would work fine. John La Rooy -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier at candeira.com Thu Sep 5 09:10:52 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 17:10:52 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: On Thu, Sep 5, 2013 at 5:07 PM, John La Rooy wrote: > def (L): > assert isinstance(L, list) But that way you don work well with "duck lists". Or, in my case, you lose polymorphism (a pythonic SortedList will work with any orderable type). Maybe I could "assert arerelativeorderable(newelement, firstelement), but that's what I do by writing "try: newelement > itemzero; except: BOOM" > PEP8 strongly discourages using l as a variable name It says nothing about email discussions! J From william.leslie.ttg at gmail.com Thu Sep 5 10:19:00 2013 From: william.leslie.ttg at gmail.com (William ML Leslie) Date: Thu, 5 Sep 2013 18:19:00 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: References: <7w8uzcuou1.fsf_-_@benfinney.id.au> <7wppsnlw8h.fsf@benfinney.id.au> <7wmwnr932n.fsf@benfinney.id.au> Message-ID: On 5 September 2013 17:07, Javier Candeira wrote: > Just one thing. Comparability is transitive, so I don't have to test > comparability of the new element with all existing elements. I only > have to check whether it's comparable to the first or root item in the > structure. So that test is O(1), not O(n). Well, you hope that comparability is transitive. In python 2, *order* wasn't even transitive between the provided numeric types: both decimal and float would order correctly with respect to int, but not with respect to each other. Maybe there's a bit of a flat spot in python teaching in that people don't know how to use NotImplemented correctly. On the other hand, correctly used NotImplemented and __radd__ can't actually solve the problem of two numeric types implemented in isolation. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. From tleeuwenburg at gmail.com Thu Sep 5 10:20:39 2013 From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg) Date: Thu, 5 Sep 2013 18:20:39 +1000 Subject: [melbourne-pug] Yesterday's MPUG session and going forward In-Reply-To: References: Message-ID: Does anyone have a practical example? I have never had a particular issue with type safety in Python, with the exception of gotchas around floating-point division where I accidentally divided by the integer returned by a function without casting it to float. On Thu, Sep 5, 2013 at 5:10 PM, Javier Candeira wrote: > On Thu, Sep 5, 2013 at 5:07 PM, John La Rooy > wrote: > > def (L): > > assert isinstance(L, list) > > But that way you don work well with "duck lists". Or, in my case, you > lose polymorphism (a pythonic SortedList will work with any orderable > type). Maybe I could "assert arerelativeorderable(newelement, > firstelement), but that's what I do by writing "try: newelement > > itemzero; except: BOOM" > > > PEP8 strongly discourages using l as a variable name > > It says nothing about email discussions! > > J > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > -- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" -------------- next part -------------- An HTML attachment was scrubbed... URL: From tleeuwenburg at gmail.com Thu Sep 5 10:27:47 2013 From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg) Date: Thu, 5 Sep 2013 18:27:47 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: References: <7w8uzcuou1.fsf_-_@benfinney.id.au> <7wppsnlw8h.fsf@benfinney.id.au> <7wmwnr932n.fsf@benfinney.id.au> Message-ID: Sorry, but doesn't this just boil down to the original poster (I think Javier) writing a sorted-order list which only implemented some of the desired behaviour? There's nothing wrong with using a try:except: block in your insert method which logs an error, refuses to accept the item, but allows processing to continue, if that's what you want. It just sounds like an example where error-handling policy isn't defined. In leiu of actual rules about how to handle the exceptions, throwing a TypeError seems like very acceptable naive behaviour. Even in other languages, it's possible to end up with exceptions based on type issues in data structures, Python is not unique in that. Perhaps I've missed the point, but I feel like it's just the same old "in the face of ambiguity, resist the temptation to guess" principle. Javier, perhaps you could post your code to pastebin and we can have a more specific conversation? Also, Javier, thanks for the interesting code-related thread to discuss! :) On Thu, Sep 5, 2013 at 6:19 PM, William ML Leslie < william.leslie.ttg at gmail.com> wrote: > On 5 September 2013 17:07, Javier Candeira wrote: > > Just one thing. Comparability is transitive, so I don't have to test > > comparability of the new element with all existing elements. I only > > have to check whether it's comparable to the first or root item in the > > structure. So that test is O(1), not O(n). > > Well, you hope that comparability is transitive. In python 2, *order* > wasn't even transitive between the provided numeric types: both > decimal and float would order correctly with respect to int, but not > with respect to each other. > > Maybe there's a bit of a flat spot in python teaching in that people > don't know how to use NotImplemented correctly. On the other hand, > correctly used NotImplemented and __radd__ can't actually solve the > problem of two numeric types implemented in isolation. > > -- > William Leslie > > Notice: > Likely much of this email is, by the nature of copyright, covered > under copyright law. You absolutely may reproduce any part of it in > accordance with the copyright law of the nation you are reading this > in. Any attempt to deny you those rights would be illegal without > prior contractual agreement. > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > -- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.leslie.ttg at gmail.com Thu Sep 5 10:37:58 2013 From: william.leslie.ttg at gmail.com (William ML Leslie) Date: Thu, 5 Sep 2013 18:37:58 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: References: <7w8uzcuou1.fsf_-_@benfinney.id.au> <7wppsnlw8h.fsf@benfinney.id.au> <7wmwnr932n.fsf@benfinney.id.au> Message-ID: On 4 September 2013 19:09, Clare Sloggett wrote: > Lack of types are the cause of most of my python issues too. Maybe we need > types that you don't HAVE to declare if you don't want :) I've had a few people say something like this to me over the years. Do many of you find this to be the case? I could probably count the number of times I've had a type-related error in python code on one hand, of those, I only know of one that would have been caught by a traditional simple static type system a-la Java (specifically, iterating over dicts yields keys, which is the correct behaviour, but after working in other languages, I often write "for key, value in the_dict:" as if it were in muscle memory). I've spent the last few months of afternoons using mostly statically typed languages (working on some projects in Haskell, experimenting with Idris and Agda for some future research). Having dependant types is very useful, but because of the mental energy required in getting the types right, I certainly feel I write a lower quality of code in those languages. The "type system" of my python code, on the other hand, is always pretty straightforward, because it describes precisely what I need it to. Hopefully, the module documentation describes all you need to know to pass me the right data. The cause of most of MY issues are the fact that Haskell somehow thinks that open imports are a reasonable default. You want to search for the definition of this data type? Good luck with that, even etags gets it wrong. You want to find usages of this constructor? You'll need to grep for it. You only want to know about its appearance in patterns, or only in applications? You wish. A fantastic static type system that is of no assistance to you at all. Wheras in python, people who write large projects assume you're going to want greppable method names and decent import statements. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. From brian at microcomaustralia.com.au Thu Sep 5 11:04:40 2013 From: brian at microcomaustralia.com.au (Brian May) Date: Thu, 5 Sep 2013 19:04:40 +1000 Subject: [melbourne-pug] Data type assumptions in Python (was: Yesterday's MPUG session and going forward) In-Reply-To: <7wk3ivlvpi.fsf_-_@benfinney.id.au> References: <7wk3ivlvpi.fsf_-_@benfinney.id.au> Message-ID: On 5 September 2013 14:48, Ben Finney wrote: > Why is it a problem for the exception to be raised within the bowels of > your program? I'm not saying there can't be a reason, but you haven't > said what the problem is. > The earlier you catch the error, the faster you can debug the source problem and fix it. Have had many cases where an error in a parameter to a function doesn't show up until sometime later after the function has returned, making it very hard to find out what the error was. Worse still, there are some errors that will just give incorrect results without giving an error. Much easier to catch the errors as soon as possible. Having asserts through your code also helps document the assumptions you made when you wrote it, which in turn makes it easier to understand the code. -- Brian May -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier at candeira.com Thu Sep 5 13:02:34 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 21:02:34 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: References: <7w8uzcuou1.fsf_-_@benfinney.id.au> <7wppsnlw8h.fsf@benfinney.id.au> <7wmwnr932n.fsf@benfinney.id.au> Message-ID: On Thu, Sep 5, 2013 at 6:19 PM, William ML Leslie wrote: > On 5 September 2013 17:07, Javier Candeira wrote: >> Just one thing. Comparability is transitive, so I don't have to test >> comparability of the new element with all existing elements. I only >> have to check whether it's comparable to the first or root item in the >> structure. So that test is O(1), not O(n). > > Well, you hope that comparability is transitive. In python 2, *order* > wasn't even transitive between the provided numeric types: both > decimal and float would order correctly with respect to int, but not > with respect to each other. Good point, and great history lesson. However, that is a serious bug in the implementation in the provided numeric types, not in the sorted list implementation. Some expectations are reasonable. J From javier at candeira.com Thu Sep 5 13:14:30 2013 From: javier at candeira.com (Javier Candeira) Date: Thu, 5 Sep 2013 21:14:30 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: References: <7w8uzcuou1.fsf_-_@benfinney.id.au> <7wppsnlw8h.fsf@benfinney.id.au> <7wmwnr932n.fsf@benfinney.id.au> Message-ID: On Thu, Sep 5, 2013 at 6:27 PM, Tennessee Leeuwenburg wrote: > Sorry, but doesn't this just boil down to the original poster (I think > Javier) writing a sorted-order list which only implemented some of the > desired behaviour? There's nothing wrong with using a try:except: block in What do you mean "only some". It preserves order over initialisation, insertion and deletion. What else do you need? > your insert method which logs an error, refuses to accept the item, but > allows processing to continue, if that's what you want. It just sounds like That should be a user option: - The sorted list does well to raise a TypeError when you try to add 'a' to a list that contains, say, integers. - The calling code calls sortedlist.insert() inside a try/except, and the calling programmer gets to decide whether to forgive and continue or abort the operation. > an example where error-handling policy isn't defined. But I disagree. It's clear the TypeError should be thrown. > In leiu of actual rules about how to handle the exceptions, throwing a > TypeError seems like very acceptable naive behaviour. Even in other > languages, it's possible to end up with exceptions based on type issues in > data structures, Python is not unique in that. My point, my only point, was about diferent tradeoffs in making things simple or giving you power. In Java type safety is a mental load that is carried by Intellisense in the IDE. Not that I like Java, in fact we are moving a whole unit from Java to Python, but students used to not have these bugs, because they didn't even consider them bugs. They were syntax errors in the editor. So no need to put an exception guard in Java, because the type system did it for you. In Python genericity is a given. In Java you have to navigate implements and extends and bounded type parameters. The mental load is taken somewhere else. These are tradeoffs. Type inference claims to save you from most of the tradeoffs, allowing you to not live at either end (the dinamicity of Python, or the bureaucratc regimented genericity of Java). But I'll let you know when I learn a bit of Scala where I think the tradeoffs are, what you lose when you gain strong typing with type inference. > Perhaps I've missed the point, but I feel like it's just the same old "in > the face of ambiguity, resist the temptation to guess" principle. > > Javier, perhaps you could post your code to pastebin and we can have a more > specific conversation? No need. I didn't actually have questions. Just reflections, thoughts out loud. > Also, Javier, thanks for the interesting code-related thread to discuss! :) No worries, I'm having fun too, and learning a lot from the community. J From ben+python at benfinney.id.au Thu Sep 5 21:14:17 2013 From: ben+python at benfinney.id.au (Ben Finney) Date: Fri, 06 Sep 2013 05:14:17 +1000 Subject: [melbourne-pug] Data type assumptions in Python References: <7wk3ivlvpi.fsf_-_@benfinney.id.au> Message-ID: <7wob87ytbq.fsf@benfinney.id.au> Brian May writes: > On 5 September 2013 14:48, Ben Finney wrote: > > > Why is it a problem for the exception to be raised within the bowels > > of your program? I'm not saying there can't be a reason, but you > > haven't said what the problem is. > > The earlier you catch the error, the faster you can debug the source > problem and fix it. Yes, failing earlier is better when you're trying to identify a problem. But ?earlier? here means ?earlier in the testing process?. A bug raised from deep within the program can provide *more* specific information, helping to trace the assumptions being made at the various levels of the program and informing your debugging efforts. So I'll agree that it's important to *catch* errors at a high enough level to provide context. But it's also important for the error to be *raised* from whatever level of the code actually triggers the fault ? which is often deep within the bowels of the program, making that a *good* place to raise the error. > Have had many cases where an error in a parameter to a function > doesn't show up until sometime later after the function has returned, > making it very hard to find out what the error was. My response to that is to recommend better unit tests, better coverage by those tests, and functions which do fewer things so each one is easier to rule out as a source of the problem. > Worse still, there are some errors that will just give incorrect > results without giving an error. This is not an argument for type checking. > Much easier to catch the errors as soon as possible. Agreed. None of that speaks against ?errors from within the bowels of the program?, though. -- \ ?I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.? ?Douglas Adams | Ben Finney From miked at dewhirst.com.au Fri Sep 6 00:40:32 2013 From: miked at dewhirst.com.au (Mike Dewhirst) Date: Fri, 06 Sep 2013 08:40:32 +1000 Subject: [melbourne-pug] Data type assumptions in Python In-Reply-To: <7wob87ytbq.fsf@benfinney.id.au> References: <7wk3ivlvpi.fsf_-_@benfinney.id.au> <7wob87ytbq.fsf@benfinney.id.au> Message-ID: <52290860.7090502@dewhirst.com.au> On 6/09/2013 5:14am, Ben Finney wrote: > Brian May writes: > >> On 5 September 2013 14:48, Ben Finney wrote: >> >>> Why is it a problem for the exception to be raised within the bowels >>> of your program? I'm not saying there can't be a reason, but you >>> haven't said what the problem is. >> >> The earlier you catch the error, the faster you can debug the source >> problem and fix it. > > Yes, failing earlier is better when you're trying to identify a problem. > But ???earlier??? here means ???earlier in the testing process???. > > A bug raised from deep within the program can provide *more* specific > information, helping to trace the assumptions being made at the various > levels of the program and informing your debugging efforts. > > So I'll agree that it's important to *catch* errors at a high enough > level to provide context. But it's also important for the error to be > *raised* from whatever level of the code actually triggers the fault ??? > which is often deep within the bowels of the program, making that a > *good* place to raise the error. > >> Have had many cases where an error in a parameter to a function >> doesn't show up until sometime later after the function has returned, >> making it very hard to find out what the error was. Someone mentioned errors occurring after hours of running. To cope(*) with that I would throw elegance to the wind and use logging to record all exceptions without stopping the process. * cope = remain sane Mike > > My response to that is to recommend better unit tests, better coverage > by those tests, and functions which do fewer things so each one is > easier to rule out as a source of the problem. > >> Worse still, there are some errors that will just give incorrect >> results without giving an error. > > This is not an argument for type checking. > >> Much easier to catch the errors as soon as possible. > > Agreed. None of that speaks against ???errors from within the bowels of > the program???, though. > From lev at levlafayette.com Sun Sep 8 14:15:47 2013 From: lev at levlafayette.com (Lev Lafayette) Date: Sun, 8 Sep 2013 22:15:47 +1000 Subject: [melbourne-pug] Linux Users of Victoria and Free Software Melbourne Present... Message-ID: Linux Users of Victoria and Free Software Melbourne Present... Software Freedom Day 2013 : Free Software for a Free Society Software Freedom Day is an international event celebrating of Free Software. Starting in 2004 in now hosts over a thousand events in over forty countries. The Melbourne event will be held on Saturday, September 21st, 9.30 to 17.00 at 110 Grey Street East Melbourne (Melbourne Unitarian Church hall) It's about 5 minutes from Jolimont Station , or a brisk 10 minute walk from Parliament station or West Richmond. There's plenty of parking at the site as well! Speakers 9.30 Introduction: Video Welcome from Dr. Richard Stallman 10.00 Andrew Pam, Content Creation with Free Software Tools 11.00 Pat Sunter, Free and Open Source In Public Decision-Making 12.00 Adam Bolte, Protecting Yourself Online 13.00 Lunch 14.00 Ben McGuiness, Pirate Party's Policy on Copyright and Patents 15.00 Kathy Reid, The Orgnisation of Free Software Communities 16.00 Lev Lafayette, Beyond Software - Steps Towards A Free Society Plus plenty of t-shirts, software and other paraphernalia giveaways, videos and a free lunch (with open sauce). -- Lev Lafayette, BA (Hons), GCertPM, MBA mobile: 0432 255 208 RFC 1855 Netiquette Guidelines http://www.ietf.org/rfc/rfc1855.txt From pwilliams at nswrdn.com.au Tue Sep 10 05:41:29 2013 From: pwilliams at nswrdn.com.au (Peter Williams) Date: Tue, 10 Sep 2013 13:41:29 +1000 Subject: [melbourne-pug] Jobs in Newcastle NSW Message-ID: <522E94E9.3060706@nswrdn.com.au> Hi all The NSW Rural Doctors Network seeks a GRADUATE SYSTEMS ENGINEER and a SYSTEMS ENGINEER TEAM LEADER to be based in our Head Office in Newcastle?s CBD. These positions will provide services to the Information Management team utilising high-level development languages and libraries such as SQL, HTML, Django, Python JavaScript, Linux, Ajax and CSS. Employment is open to Australian citizens, permanent residents and other applicants with the appropriate visa authorisation to work in Australia. The successful candidates will be required to work at the RDN office. http://www.nswrdn.com.au/site/careers If you know anyone who might be interested, please direct them to the URL above. Applications close 27 Sept 2013. Cheers Peter -- Peter J Williams Information Manager NSW Rural Doctors Network Head Office Suite 19, Level 3 133 King Street Newcastle NSW 2300 Telephone: (02) 4924-8000 Facsimile: (02) 4924-8010 Mailto:pwilliams at nswrdn.com.au Web: http://www.nswrdn.com.au From chrisjrn at gmail.com Fri Sep 13 03:03:29 2013 From: chrisjrn at gmail.com (Chris Neugebauer) Date: Fri, 13 Sep 2013 11:03:29 +1000 Subject: [melbourne-pug] PyCon 2014 Call for Proposals due Sunday Message-ID: Hello Python Fans! Just a friendly reminder that proposals for PyCon 2014 Montr?al are due Sunday (15 September)! If you want to talk at the world's biggest gathering of Python developers, get your thinking caps on, and submit something! CFP details are here: https://us.pycon.org/2014/speaking/cfp/ If you don't think you can make the trip, remember that PyCon has a generous financial assistance programme available to those who couldn't otherwise make it ? https://us.pycon.org/2014/assistance/ --Chris On 12 July 2013 04:15, Brian Curtin wrote: > Hi Australian Python Users! > > It's that time of year again! The PyCon website received a beautiful refresh and we're ready to accept proposals for the 2014 conference taking place April 9-17 in Montreal. Check out the new site at http://us.pycon.org/2014 and create your account today! Registration will open in September, so mark your calendars and get ready to head into Canada for another great PyCon. > > We've received record numbers of proposals over each of the last several years, and we expect this year to be no different. For 2012 we received over 500 proposals for talks, tutorials, and posters, and for 2013 we received over 600. This community's excellent submissions have made for schedules where there is just too much good stuff to take in without cloning yourself, which is a problem we're proud to have. Thankfully you can catch up with the talks you missed at http://pyvideo.org/. > > If you're interested in submitting a proposal, take a look at our Call for Proposals at http://us.pycon.org/2014/speaking/cfp/ and poke around the site for advice and resources to help you create a great proposal. New for this year are the addition of Lightning Talk proposals, from which we'll be pre-selecting some of the slots that make up the Lightning Talk sessions. > > > If your company is interested in sponsorship, we need you. Sponsors are what make PyCon a possibility, and sponsorship offers some great values to the generous organizations who support the conference. Check out https://us.pycon.org/2014/sponsors/whysponsor/ to find out what you get out of sponsorship, with a prospectus at https://us.pycon.org/2014/sponsors/prospectus/. Contact Jesse Noller at jnoller at python.org with any sponsorship inquiries. > > Keep an eye out for news on our blog at http://pycon.blogspot.com/ and follow us on twitter at https://twitter.com/pycon > > Diana Clarke, Chairwoman > diana.joan.clarke at gmail.com > > Brian Curtin, Publicity Coordinator > brian at python.org > > > _______________________________________________ > python-au maillist - python-au at starship.python.net > http://starship.python.net/mailman/listinfo/python-au -- --Christopher Neugebauer Jabber: chrisjrn at gmail.com -- IRC: chrisjrn on irc.freenode.net -- AIM: chrisjrn157 -- MSN: chris at neugebauer.id.au -- WWW: http://chris.neugebauer.id.au -- Twitter/Identi.ca: @chrisjrn From gus at projectgus.com Wed Sep 18 01:22:13 2013 From: gus at projectgus.com (Angus Gratton) Date: Wed, 18 Sep 2013 09:22:13 +1000 Subject: [melbourne-pug] Call for coaches: OTS this Saturday - Intro to Programming Message-ID: <20130917232208.GB1450@ex2.chainxor.org> Hi Melbourne-Pug members, We're running another free "Introduction to Programming with Python" workshop this Saturday from noon. If you have a few hours spare then it'd be great if you could come along and help coach. http://www.meetup.com/OpenTechSchool-Melbourne/events/138303102/ (Don't need to RSVP on Meetup to coach, just drop me an email off-list.) Thanks everyone, Angus PS On a personal note I promise that I will finally make it to a Melbourne-PUG meetup soon! I always seem to be busy on Monday evenings, but enough is enough! From bianca.rachel.gibson at gmail.com Tue Sep 24 14:21:14 2013 From: bianca.rachel.gibson at gmail.com (Bianca Gibson) Date: Tue, 24 Sep 2013 22:21:14 +1000 Subject: [melbourne-pug] Fwd: [LCA2013-Chat] LCA2014 Registrations now open! In-Reply-To: <52291AAE.30003@opentechnologysolutions.com.au> References: <52291AAE.30003@opentechnologysolutions.com.au> Message-ID: ---------- Forwarded message ---------- From: Joshua Hesketh On behalf of the *linux.conf.au 2014* team we are pleased to announce that we have now started accepting early bird registrations. According to Luke John, organising director, ?The start of registration represents the culmination of a lot of groundwork in planning for the conference and it's a real milestone to be at this point in the process?, ?While there's still a lot to do, it's really starting to take shape now, and I'm quietly confident that we've got a great line up of speakers and topics and we are looking forward to an awesome conference?. Paul Del Fante also chipped in to offer encouragement for those of you who may feel a bit daunted by the distances. ?It's Perth, it's Summer, we've got a fantastic Linux conference on, warm beaches, balmy evenings, city life, so come on over and share in our hospitality?. The *linux.conf.au 2014* early bird registrations will be open till 2013/10/13, but are for a limited number of places and may close earlier before we move on to the formal registration period, and we'd please ask anyone who registers during this time to keep an eye out for any minor issues or inconsistencies you come across. The *linux.conf.au 2014* Organising Team. http://lca2014.linux.org.au #lca14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier at candeira.com Wed Sep 25 01:06:25 2013 From: javier at candeira.com (Javier Candeira) Date: Wed, 25 Sep 2013 09:06:25 +1000 Subject: [melbourne-pug] Next MPUG meeting: Devops and Bioinformatics on October 7, 6PM - Inspire 9, 41 Stewart St Message-ID: Dear Melbourne Pythonistas, Here's the current lineup for the October MPUG meeting: # Clare Slogget -- Python for Bioinformatics. # Lex Hider -- Salt: How to be truly lazy. We can still fit in a 5 minute short talk for this session, so please volunteer or dob in a friend! You can do it anonymously using our wiki: https://wiki.python.org/moin/MelbournePUG Also, a reminder that MPUG meetings are now BYO. But they don't have to be if someone volunteers to organize beer for everyone. See you in 12 days, Javier & the MPUG organists. From gcross at fastmail.fm Fri Sep 27 11:07:16 2013 From: gcross at fastmail.fm (Graeme Cross) Date: Fri, 27 Sep 2013 19:07:16 +1000 Subject: [melbourne-pug] Urgent: Submissions on Software Patents by 4 October References: <5244E227.3000305@stumbles.id.au> Message-ID: <1380272836.6296.27105005.23D1B8C3@webmail.messagingengine.com> Hi Pythoners, The Australian Government is requesting submissions for a Review of the Innovation Patent System. We all understand that software patents don't serve inventors, and now we have an opportunity to make a written submission to voice our concerns. Submissions close next Friday, the 4th October! The review has already show a genuine interest in our plight, so simply making a brief comment will help convince them to take the next step. Ben Sturmfels has prepared the following, no-nonsense guide to help you, and includes details around the submission process: http://www.sturm.com.au/resources/guide-innovation-patents.pdf I urge members of the Australian software industry to consider making a submission. Let's join New Zealand in becoming the next country to ban software patents. Regards, Graeme -------------- next part -------------- -- You have received this email because you're signed up to the Open Source Developers' Conference announce list. To unsubscribe, simply send a blank email to announce-leave at osdc.com.au. If you wish to temporarily disable email delivery without unsubscribing, or change any other membership information, head to the options page at https://securityprotected.net/lists/options/announce.osdc.com.au -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bianca.rachel.gibson at gmail.com Sat Sep 28 09:05:05 2013 From: bianca.rachel.gibson at gmail.com (Bianca Gibson) Date: Sat, 28 Sep 2013 17:05:05 +1000 Subject: [melbourne-pug] pythontex talk Message-ID: Hi all, Is there any interest in a talk about pythontex? It's a LaTeX package that allows running python code in the document and typesetting the results. It also provides syntax highlighting for python code in LaTeX documents. I think it's cool, but I don't think many others would be interested. Cheers, Bianca -------------- next part -------------- An HTML attachment was scrubbed... URL: From hartror at gmail.com Sat Sep 28 09:21:59 2013 From: hartror at gmail.com (Rory Hart) Date: Sat, 28 Sep 2013 17:21:59 +1000 Subject: [melbourne-pug] pythontex talk In-Reply-To: References: Message-ID: Lots of Science types in the python community so I would expect it would go down a treat. I am certainly interested myself. On 28 September 2013 17:05, Bianca Gibson wrote: > Hi all, > Is there any interest in a talk about pythontex? It's a LaTeX package that > allows running python code in the document and typesetting the results. > It also provides syntax highlighting for python code in LaTeX documents. > > I think it's cool, but I don't think many others would be interested. > > Cheers, > Bianca > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonslists at gmail.com Sat Sep 28 09:29:51 2013 From: noonslists at gmail.com (Noon Silk) Date: Sat, 28 Sep 2013 17:29:51 +1000 Subject: [melbourne-pug] pythontex talk In-Reply-To: References: Message-ID: I'd be interested; indeed, I gave a talk on something similar almost 2 years ago! https://mail.python.org/pipermail/melbourne-pug/2011-October/001045.html The one I talked about was quite limited in what it could do, though, so this pythontex sounds cool! On Sat, Sep 28, 2013 at 5:05 PM, Bianca Gibson < bianca.rachel.gibson at gmail.com> wrote: > Hi all, > Is there any interest in a talk about pythontex? It's a LaTeX package that > allows running python code in the document and typesetting the results. > It also provides syntax highlighting for python code in LaTeX documents. > > I think it's cool, but I don't think many others would be interested. > > Cheers, > Bianca > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > > -- Noon Silk Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/ "Every morning when I wake up, I experience an exquisite joy ? the joy of being this signature." -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier at candeira.com Sat Sep 28 10:32:54 2013 From: javier at candeira.com (Javier Candeira) Date: Sat, 28 Sep 2013 18:32:54 +1000 Subject: [melbourne-pug] pythontex talk In-Reply-To: References: Message-ID: It'd be awesome. We have two longish talks for October, so maybe for November or December? J On Sat, Sep 28, 2013 at 5:29 PM, Noon Silk wrote: > I'd be interested; indeed, I gave a talk on something similar almost 2 years > ago! > > https://mail.python.org/pipermail/melbourne-pug/2011-October/001045.html > > The one I talked about was quite limited in what it could do, though, so > this pythontex sounds cool! > > > > > On Sat, Sep 28, 2013 at 5:05 PM, Bianca Gibson > wrote: >> >> Hi all, >> Is there any interest in a talk about pythontex? It's a LaTeX package that >> allows running python code in the document and typesetting the results. >> It also provides syntax highlighting for python code in LaTeX documents. >> >> I think it's cool, but I don't think many others would be interested. >> >> Cheers, >> Bianca >> >> _______________________________________________ >> melbourne-pug mailing list >> melbourne-pug at python.org >> https://mail.python.org/mailman/listinfo/melbourne-pug >> > > > > -- > Noon Silk > > Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/ > > "Every morning when I wake up, I experience an exquisite joy ? the joy > of being this signature." > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > From bianca.rachel.gibson at gmail.com Sat Sep 28 13:08:12 2013 From: bianca.rachel.gibson at gmail.com (Bianca Gibson) Date: Sat, 28 Sep 2013 21:08:12 +1000 Subject: [melbourne-pug] pythontex talk In-Reply-To: References: Message-ID: I'm glad there's interest, I'll speak in December. Cheers, Bianca -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier at candeira.com Sun Sep 29 13:23:25 2013 From: javier at candeira.com (Javier Candeira) Date: Sun, 29 Sep 2013 21:23:25 +1000 Subject: [melbourne-pug] pythontex talk In-Reply-To: References: Message-ID: Thanks a lot, Bianca! J On Sat, Sep 28, 2013 at 9:08 PM, Bianca Gibson wrote: > I'm glad there's interest, I'll speak in December. > > Cheers, > Bianca > > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug > From cfp at ruxcon.org.au Tue Sep 24 11:35:38 2013 From: cfp at ruxcon.org.au (cfp at ruxcon.org.au) Date: Tue, 24 Sep 2013 19:35:38 +1000 (EST) Subject: [melbourne-pug] Ruxcon 2013 Security Conference Message-ID: <20130924093538.69A302F35D@ruxcon.com.au> Hi, Ruxcon is Australia's premier technical computer security conference, held at the CQ Function Centre in Melbourne. Ruxcon brings together the best and the brightest security talent in the Australia-Pacific region through live presentations, activities, and demonstrations. This year we also feature a fantastic line-up with several high-profile international speakers. Ruxcon 2013 will be held on the weekend of the 26th of October to the 27th of October. Doors open at 8:00am and the first presentation commences at 9:00am. There are a limited number of tickets available and they are going very quickly. Please register via the Ruxcon website to ensure that you don't miss out: http://www.ruxcon.org.au/register For more information, please visit http://www.ruxcon.org.au/speakers 1. BIOS Chronomancy - Jon Butterworth 2. Mining Mach Services within OS X Sandbox - Meder Kydryraliev 3. VoIP Wars: Return of the SIP - Fatih Ozavci 4. Inside Story Of Internet Banking: Reversing The Secrets Of Banking Malware - Sean Park 5. Top of the Pops: How to top the charts with zero melodic talent and a few friendly computers - Peter Fillmore 6. Deus Ex Concolica - Explorations in end-to-end automated binary exploitation - Mark Brand 7. The Art Of Facts - A look at Windows Host Based Forensic Investigation - Adam Daniel 8. AntiTraintDroid - Escaping Taint Analysis on Android for Fun and Profit - Golam 'Babil' Sarwar 9. Amateur Satellite Intelligence: Watching North Korea - David Jorm 10. Payment Applications Handle Lots of Money. No, Really: Lots of It - Mark Swift & Alberto Revelli 11. 50 Shades of Oddness - Inverting the Anti-Malware Paradigm - Peter Szabo 12. Assessing the Linux Desktop's Security - Ilja van Sprundel 13. .Net Havoc - Manipulating Properties of Dormant Server Side Web Controls - Shay Chen 14. Cracking and Analyzing Apple iCloud Protocols: iCloud Backups, Find My iPhone, Document Storage - Vladimir Katalov 15. Espionage: Everything Old is New Again - Kayne Naughton 16. Buried By Time, Dust and BeEF- Michele (Antisnatchor) 17. Under the Hood of Your Password Generator - Michael Samuel 18. Wireless Wickedness - Steve Glass & Matt Robert 19. BYOD PEAP Show: Mobile Devices Bare Auth - Josh Yavor 20. Top of the Pops: How to top the charts with zero melodic talent and a few friendly computers - Peter Fillmore 21. A Beginner's Journey Into Hardware Hacking - Silvio Cesare 22. Underground: The Julian Assange story (with Q&A session) - Suelette Dryfus & Ken Day 23. Introspy : Security Profiling for Blackbox iOS and Android - Alban Diquet & Marc Blanchou 24. 5 more presentations to be announced. Videos from previous Ruxon's can be found here: http://www.youtube.com/ruxcon Hope to see you there, Regards, Ruxcon 2013 Staff http://www.ruxcon.org.au From walker.ab at gmail.com Sat Sep 28 09:20:40 2013 From: walker.ab at gmail.com (Andrew Walker) Date: Sat, 28 Sep 2013 17:20:40 +1000 Subject: [melbourne-pug] pythontex talk In-Reply-To: References: Message-ID: <8A5DB511-789F-4C02-B45C-72A106B63172@gmail.com> Maybe I'm biased, but I'd love to hear this talk. It's always a struggle to get publication quality plots in a sensible amount of time, especially when you're seemingly fighting against pstricks, single- vs. multi-column layouts, not to mention the challenges of matplotlib tick and title labelling. From the questions asked over at the last few meetings I've been to, there's been a pretty strong interest from the academic & science communities lately, with lots of interest (and questions) about numpy / scipy / pandas / matplotlib. There are also at least three of the major universities represented (at least semi- regularly). Also, given that LaTeX is now one of the targets for nbconvert (the IPython notebook converter), this kind of tool is going to get even more important in the future. Andrew. On 28/09/2013, at 5:05 PM, Bianca Gibson wrote: > Hi all, > Is there any interest in a talk about pythontex? It's a LaTeX package that allows running python code in the document and typesetting the results. > It also provides syntax highlighting for python code in LaTeX documents. > > I think it's cool, but I don't think many others would be interested. > > Cheers, > Bianca > _______________________________________________ > melbourne-pug mailing list > melbourne-pug at python.org > https://mail.python.org/mailman/listinfo/melbourne-pug Dr Andrew Walker PhD BEng. (Hons) BApp. Sci. QS e-mail: walker.ab at gmail.com From rhydwyn.beta at gmail.com Mon Sep 30 02:45:59 2013 From: rhydwyn.beta at gmail.com (Rhydwyn beta) Date: Mon, 30 Sep 2013 10:45:59 +1000 Subject: [melbourne-pug] Fwd: [@OKFNau] HealthHack Melbourne In-Reply-To: References: Message-ID: In case anyone is interested: I wish I could be their. Hello lovely Melbourne friends! We've got an exciting event coming up at the end of October, a weekend long hackathon bringing together medical researchers and people with clever techy skills to tackle some real problems in health research. Example problems include: - I use multiple online data sets but I don't have a good way of knowing when I have looked at all the available information. I'd like an intuitive search panel that allows me to select exactly what I need, and report back all the relevant results - I generate vast quantities of data; I would like a visualisation panel that lets me quickly and easily compare multiple data sets against each other - I regularly search for information about disease occurrence; I'd like a tool that reports on aspects of previous research, e.g. statistical significance, number of patients, number Or you might just do an exploration of an interesting dataset without a fixed goal. So if you are great at data visualisation, data management or analytics (or have other great skills like data journalism and can coax the story out of a dataset) we'd love to see you there! You can find some more details here: http://au.okfn.org/2013/09/21/healthhack/, and register here: http://healthhackmelb.eventbrite.com. _______________________________________________ OKFN-AU mailing list OKFN-AU at lists.okfn.org http://lists.okfn.org/mailman/listinfo/okfn-au Unsubscribe: http://lists.okfn.org/mailman/options/okfn-au From noonslists at gmail.com Mon Sep 30 03:40:56 2013 From: noonslists at gmail.com (Noon Silk) Date: Mon, 30 Sep 2013 11:40:56 +1000 Subject: [melbourne-pug] pythontex talk In-Reply-To: <8A5DB511-789F-4C02-B45C-72A106B63172@gmail.com> References: <8A5DB511-789F-4C02-B45C-72A106B63172@gmail.com> Message-ID: On Sat, Sep 28, 2013 at 5:20 PM, Andrew Walker wrote: > Maybe I'm biased, but I'd love to hear this talk. > > It's always a struggle to get publication quality plots in a sensible > amount of time, especially when you're seemingly fighting against pstricks, > single- vs. multi-column layouts, not to mention the challenges of > matplotlib tick and title labelling. > > From the questions asked over at the last few meetings I've been to, > there's been a pretty strong interest from the academic & science > communities lately, with lots of interest (and questions) about numpy / > scipy / pandas / matplotlib. There are also at least three of the major > universities represented (at least semi- regularly). > > Also, given that LaTeX is now one of the targets for nbconvert (the > IPython notebook converter), this kind of tool is going to get even more > important in the future. > Along these lines, have you seen the stuff William Stein[1] at cloud.sagemath - https://cloud.sagemath.com/ - has been doing? I'm not generally into that kind of thing, but it is pretty cool! [1] https://plus.google.com/115360165819500279592/posts > Andrew. > -- Noon Silk Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/ "Every morning when I wake up, I experience an exquisite joy ? the joy of being this signature." -------------- next part -------------- An HTML attachment was scrubbed... URL: