Re: Clean Singleton Docstrings

On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote: > The difference between ints and floats can lead to bugs, too. Which > one should we eliminate? Eliminate both of them. Move to a single abstract numeric type* a la Scheme, with an "inexact" attribute (inexact numbers may or may not be represe

Re: Clean Singleton Docstrings

On Sat, Jul 16, 2016 at 4:53 PM, Random832 wrote: > On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote: >> The difference between ints and floats can lead to bugs, too. Which >> one should we eliminate? > > Eliminate both of them. Move to a single abstract numeric type* a la > Scheme, with an "i

Re: Clean Singleton Docstrings

Chris Angelico : > With a single abstract numeric type, what exactly does "inexact" mean, > where does it come from, and how does that affect the expected > behaviour and performance of numbers? Not much is said in the standard: Thus inexactness is a contagious property of a number. If two

Re: Clean Singleton Docstrings

On Sat, 16 Jul 2016 04:53 pm, Random832 wrote: > On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote: >> The difference between ints and floats can lead to bugs, too. Which >> one should we eliminate? > > Eliminate both of them. Move to a single abstract numeric type* a la > Scheme, with an "ine

Re: Operator Precedence/Boolean Logic

On Sat, 16 Jul 2016 03:58 pm, Rustom Mody wrote: > > From other thread: > > On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote: >> On 07/15/2016 09:04 PM, Rustom Mody wrote: >> >> > Just that suggesting that python's bool notion is straightforward is an >> > unnecessary lie –

EuroPython 2016: Recruiting Offers

Many of our sponsors are looking for new employees, so EuroPython 2016 is not only an exciting conference, but may very well also be your chance to find the perfect job you’ve always been looking for. Sponsor job board - We will post sponsor recruiting offers on the job board of

Re: Clean Singleton Docstrings

Oh, and a further thought... On Sat, 16 Jul 2016 04:53 pm, Random832 wrote: > Eliminate both of them. Move to a single abstract numeric type* a la > Scheme, with an "inexact" attribute (inexact numbers may or may not be > represented by a float, or by the same bigint/decimal/rational types as >

EPS Board Candidates for 2016/2017

At this year’s General Assembly we will vote in a new board of the EuroPython Society: http://www.europython-society.org/post/146998034935/invitation-to-the-europython-society-general This posting is also available as blog post: http://www.europython-society.org/post/147488545100/eps-board-candid

Re: Operator Precedence/Boolean Logic

On Sat, 16 Jul 2016 03:48 pm, Rustom Mody wrote: > On Thursday, June 30, 2016 at 10:52:50 PM UTC+5:30, Steven D'Aprano wrote: >> Okay, if you think that automata cannot be empty, I'll accept that. In >> that case, then I'll change my answer and say that __bool__ for automata >> should simply retur

Re: math.frexp

On Sat, 16 Jul 2016 06:24 am, Paul Rubin wrote: > Steven D'Aprano writes: >> But this can give some protection against overflow of intermediate >> values. > > Might be simplest to just add the logarithms. Look up Kahan summation > for how to do that while minimizing loss of precision. Simplest

EuroPython 2017 On-site Teams: Call for Interest (CFI)

The EuroPython Society (EPS) is happy to announce the Call for Interest (CFI) for EuroPython 2017: http://www.europython-society.org/post/147488978255/europython-2017-on-site-teams-call-for-interest The purpose of this call is to get to know teams willing to help organize the EuroPython conferenc

Re: Operator Precedence/Boolean Logic

On Sat, Jul 16, 2016 at 8:16 PM, Steven D'Aprano wrote: >> If both you and Chris tripped up on a right definition of an “empty” >> automaton and regex respectively, I believe it demonstrates that getting >> boolishness for an arbitrary type right is at least non-trivial. [FWIW My >> belief: In gen

Re: Operator Precedence/Boolean Logic

On Sat, 16 Jul 2016 08:46 pm, Chris Angelico wrote: > As Steven says, > the default is that they're all truthy, and onus is on the implementer > to demonstrate that this object is functionally equivalent to 0 or an > empty collection. (And it's possible for ANYONE to get that wrong - cf > timedelt

Re: Operator Precedence/Boolean Logic

Earlier you said: > > 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a > > graph..." > > I would make the empty graph (zero nodes) falsey, and non-empty graphs (one > or more nodes) truthy. > > > > 2. Automata which in a way are special kinds of graphs > > As above. No

Re: Operator Precedence/Boolean Logic

On Saturday, July 16, 2016 at 4:16:34 PM UTC+5:30, Chris Angelico wrote: > On Sat, Jul 16, 2016 at 8:16 PM, Steven D'Aprano wrote: > >> If both you and Chris tripped up on a right definition of an “empty” > >> automaton and regex respectively, I believe it demonstrates that getting > >> boolishnes

re: Operator Precedence/Boolean Logic

>Earlier you said: >* > 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a *>* > graph..." *> >* I would make the empty graph (zero nodes) falsey, and non-empty graphs (one *>* or more nodes) truthy. *> > >* > 2. Automata which in a way are special kinds of graphs *> >* As abo

Re: Operator Precedence/Boolean Logic

On Sat, Jul 16, 2016 at 9:02 PM, Steven D'Aprano wrote: > On Sat, 16 Jul 2016 08:46 pm, Chris Angelico wrote: > >> As Steven says, >> the default is that they're all truthy, and onus is on the implementer >> to demonstrate that this object is functionally equivalent to 0 or an >> empty collection.

Re: Operator Precedence/Boolean Logic

On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote: > You also have a bizarre notion that python's property: “Everything has > auto-bool-nature” IS STRAIGHTFORWARD. That's a very strong claim. You're not just pointing out that there may be a few old corner cases here and there where Python's treatm

Re: Operator Precedence/Boolean Logic

On Sat, 16 Jul 2016 10:15 pm, Rustom Mody wrote: > Earlier you said: > >> > 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a >> > graph..." >> >> I would make the empty graph (zero nodes) falsey, and non-empty graphs >> (one or more nodes) truthy. >> >> >> > 2. Automata w

Re: Operator Precedence/Boolean Logic

On 2016-07-16 17:27, Steven D'Aprano wrote: On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote: [snip] And yes, Rustom, I'm very familiar with the philosophical objections to the something/nothing distinction. "Is zero truly nothing, or is it some thing distinct from the absence of any number?" I

Re: Operator Precedence/Boolean Logic

On Sun, Jul 17, 2016 at 2:27 AM, Steven D'Aprano wrote: > If you really mean your words, and don't wish to step back and make a less > extreme claim, then you ought to be easily able to show that Python's use > of bools hardly ever works. It's clearly a terrible idea, almost every use > of it is a

Re: Clean Singleton Docstrings

On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote: > Will an "Exact" non-integer be stored as Decimal or > Fraction? How do you know? They have vastly different semantics, and > you should be able to choose. Er, the point is for them to _not_ have different semantics. A decimal storage format w

Re: Clean Singleton Docstrings

Random832 : > On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote: >> Will an "Exact" non-integer be stored as Decimal or >> Fraction? How do you know? They have vastly different semantics, and >> you should be able to choose. > > Er, the point is for them to _not_ have different semantics. A dec

Re: math.frexp

Steven D'Aprano writes: >>> protection against overflow of intermediate values. >> Might be simplest to just add the logarithms. > Simplest, but least accurate, even with Kahan summation or equivalent. Well the idea was to avoid overflow first, then hold on to whatever precision you have after th

Re: Clean Singleton Docstrings

On Sun, Jul 17, 2016 at 4:04 AM, Random832 wrote: > On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote: >> Will an "Exact" non-integer be stored as Decimal or >> Fraction? How do you know? They have vastly different semantics, and >> you should be able to choose. > > Er, the point is for them to

Re: Clean Singleton Docstrings

Chris Angelico : > In that case, an 'Exact' non-integer will have appalling performance - > fractions.Fraction doesn't really work all that nicely when the > numbers start getting huge. In Scheme, any math operation is allowed to drop exactness: If one of these procedures is unable to deliver

PEP Request: Advanced Data Structures

I have found it slightly frustrating that Python does not have built-in support for advanced data structures (Linked Lists, Stacks/Queues, BST) in its distribution. Many computer science students, developers, and software engineers rely on these data structures; having the data structures be a p

Re: Clean Singleton Docstrings

On Sun, Jul 17, 2016 at 7:27 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> In that case, an 'Exact' non-integer will have appalling performance - >> fractions.Fraction doesn't really work all that nicely when the >> numbers start getting huge. > > In Scheme, any math operation is allowed to dr

Re: PEP Request: Advanced Data Structures

On Sun, Jul 17, 2016 at 8:14 AM, wrote: > I have found it slightly frustrating that Python does not have built-in > support for advanced data structures (Linked Lists, Stacks/Queues, BST) in > its distribution. Many computer science students, developers, and software > engineers rely on these

Re: PEP Request: Advanced Data Structures

On Saturday, July 16, 2016 at 3:19:56 PM UTC-7, Chris Angelico wrote: > On Sun, Jul 17, 2016 at 8:14 AM, wrote: > > I have found it slightly frustrating that Python does not have built-in > > support for advanced data structures (Linked Lists, Stacks/Queues, BST) in > > its distribution. Many c

Re: PEP Request: Advanced Data Structures

On Sun, Jul 17, 2016 at 8:33 AM, Shrey Desai wrote: > Hi Chris, thanks for the reply. There's a couple of reasons why I would need > a Linked List (and other data structures): > - Education: the Linked List is a core data structure that CS undergraduates > (among others) use and study, so it is

Re: math.frexp

2016-07-15 13:39 GMT+02:00 Steven D'Aprano : > I'm experimenting with various implementations of product(values). Here's a > naive version that easily suffers from overflow: > > from functools import reduce > from operator import mul > > def product_naive(values): > return reduce(mul, values) >

Re: PEP Request: Advanced Data Structures

shrey.de...@gmail.com writes: > As a computer science undergraduate student, I don't want to spend > time writing the module but instead I want to work with it, play > around with it, and do problems with it. For educational purposes, I think writing the module yourself is part of the idea. Also,

Re: PEP Request: Advanced Data Structures

On Saturday, July 16, 2016 at 11:15:04 PM UTC+1, Shrey Desai wrote: > I have found it slightly frustrating that Python does not have built-in > support for advanced data structures (Linked Lists, Stacks/Queues, BST) in > its distribution. Many computer science students, developers, and software

Re: PEP Request: Advanced Data Structures

On 7/16/2016 6:14 PM, shrey.de...@gmail.com wrote: I have found it slightly frustrating that Python does not have built-in support for advanced data structures (Linked Lists, You and I have different ideas of 'advanced data structures' ;-). To me, linked list are limited structures used in fu

Re: PEP Request: Advanced Data Structures

On 2016-07-17 01:10, Terry Reedy wrote: On 7/16/2016 6:14 PM, shrey.de...@gmail.com wrote: I have found it slightly frustrating that Python does not have built-in support for advanced data structures (Linked Lists, You and I have different ideas of 'advanced data structures' ;-). To me, linke

Re: PEP Request: Advanced Data Structures

On 16Jul2016 19:49, Dennis Lee Bieber wrote: On Sat, 16 Jul 2016 15:33:12 -0700 (PDT), Shrey Desai declaimed the following: - Education: the Linked List is a core data structure that CS undergraduates (among others) use and study, so it is vital that they have hands on access to them. A list

Re: PEP Request: Advanced Data Structures

On Sun, Jul 17, 2016 at 10:54 AM, wrote: > Well, in a larger context you can keep a reference to an element deep in the > list, and insert a new element in O(1) time at that point. > I'd like to know how many elements your list needs before that actually becomes faster than CPython's heavily-opt

Passing File Descriptors To Subprocesses

A few years ago I wrote a tool to do comparisons between different versions of the Android API. Then one day, after a Python update (from the dates, it had to have been some version of 3.2), it stopped working. It took quite a while--over a year--until I figured

Re: PEP Request: Advanced Data Structures

Chris Angelico writes: >> keep a reference to an element deep in the list, and insert a new >> element in O(1) time at that point. > at the C level, wouldn't tracing the links cost massively more than > the occasional insertion too? I'm not sure O(1) is of value at any > size, if the costs of all

Re: PEP Request: Advanced Data Structures

On Sun, Jul 17, 2016 at 12:33 PM, Paul Rubin wrote: > Chris Angelico writes: >>> keep a reference to an element deep in the list, and insert a new >>> element in O(1) time at that point. >> at the C level, wouldn't tracing the links cost massively more than >> the occasional insertion too? I'm no

Re: PEP Request: Advanced Data Structures

On 2016-07-17 03:33, Paul Rubin wrote: Chris Angelico writes: keep a reference to an element deep in the list, and insert a new element in O(1) time at that point. at the C level, wouldn't tracing the links cost massively more than the occasional insertion too? I'm not sure O(1) is of value at

Re: Passing File Descriptors To Subprocesses

On Sun, Jul 17, 2016 at 1:59 AM, Lawrence D’Oliveiro wrote: > The various subprocess functions > have > arguments called “close_fds” and “pass_fds”, which specify which file > descriptors are to be > left open in the child process. Yet no matte

Re: Operator Precedence/Boolean Logic

Heh! A flurry of opinions! No time right now… other than to say thank you (MRAB) for this little gem: On Saturday, July 16, 2016 at 10:29:02 PM UTC+5:30, MRAB wrote: > On 2016-07-16 17:27, Steven D'Aprano wrote: > > On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote: > [snip] > > > And yes, Rustom,

Re: PEP Request: Advanced Data Structures

On 17Jul2016 12:43, Chris Angelico wrote: On Sun, Jul 17, 2016 at 12:33 PM, Paul Rubin wrote: Chris Angelico writes: keep a reference to an element deep in the list, and insert a new element in O(1) time at that point. at the C level, wouldn't tracing the links cost massively more than the

Re: PEP Request: Advanced Data Structures

On Sun, Jul 17, 2016 at 1:27 PM, wrote: >> Right, but how did you *get* that deep into the list? By following a >> chain of pointers. That's a relatively costly operation, so the >> benefit of not having to move all the following elements is damaged >> some by the cost of chasing pointers to get

Re: Operator Precedence/Boolean Logic

On Sun, Jul 17, 2016 at 1:43 PM, Rustom Mody wrote: > Heh! A flurry of opinions! > No time right now… other than to say thank you (MRAB) for this little gem: > > On Saturday, July 16, 2016 at 10:29:02 PM UTC+5:30, MRAB wrote: >> On 2016-07-16 17:27, Steven D'Aprano wrote: >> > On Sat, 16 Jul 2016

Re: PEP Request: Advanced Data Structures

On Sun, 17 Jul 2016 08:14 am, shrey.de...@gmail.com wrote: > I have found it slightly frustrating that Python does not have built-in > support for advanced data structures (Linked Lists, Stacks/Queues, BST) in > its distribution. They are hardly "advanced" data structures. They are trivial data s

Re: PEP Request: Advanced Data Structures

On 2016-07-17 08:19, Chris Angelico wrote: > Why do you need a linked list? That's an implementation detail; why > not simply use a regular list? > > Not trolling, genuinely asking. Is there something that you > specifically need those exact structures for? I know there have been times I want kno

Re: Operator Precedence/Boolean Logic

On Sunday, July 17, 2016 at 9:35:57 AM UTC+5:30, Chris Angelico wrote: > On Sun, Jul 17, 2016 at 1:43 PM, Rustom Mody wrote: > > Heh! A flurry of opinions! > > No time right now… other than to say thank you (MRAB) for this little gem: > > > > On Saturday, July 16, 2016 at 10:29:02 PM UTC+5:30, MRA