From greg.ewing at canterbury.ac.nz Sat Mar 1 00:34:05 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 01 Mar 2014 12:34:05 +1300 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: Message-ID: <53111CED.2050801@canterbury.ac.nz> Chris Angelico wrote: > With this proposal, your > star_lambda function's declaration changes the call site - instead of > evaluating a*b+c, it has to construct an anonymous function and pass > it along. And when you consider that this could happen with any argument to any function, depending on what the function turns out to be like at run time, it means that *all* function arguments would need to be passes as anonymous functions. That would be very awkward an inefficient. -- Greg From ron3200 at gmail.com Sat Mar 1 03:13:50 2014 From: ron3200 at gmail.com (Ron Adam) Date: Fri, 28 Feb 2014 20:13:50 -0600 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: Message-ID: On 02/28/2014 04:33 PM, Nick Coghlan wrote: > On 1 Mar 2014 05:43, "Ron Adam" > > wrote: > > > > > > > > On 02/28/2014 11:54 AM, Chris Angelico wrote: > >> > >> On Sat, Mar 1, 2014 at 4:17 AM, Ron > Adam > wrote: > >>> > >>> >This returns a lambda-like function. > >>> > > >>> > def star_lambda(***expr): return expr > >>> > > >>> > > >>> >And is used this way... > >>> > > >>> > result = star_lambda(a * b + c) # captures expression. > >>> > > >>> > actual_result = ***result # *** resolves "result" here! > >>> > > >> > >> Interesting, but I don't like the way the interpretation of a function > >> call depends on the target function. With both * and ** notations, > >> there's absolutely no difference: the function is called with these > >> positional and those keyword arguments, whether they came from actual > >> args or from * or ** unpack/repacks;and there's no difference between > > > > > a function that collects args with *args,**kwargs and one that > > > collects them with individual names (or a C-level function that might > > > do something altogether different). > > > > > > It's not clear what differences you mean here... can you show some examples? > > Remember that at compile time, Python has *no idea* what the actual > signature of the target function is. Thus, all Python function calls use > the following sequence (ignoring optimisations of special cases): > > 1. At the call site, the arguments are collected into a tuple of positional > arguments and a dict of keyword arguments. > 2. The interpreter hands that tuple and dict over to the target callable > 3. The *target callable* then maps the supplied arguments to the defined > parameters including filling in any default values. > > Any function related proposals need to account for the fact that from the > compiler's point of view *every* function signature looks like "(*args, > **kwds)" (although it may have optimised paths for the no-args case and the > positional-args-only case), and that the target callable may not even be > written in Python. So functions can't be extended to take a triplet instead of a pair... (*args, **kwds, ***expr) Looking up... I think this is what you're referring to in ceval.c. #------------------- /* External interface to call any callable object. The arg must be a tuple or NULL. The kw must be a dict or NULL. */ PyObject * PyEval_CallObjectWithKeywords(PyObject *func, PyObject *arg, PyObject *kw) { #-------------------- And it wouldn't work in the normal case any way, as expressions are evaluated as they are put on the stack before calling the function. Somehow I was thinking this morning the code inside the function call parentheses f(...), could be parsed later than it actually is. And in the context of the function definition, possibly similar to how a comprehension is evaluated. But it would take some pretty big changes to do that I supose. Cheers, Ron From rosuav at gmail.com Sat Mar 1 03:14:52 2014 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 1 Mar 2014 13:14:52 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: Message-ID: On Sat, Mar 1, 2014 at 6:42 AM, Ron Adam wrote: > It's not clear what differences you mean here... can you show some examples? These are exactly the same: x = (1,2) f(*x) f(1,2) I played with dis.dis() and it seems there are special-case opcodes for calling a function with a variable number of arguments and/or with variable keyword args; but once it arrives at the other side, the two are identical: >>> def f(*args): print(args) >>> f(1,2) (1, 2) >>> x=(1,2) >>> f(*x) (1, 2) The runtime fetches some callable, gives it some args, and says "Go do your stuff!". It doesn't care what that callable is - it could be a classic function defined with 'def' or 'lambda', it could be a type, it could be an object with __call__, it could be a built-in that's backed by a C function, anything. All that ends up arriving on the other side is: You have these positional args and these keyword args. Adding the tri-star to the mix suddenly changes that. A function is now capable of taking an expression, rather than an object. That's completely different, and it depends on the called function to distinguish one from the other. ChrisA From rosuav at gmail.com Sat Mar 1 03:17:10 2014 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 1 Mar 2014 13:17:10 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: Message-ID: On Sat, Mar 1, 2014 at 1:13 PM, Ron Adam wrote: > Somehow I was thinking this morning the code inside the function call > parentheses f(...), could be parsed later than it actually is. And in the > context of the function definition, possibly similar to how a comprehension > is evaluated. But it would take The best way to do it would be to adorn the call site. We can currently do that with lambda: f(a * b + c) f(lambda: a * b + c) Those are completely different from each other, but completely consistent with themselves - it doesn't matter what f is, one of them passes the sum of the product and the other passes a callable. ChrisA From ian.team.python at gmail.com Sat Mar 1 04:09:02 2014 From: ian.team.python at gmail.com (ian o) Date: Fri, 28 Feb 2014 19:09:02 -0800 (PST) Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: > > And we don't actually mind all that much if applications don't migrate > in the near term - Python 2 will have commercial support available > well past 2020. (The developers of *those applications* might mind, > though, just as anyone maintaining Python 2.4 compatibility for the > benefit of RHEL/CentOS 5 typically isn't happy about it) > > > Your response is most dissapointing, and I would hope does not represent the community overall. We have 3 teams working server systems currently with python as the implementation model. All work is currently in python 2.x and with a solution to this the work could immediately move to 3.x. However, you state that our situation, and that of the other 60% of python programmers as at end January 2014 who are constrained from using python 3 by python 2 dependencies: "we don't mind about those developers" And of course the dependent library module developers will not update the library, because 'no one out there uses python 3.x'. And from your perspective this is simply not of any interest. No wonder Tiobe index shows python dropping and in the words of those trying to persuade me to move the projects to another language 'python 3.x' came out 5 years ago and we still cannot move to it, this is going no where. I would like to still have the developers work in python, and to do that there needs to be a path to python 3. I also would prefer to be in python 3 anyway. But even if a workable solution is there, your answer is who cares about 60% of developers anyway! -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sat Mar 1 04:46:11 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 1 Mar 2014 14:46:11 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: Message-ID: <20140301034611.GD28804@ando> On Fri, Feb 28, 2014 at 11:17:18AM -0600, Ron Adam wrote: > > Starting new thread because this bike has a different shape and color. > > Yesterday I was thinking that just making the keyword lambda assignable > like True, False, and None, would be enough. You can't assign to True, False or None. (You can assign to True and False in Python 2, but shouldn't.) [...] > This morning I thought we could have in a functions definition something, > like "*", and "**", to take an expression. Similar to Nicks idea with =:, > but more general. > > The idea is to have "***" used in def mean to take "any" call expression > and not evaluate it until *** is used on it. [...] > A function call that captures an expression may be tricky to do. Here's one > approach that requires sugar when a function defined with "***" is called. I think it would be useful to have a way to delay execution of an expression, that is to say, have a way to capture an expression for later evaluation, something more lightweight than a function, but I don't think that limiting it to inside function calls is the right approach. Something perhaps like a thunk might be appropriate? We can *almost* do that now, since Python has a compile function: thunk = compile("x + 3", "", "eval") # much later eval(thunk) Some problems with that approach: - You have to write the expression as a string, which means you lose any possibility of syntax highlighting. - The temptation is to pass some arbitrary untrusted string, which leads to serious security implications. The argument here should be limited to an actual expression, not a string containing an expression which might have come from who knows where. - It should be as lightweight as possible. The actual compilation of the expression should occur at compile-time, not run-time. That implies some sort of syntax for making thunks, rather than a function call. - Likewise actually evaluating the thunk should be really lightweight, which may rule out a function call to eval. - How should scoping work? I can see use-cases for flat scoping, static scoping, dynamic scoping, and the ability to optionally provide custom globals and locals, but I have no idea how practical any of them would be or what syntax they should use. All of this is pie-in-the-sky at the moment, and not a serious proposal for Python 3.5. -- Steven From ncoghlan at gmail.com Sat Mar 1 04:57:42 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 1 Mar 2014 13:57:42 +1000 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: On 1 March 2014 13:09, ian o wrote: >> And we don't actually mind all that much if applications don't migrate >> in the near term - Python 2 will have commercial support available >> well past 2020. (The developers of *those applications* might mind, >> though, just as anyone maintaining Python 2.4 compatibility for the >> benefit of RHEL/CentOS 5 typically isn't happy about it) >> > Your response is most dissapointing, and I would hope does not represent the > community overall. My apologies, I wrote my post assuming you had already read http://docs.python.org/dev/howto/pyporting.html and decided that the existing approaches described there weren't sufficient for your purposes. Those cases where the recommended migration process isn't considered acceptable for some reason (usually non-technical ones) are the cases that I consider to fall into the "it's OK to just keep using Python 2" category. However, I just realised two things: * that version of the guide is currently only in the Python 3.4 docs, and so the page at http://docs.python.org/3/howto/pyporting.html is still displaying the older 3.3 version of the guide (the page in the Python 2.7 docs is similarly outdated). * that guide is currently aimed primarily at library and framework authors, and doesn't explicitly discuss the migration of integrated applications. I have now filed http://bugs.python.org/issue20812 and http://bugs.python.org/issue20813 to address those limitations, but in the meantime, I will provide the missing information here: For developers of integrated applications that currently still have some dependencies on Python 2, the preferred migration path is to use tools like python-modernize or python-future to shift first into the large common subset of Python 2 and Python 3, and then only later switch fully to Python 3. This approach permits application developers to take the following path: 1. Python 2 only (status quo) 2. Python 2/3 compatible on Python 2 (waiting for dependencies) 3. Python 2/3 compatible on Python 3 (dependencies ported or replaced) 4. Python 3 only (drop Python 2 support) Brett Cannon's "caniusepython3" tool (https://pypi.python.org/pypi/caniusepython3/) is designed to automate the dependency analysis to see if all declared dependencies are Python 3 compatible (or have suitable alternatives available). However, if you're using system packages for dependency management, some data transformations will be needed to convert them to a form that the tool understands. My original reply assumed that you were already aware of the details of this preferred approach before posting your proposal, and I now realise that assumption was likely incorrect. Once again, my apologies. Regards, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From abarnert at yahoo.com Sat Mar 1 04:58:08 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Fri, 28 Feb 2014 19:58:08 -0800 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: Message-ID: On Feb 28, 2014, at 18:13, Ron Adam wrote: > So functions can't be extended to take a triplet instead of a pair... > > (*args, **kwds, ***expr) The more you elaborate this, the more this looks like Ruby procs: You get any number of normal arguments, then at most one special kind of callback thing which must come at the end. I'm not sure which use cases this solves. It doesn't work for expressions that need an argument, like a sorting key function. It also doesn't work for pre-existing functions that weren't designed to take ***expr, like Button or takewhile. And wrapping the expression in a call to a forwarding function doesn't seem any less verbose or more readable than just using lambda. Anyway, there are two fundamental problems with anything that doesn't require any syntax at the call site. First, it's not obvious, or even easily discoverable, to the reader when you're passing a quoted expression and when you're passing a value. Second, it's not discoverable to the compiler. Going back to the analogies from other languages again, Lisp gets around this by making functions and macros different things. Among other differences, a macro always gets expressions instead of values, without any need to quote them at the call site. And, as Haoyi Li has pointed our multiple times on the other threads, you can already do the same thing in Python (with MacroPy). From ron3200 at gmail.com Sat Mar 1 05:07:27 2014 From: ron3200 at gmail.com (Ron Adam) Date: Fri, 28 Feb 2014 22:07:27 -0600 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: Message-ID: On 02/28/2014 08:14 PM, Chris Angelico wrote: > On Sat, Mar 1, 2014 at 6:42 AM, Ron Adam wrote: >> It's not clear what differences you mean here... can you show some examples? > > These are exactly the same: > > x = (1,2) > f(*x) > > f(1,2) > > I played with dis.dis() and it seems there are special-case opcodes > for calling a function with a variable number of arguments and/or with > variable keyword args; but once it arrives at the other side, the two > are identical: > >>>> def f(*args): > print(args) >>>> f(1,2) > (1, 2) >>>> x=(1,2) >>>> f(*x) > (1, 2) > > The runtime fetches some callable, gives it some args, and says "Go do > your stuff!". It doesn't care what that callable is - it could be a > classic function defined with 'def' or 'lambda', it could be a type, > it could be an object with __call__, it could be a built-in that's > backed by a C function, anything. All that ends up arriving on the > other side is: You have these positional args and these keyword args. > > Adding the tri-star to the mix suddenly changes that. A function is > now capable of taking an expression, rather than an object. That's > completely different, and it depends on the called function to > distinguish one from the other. Right.. To make it work in the way I was thinking would require each function consisting of two parts. One part to build a name-space, and the other for executing the code. Then at call time, the first part could evaluate the expressions inside the function parentheses. This part would be new, and possibly work like a dict comprehension, except more specific to call signatures. Then the constructed name space would be passed directly to the code part for the actual call. Which would be quite different than what happens presently. I've refactored dis once for fun, and also played around with ceval enough to know how this stuff works, but when I haven't looked at the code recently, (like now) I tend to think more in abstract terms which helps with creativity and seeing new ways to do things. (And it is why I like reading this list), But I sometimes misses on the objectivity side... [Note to self... look at the code more.] It comes down to this... "Creativity and Objectivity often don't want to occupy the same space at the same time." also helped test some patches to dis as well. And Cheers, Ron From steve at pearwood.info Sat Mar 1 05:07:40 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 1 Mar 2014 15:07:40 +1100 Subject: [Python-ideas] A python bridge between versions In-Reply-To: <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: <20140301040740.GF28804@ando> On Thu, Feb 27, 2014 at 10:03:42PM -0800, ian o wrote: > Chris, great reply. > > Yes it is not easy. Especially if you wish to make use of python2 modules > painless. > > And I agree wholeheartedly that serious thought is needed on the 'could it > work so well that it actually slow the migration of library modules?'. I think that such a bridge will slow the migration of library modules, since it reduces the need to migrate. As a library author, why should I spend tens or hundreds of hours migrating my library to Python 3 when I can spend 10 minutes adding a note to the library's website telling people to use the bridge? The problem with this suggestion is that it does nothing to encourage library authors to migrate to 3, it simply enables them to delay migrating even longer, possibly for so long that they lose interest altogether. That's library authors. How about the developers who use those libraries? Right now, there is some motivation for people to move to 3: cool new features, and getting cooler by the year. With this suggested bridge, they can migrate to 3 while still remaining dependent on 2. This might seem like a win if you only focus on the short term uptake of 3, but it misses the fact that they're still dependent on 2. They've now *trebled* the number of language dependencies, from Python only to two versions of Python plus the bridge software. Having spent the time and effort to migrate to 3, in a few years they'll have to go through the same pain again to get rid of the dependency on 2 and the bridge. Nobody will want to do that. The pressure on the core developers to keep supporting 2 forever will increase, not decrease. > This is an important debate to have. I suggest if the answer to 'can a > specification be created that will significantly accelerate migration?', > then it is worth the effort to deliver this. I think you are making a classic mistake of technically-minded people: looking for a technical solution to a social problem. The problem with Python 3 uptake is not a technical problem, or at least not *only* a technical problem. It is mostly a social problem: the costs of migrating are greater than the benefits. Python 3 is great, but for most people Python 2 does the job. Another social problem is that the minority of library authors who haven't migrated haven't done so because they personally don't care about Python 3, or they don't have the time or money to spend on it. Adding a bridge doesn't suddenly give them more time or money. For application developers, the social problem is less because of a few libraries and more to do with the supported standard Python on their system. That will change once Linux distros start providing 3 as their standard system Python; out of the big distros, Fedora is about to do so, so things will start changing soon. But perhaps the biggest reason for slow uptake of Python 3 with existing projects is that nobody wants to spend money just to migrate to 3 for the sake of migrating to 3. "Written in Python 3" is not a selling point. Even the availability of security updates is not much of a selling point, although it will become more important when Python 2.7 is end-of-lifed. The reality is that many apps work perfectly well now using Python 2.7, or 2.6, or even 2.4, and they'll continue to work well in five or ten years so there's no real need to update. At the last US PyCon, there was even one fellow still using Python 1.5. It works, he didn't need security updates, so why migrate? *This is not a problem to be solved.* It's okay for people to stick with an old version of Python. There's no rule that says Python has failed if some developers stick to old versions. > As things stand, the popularity of Python has dropped by most measures > since the release of Python 3. Improve the language and lose market share? > I suggest that is all about the pain of the transition. That sounds remarkably like FUD to me. Where is your evidence that the popularity of Python has fallen? Personally, I think all the "language popularity" measures are dubious, or at least need to be treated with considerable skepticism. Take this one: http://langpop.com/ which lists BrainF--- in the 40 most popular languages. Sure it is. The PyPL popularity index here: https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY-of-Programming-Language shows Python as increasing in popularity. In contrast, TIOBE shows Python as losing popularity -- but so did Java, PHP, C++ and Ruby, and none of them have a major version change. (TIOBE also shows that despite a large number, possibly majority, of VB 6 developers boycotting VB.Net, VB.Net has just entered the top 10 most popular languages.) And then there's CodeEval, which for the third year in a row has found that Python is more popular than Java, C++, C, PHP and Javascript. In fact more popular than Java, C and PHP *together*. http://blog.codeeval.com/codeevalblog/2014 Bless their little white socks, but methinks their methodology is perhaps a tad flawed. I think it is interesting to compare and contrast these different ways of measuring popularity, but then I'm a statistics wonk and I find even flawed statistics interesting. Remember that there is no one true definition of popularity, even if there were there is no accurate way of measuring it, and all of the sites that claim to do so are actually measuring subtley different things. Most importantly, chasing popularity for its own sake is a waste of time. What makes Python Python is not just the syntax and std lib, but also the culture -- we're neither the stultifying corporate culture of "Java shops", nor the wild-west anything goes of cowboy PHP developers, but something unique. (As are other languages, of course. Perl culture is not Haskell culture is not Erlang culture.) In part, people take up languages because they like the culture. Python will never attract the corporate suits who like the Java philosophy, nor will it attract the cowbody web developers who like the PHP way of doing things. Should we try to ape PHP or Java to attract the cowboys or suits? Or should we continue to make Python the best language that *we* like, regardless of what other people prefer? Untimately, apart from winning pissing contests on Slashdot and Reddit, what does it matter if Python is third most popular or ninth most popular? Its not a popularity context where the winner takes all. According to TIOBE, the most popular language, C, has less than 20% share. If you think Python is a failure because it is in position 8, what does that make Javascript in position 9? > You do not have to search hard to find comments to the effect 'nobody is > using python3'. Or 'even if you use python 3, do not use the new features > since you need to ensure code is compatible with both versions'. You don't have to search very hard to find comments that Elvis was kidnapped by aliens. https://duckduckgo.com/html/?q=elvis+kidnapped+by+aliens A belief which has rather more going for it than either of the two comments you list above, since there's a miniscule, microscopic chance that perhaps Elvis *was* kidnapped by aliens, whereas I know for a fact beyond any doubt that some people are using Python 3 and using the new features. -- Steven From ian.team.python at gmail.com Sat Mar 1 05:10:04 2014 From: ian.team.python at gmail.com (ian o) Date: Fri, 28 Feb 2014 20:10:04 -0800 (PST) Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: > And we don't actually mind all that much if applications don't migrate > in the near term - Python 2 will have commercial support available > well past 2020. (The developers of *those applications* might mind, > though, > ..... > The group we *do* really care about supporting is authors of existing > Python *libraries*, and "2in3" and "3in2" approaches don't really help > them at all, since library and framework authors with users on both > Python 2 and Python 3 will likely face demand to support both versions > natively anyway. Cheers, > Nick. > > Nic, > Lets assume for the moment that the 'we don't really care about the 60% of python developers blocked from moving to python 3 by depencies' was not really what you meant. I am going to assume that what you really meant was 'I do not think helping these people directly is the best solution'. And this attitude is based around the fear that if the developers can move to python 3 before the libraries all support python 3, then that will remove pressure from the libraries to support python 3. This fear i can understand. But I suggest some real world experience shows this approach is actually not assisting either group. It is certainly not assisting the developers wishing to move to python 3, but it is also making life hard for the "people we do really care about" So not supporting a "2in3" solution forces programmers to with python2 dependencies to hold off moving to python3 until their dependencies migrate, but hopefully with sound motives. Now take a typical dependency. Web2py. Speak to them on migration and they will telly you 'none of our users have moved to python 3'. So the users are held back from moving by the dependencies, and the dependencies are held back by the users. I would suggest that making it easier to support both python2 and ptyhon3 from a library is simply reducing what it a painful thing. I would suggest that allowing all the end users to migrate to python3 as soon as possible is a far more attractive solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Sat Mar 1 06:09:03 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Fri, 28 Feb 2014 21:09:03 -0800 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: On Feb 28, 2014, at 19:09, ian o wrote: > However, you state that our situation, and that of the other 60% of python programmers as at end January 2014 who are constrained from using python 3 by python 2 dependencies: "we don't mind about those developers" You're twisting the numbers. I'm part of the 60% who have to work on Python 2.x for at least one project. But first, I have others--including shipping commercial code both on the desktop and the server--using 3.x. And second, in all but one case, the 2.x apps are 2.x not because of lacking library support, but because we have an already-working and -deployed app that's effectively in maintenance mode, and it's not worth the effort or risk to port it to 3.x. (In other words, most of my 2.x work points to the _success_ of the migration plan, not a failure.) And you're also twisting Nick's words. He said that he cares more about getting library developers to 3.x than application developers. And he explained why that makes life better for application developers. To take that as "the Python devs don't care about application developers" is willfully misinterpreting the point. > And of course the dependent library module developers will not update the library, because 'no one out there uses python 3.x'. None of the library devs I've ever dealt with has ever said that (well, not since the early 3.1 days). Most projects that don't support 3.x today want to do so, it just isn't always the very highest thing on their priority list. Three times I've had to port a library myself rather than waiting around--but in every case, the library's dev was happy to take my code, even if it meant losing 2.5 support, reviewing large changelists, etc. I'm sure there are some exceptions, but it's certainly not the ubiquitous case you're presenting. There's a reason the Python 3 Wall of Shame changed it's name to Wall of Superpowers and the competing py3ksupport page stopped updating: because people have been porting important libraries to 3.x, and continue to do so. > No wonder Tiobe index shows python dropping And is the Python 3 migration also to blame for Python's direct competitors (Ruby, Perl, and PHP) also dropping)? Or for the general trend in Tiobe numbers to show ObjC and Windows-specific languages continually gaining on cross-platform languages? > and in the words of those trying to persuade me to move the projects to another language 'python 3.x' came out 5 years ago and we still cannot move to it, this is going no where. This is pure FUD. And I don't see how repeating that FUD to the Python devs is going to help you. If you want to convince these people to stay on Python, you need to start talking specifics instead of talking points. What libraries are stopping you from moving to 3.x? Does Ruby or Node.js or whatever actually have a better alternative for all of those libraries than Python 3 does? Would it really be easier to write those missing libraries yourself in a new language than to port existing Python 2.x libraries to 3.x? For that matter, have you actually checked whether those libraries really are blocking you? I've lost count of the number of people who've claimed they can't switch to Python 3 because of some library that's been ported since 2010 or that has a 3.x-compatible drop-in replacement. From ian.team.python at gmail.com Sat Mar 1 06:53:13 2014 From: ian.team.python at gmail.com (ian o) Date: Fri, 28 Feb 2014 21:53:13 -0800 (PST) Subject: [Python-ideas] A python bridge between versions In-Reply-To: <20140301040740.GF28804@ando> References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> Message-ID: Steven, Great post. Arguments can be enjoyed when people with differing views argue them well. Let me try and put the counter case as well. I have to start with the Elvis abducted by aliens just because it is such a great place to start. I enjoyed your point. But let me counter by saying that the information that some people say 'Elvis was abducted by aliens' does not mean this is what actually happened, but it does tell us that some people believe this! And there is rather surprising information in the fact that 'some people believe Elvis was abducted by Aliens'. Similarly I do not believe 'no-one is using python 3'. I program in python3 (and wish i could for all programming). But it is still interesting that people are saying it. Other comments inline below: I think that such a bridge will slow the migration of library modules, > since it reduces the need to migrate. As a library author, why should I > spend tens or hundreds of hours migrating my library to Python 3 when I > can spend 10 minutes adding a note to the library's website telling > people to use the bridge? > > The problem with this suggestion is that it does nothing to encourage > library authors to migrate to 3, it simply enables them to delay > migrating even longer, possibly for so long that they lose interest > altogether. > > I suggest the counter point here is to consider life a library developer. Which motivates you: that fact that people using your library all program in python3, or hearing that all your users program in python2? > That's library authors. How about the developers who use those > libraries? > > Right now, there is some motivation for people to move to 3: cool new > features, and getting cooler by the year. With this suggested bridge, > they can migrate to 3 while still remaining dependent on 2. This might > seem like a win if you only focus on the short term uptake of 3, but it > misses the fact that they're still dependent on 2. They've now *trebled* > the number of language dependencies, from Python only to two versions of > Python plus the bridge software. > > Are you assuming that it will always be either a) all dependencies require python2 or b) all dependencies are available in python 3. Rather than c) some dependencies are available in python3 but the python3 version cannot be used because I am being held back to python2 by some other critical dependencies. For the projects i work on, it is c). It is not like there has been no success getting packages to migrate. The problem is that an entire project is held back by one single dependency. And for us we would wear some pain right now and make that move. Most of the project doesn't have tow steps and can be moved immediately. If a bridge is offered, it would not be a great idea to force everyone to use it. If EVERY imported module is still in python2 then I suggest it is too early to move. Demonstrably, some people like the idea, and I suggest it would be interesting to discover how many. There may be cases where it is not the right choice because too many dependencies are only available in python3 , but alone that does not mean the choice should not be offered. Personally I beleive that now many dependencies can be found in python3, hence the frustration of having to wait until every single one moves seems unfortunate. Having spent the time and effort to migrate to 3, in a few years they'll > have to go through the same pain again to get rid of the dependency on 2 > and the bridge. Nobody will want to do that. The pressure on the core > developers to keep supporting 2 forever will increase, not decrease. > > I cannot see that getting rid of the bridge would be that difficult, particularly if it is not for many modules. The real pain is living in world where there is so much holding everything back to the older version. Again, let me declare the self interest here. We have development teams and projects we wish to move to python3. A bridge like this would allow us to move now, and that would allow pressure on the module providers. Stopping a step like this on the basis it stops people like us moving to python3 just seems counter productive if the goal is to move to python3. > > > This is an important debate to have. I suggest if the answer to 'can a > > specification be created that will significantly accelerate migration?', > > then it is worth the effort to deliver this. > > I think you are making a classic mistake of technically-minded people: > looking for a technical solution to a social problem. > > The problem with Python 3 uptake is not a technical problem, or at least > not *only* a technical problem. It is mostly a social problem: the costs > of migrating are greater than the benefits. Python 3 is great, but for > most people Python 2 does the job. > > I am a person experiencing the problem. And our experience is that our core developers use code supplied by a third party who does not produce a python3 version. So the core has to be done in python2. The code produced by these core developers is then supplied to other companies - forcing them to stay in python2. It is dependency hell. One module anywhere down the chain that cannot be moved and the whole project is forced to stay python2. > Another social problem is that the minority of library authors who > haven't migrated haven't done so because they personally don't care > about Python 3, or they don't have the time or money to spend on it. > Adding a bridge doesn't suddenly give them more time or money. > Agreed. But in the real world, an example of a major dependency requiring python2, web2py, states they will be motivated to python3 when the users of their framework move. But this policy of forcing all dependencies to move before the end users move means this will never happen. What it does mean is many of their customers can move. And it is even possible for them to ask their holdout customers to either stay with the old version or move, since these customers are no longer held back by other dependencies. For application developers, the social problem is less because of a few > libraries and more to do with the supported standard Python on their > system. That will change once Linux distros start providing 3 as their > standard system Python; out of the big distros, Fedora is about to do > so, so things will start changing soon. > > But perhaps the biggest reason for slow uptake of Python 3 with existing > projects is that nobody wants to spend money just to migrate to 3 for > the sake of migrating to 3. "Written in Python 3" is not a selling > point. Even the availability of security updates is not much of a > selling point, although it will become more important when Python 2.7 is > end-of-lifed. The reality is that many apps work perfectly well now > using Python 2.7, or 2.6, or even 2.4, and they'll continue to work well > in five or ten years so there's no real need to update. At the last US > PyCon, there was even one fellow still using Python 1.5. It works, he > didn't need security updates, so why migrate? > > Perhaps the biggest reason ..... Why not ask? Well, python.org conducted a survey as of January 2014 an answer given was that 60% of developers were held back from moving projects because of dependencies. This is a big number and it is not just guessing but real figures. *This is not a problem to be solved.* It's okay for people to stick with > an old version of Python. There's no rule that says Python has failed if > some developers stick to old versions. > > OK. So you are telling us forget moving our developers to python3 until every last dependency has moved. And we should also force the people who in turn use our code to stay with python2 and it is not a problem. > > > As things stand, the popularity of Python has dropped by most measures > > since the release of Python 3. Improve the language and lose market > share? > > I suggest that is all about the pain of the transition. > > That sounds remarkably like FUD to me. Where is your evidence that the > popularity of Python has fallen? > > Personally, I think all the "language popularity" measures are dubious, > or at least need to be treated with considerable skepticism. Take this > one: > > http://langpop.com/ > > which lists BrainF--- in the 40 most popular languages. Sure it is. > > The PyPL popularity index here: > > > https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY-of-Programming-Language > > Thanks for that- useful link! Please remember I am the converted, so it helps to have arguments to push back with when others push tiobe in front of me. > shows Python as increasing in popularity. In contrast, TIOBE shows > Python as losing popularity -- but so did Java, PHP, C++ and Ruby, and > none of them have a major version change. (TIOBE also shows that despite > a large number, possibly majority, of VB 6 developers boycotting VB.Net, > VB.Net has just entered the top 10 most popular languages.) > > And then there's CodeEval, which for the third year in a row has found > that Python is more popular than Java, C++, C, PHP and Javascript. In > fact more popular than Java, C and PHP *together*. > > http://blog.codeeval.com/codeevalblog/2014 > > Perhaps overstated, but it helps to have sources like this. It does say coding tests and challenges. I live in a country where school children have one national coding contest/challenge, and it is in python. (And in python 3, no dependencies :) ) Bless their little white socks, but methinks their methodology is > perhaps a tad flawed. > > I think it is interesting to compare and contrast these different ways > of measuring popularity, but then I'm a statistics wonk and I find even > flawed statistics interesting. Remember that there is no one true > definition of popularity, even if there were there is no accurate way of > measuring it, and all of the sites that claim to do so are actually > measuring subtley different things. > > Most importantly, chasing popularity for its own sake is a waste of > time. What makes Python Python is not just the syntax and std lib, but > also the culture -- we're neither the stultifying corporate culture of > "Java shops", nor the wild-west anything goes of cowboy PHP developers, > but something unique. (As are other languages, of course. Perl culture > is not Haskell culture is not Erlang culture.) In part, people take up > languages because they like the culture. Python will never attract the > corporate suits who like the Java philosophy, nor will it attract the > cowbody web developers who like the PHP way of doing things. Should we > try to ape PHP or Java to attract the cowboys or suits? Or should we > continue to make Python the best language that *we* like, regardless of > what other people prefer? > All agreed on the culture. But i suggest this is the biggest point. Stopping measures like a bridge that would allow many more end users to code in python3 just seems a negative culture. Effectively you are telling us that our team should not move to python3. > > Untimately, apart from winning pissing contests on Slashdot and Reddit, > what does it matter if Python is third most popular or ninth most > popular? Its not a popularity context where the winner takes all. > According to TIOBE, the most popular language, C, has less than 20% > share. If you think Python is a failure because it is in position 8, > what does that make Javascript in position 9? > > > > > You do not have to search hard to find comments to the effect 'nobody is > > using python3'. Or 'even if you use python 3, do not use the new > features > > since you need to ensure code is compatible with both versions'. > > You don't have to search very hard to find comments that Elvis was > kidnapped by aliens. > > https://duckduckgo.com/html/?q=elvis+kidnapped+by+aliens > > A belief which has rather more going for it than either of the two > comments you list above, since there's a miniscule, microscopic chance > that perhaps Elvis *was* kidnapped by aliens, whereas I know for a fact > beyond any doubt that some people are using Python 3 and using the new > features. > > I think I already covered this one. Again the point is that some people say it. We both know it is not literally true. If i did not program in python3 I would not bother posting suggestions to try and allow more programming in python3. Ian > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python... at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > Steven, -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron3200 at gmail.com Sat Mar 1 07:07:14 2014 From: ron3200 at gmail.com (Ron Adam) Date: Sat, 01 Mar 2014 00:07:14 -0600 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <20140301034611.GD28804@ando> References: <20140301034611.GD28804@ando> Message-ID: On 02/28/2014 09:46 PM, Steven D'Aprano wrote: > On Fri, Feb 28, 2014 at 11:17:18AM -0600, Ron Adam wrote: >> > >> >Starting new thread because this bike has a different shape and color. >> > >> >Yesterday I was thinking that just making the keyword lambda assignable >> >like True, False, and None, would be enough. > You can't assign to True, False or None. (You can assign to True and > False in Python 2, but shouldn't.) I meant it the other way around. For example... def is not assignable to anything.. D = def # won't work T = True # works F = False N = None L = lambda # won't work lambda isn't an object like True, False, and None. > [...] >> >This morning I thought we could have in a functions definition something, >> >like "*", and "**", to take an expression. Similar to Nicks idea with =:, >> >but more general. >> > >> >The idea is to have "***" used in def mean to take "any" call expression >> >and not evaluate it until *** is used on it. > [...] >> >A function call that captures an expression may be tricky to do. Here's one >> >approach that requires sugar when a function defined with "***" is called. > I think it would be useful to have a way to delay execution of an > expression, that is to say, have a way to capture an expression for > later evaluation, something more lightweight than a function, but I > don't think that limiting it to inside function calls is the right > approach. The expressing part isn't limited to inside function calls.. Or wouldn't be if it was a doable idea. > Something perhaps like a thunk might be appropriate? We can*almost* do > that now, since Python has a compile function: > > thunk = compile("x + 3", "", "eval") > # much later > eval(thunk) def thunk(***expr): return expr def do thunks(*args): for expr in args: ***expr start = t = time() update_timer = thunk(t = time()) show_timer = thunk(print(t-start)) show_status = thunk(do_thunks(upate_timer, show_timer)) Then as you do things, possibly in different functions as well. ... ***show_status # update t, and prints elapsed time. ... ***show_status ... ***show_status ... Yes, it could be done with lambda too. Here's where it differs... So if we have this, where obj is nested expressions. While 1: try: obj = ***obj except TypeError: break Then the result of the obj expression, could be a callable without any conflict. Only delayed expressions would be expressed. This was one of the properties I was looking for. > Some problems with that approach: > > - You have to write the expression as a string, which means you lose any > possibility of syntax highlighting. > > - The temptation is to pass some arbitrary untrusted string, which leads > to serious security implications. The argument here should be limited > to an actual expression, not a string containing an expression which > might have come from who knows where. > > - It should be as lightweight as possible. The actual compilation of the > expression should occur at compile-time, not run-time. That implies some > sort of syntax for making thunks, rather than a function call. > > - Likewise actually evaluating the thunk should be really lightweight, > which may rule out a function call to eval. > > - How should scoping work? I can see use-cases for flat scoping, static > scoping, dynamic scoping, and the ability to optionally provide custom > globals and locals, but I have no idea how practical any of them would > be or what syntax they should use. That's where the idea I mentioned in another response to this thread comes in. Separating the namespace constructing from the code part of a function in a well defined way. If that can be done... also pie in the sky. Then we could also evaluate an expression in a previously defined namespace. It's hypothetical, so supply your own syntax for it. The compiler will still compile the code, so most of the work is still done at compile time. But we have these useful pieces we can take apart and put back together again. (without calling eval, or exec.) BTW, you can do that now, but it's very hard to get right. help(type(lambda:1)) > All of this is pie-in-the-sky at the moment, and not a serious proposal > for Python 3.5. Agree. Cheers, Ron From rosuav at gmail.com Sat Mar 1 07:43:50 2014 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 1 Mar 2014 17:43:50 +1100 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> Message-ID: On Sat, Mar 1, 2014 at 4:53 PM, ian o wrote: > A bridge like this would allow us to move now, and that would allow pressure > on the module providers. Think about what the bridge really means. It means that you move now, yes, but it also means that the existing module is working fine. That means there is *no* pressure on the module provider. The pain of maintaining the bridge is all yours. You want to put pressure on the module provider? *Don't* have the bridge. Then you have an incentive to get that module ported, because then you could migrate. Maybe that means you lean on the developers; maybe that means you run the code through 2to3 and then start dealing with test suite failures, and then submit the code back to them and say "Here's Python 3.3 support, these are the downsides, will you accept it?". That's the sort of pressure that's likely to work. Saying "Hey, we can use your module in Python 3 now, thanks to a Python-in-C-in-Python bridge" will evoke the response "Okay fine, no problem then!". ChrisA From ncoghlan at gmail.com Sat Mar 1 07:55:37 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 1 Mar 2014 16:55:37 +1000 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> Message-ID: On 1 March 2014 15:53, ian o wrote: > Steven, >> *This is not a problem to be solved.* It's okay for people to stick with >> an old version of Python. There's no rule that says Python has failed if >> some developers stick to old versions. >> > OK. So you are telling us forget moving our developers to python3 until > every last dependency has moved. And we should also force the people who in > turn use our code to stay with python2 and it is not a problem. Ian, please keep in mind that you are asking people to do extra work for you *for free*, after you have already been benefiting for years from work that we already made available to you free of charge. The latter part is OK, and entirely the way non-commercial open source works, but it *does* mean that you *don't* get to tell the core development team our priorities are wrong when you haven't paid us a cent. If that's the kind of relationship you want, pay a commercial vendor to listen to your concerns - mediating between customers and the community one of the services commercial open source vendors provide (and the best ones will then contribute upstream development effort on your behalf). By contrast,community oriented open source operates on a time-based economy - the only ways for people to get things are done to dedicate their own time, inspire others to dedicate their time, or else to pay developers (either directly or indirectly through a vendor) to spend *their* time on projects of interest to those providing the funds. The CPython core development team has made it clear we don't want to support running Python 2 and 3 code in the same process because doing so is *hard* (and perhaps even impossible without completely redesigning the interpreter) and certainly *not fun*. The inspiration based approach is unlikely to work in this case (because we've already considered the possibility and dismissed it as impractical), but that still leaves open the possibility of finding someone else that is interested in attempting to prove us wrong, as well as people finding a way to pay someone to make it happen. However, in both cases, keep in mind that the people *most* familiar with the CPython code base think it's a bad idea that probably won't work. Instead, with the aid of many other members of the community, we've created a source based migration approach that involves taking advantage of the large common subset of Python 2 & 3. If commercial operations higher in the stack would like to migrate to Python 3, but are relying on dependencies that the community has provided for free, then it's time to think seriously about *investing* in the community and helping those projects to migrate (either by contributing developer time directly or by contributing funds to the existing developers for those projects). Note that the Python Software Foundation is able to help mediate requests for assistance with getting dependencies ported. Regards, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Sat Mar 1 08:26:23 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 1 Mar 2014 17:26:23 +1000 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <20140301034611.GD28804@ando> References: <20140301034611.GD28804@ando> Message-ID: On 1 March 2014 13:46, Steven D'Aprano wrote: > > Something perhaps like a thunk might be appropriate? We can *almost* do > that now, since Python has a compile function: > > thunk = compile("x + 3", "", "eval") > # much later > eval(thunk) FWIW, I think this is why PEP 312 (simple implicit lambda) garnered any interest at all: sure, you can't pass such a lambda any arguments, but it works fine as a *closure*. It's also potentially worth trawling the python-ideas archives for the various discussions about deferred and delayed expressions - they're generally all variants of the same basic idea, a less esoteric, easier to learn way to handle one-shot callbacks and other forms of lazy expression evaluation. The "lambda" keyword in the current syntax ends up being a distraction rather than an aid to understanding. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From abarnert at yahoo.com Sat Mar 1 08:44:49 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Fri, 28 Feb 2014 23:44:49 -0800 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> Message-ID: On Feb 28, 2014, at 21:53, ian o wrote: > Agreed. But in the real world, an example of a major dependency requiring python2, web2py, states they will be motivated to python3 when the users of their framework move. This is an interesting choice for an example. web2py isn't just a library, it's a framework. Its main purpose is to run your code in the right situations. Which is exactly the kind of thing your bridge cannot handle, for the reasons you already gave. And I don't think this is a coincidence. The same thing is true of many of the most prominent packages that haven't been ported yet--Twisted, Paste, gevent, supervisor, etc. On top of that, web2py is all about passing Internet strings around. The same thing that makes it difficult to port--the bytes/Unicode distinction--would make it just as hard to use through the bridge. Anyway, if you're interesting in pursuing this, obviously nobody is going to stop you from doing it and putting it on PyPI. And if there's as much interest in the idea as you think, you should start getting outside contributions as soon as you have a workable beta (or you might even be able to get funded development before that). And if it became popular enough, you could come back to the core dev team and say, "Like it or not, there are tons of major projects relying on my bridge, and the consequences aren't nearly as gloomy as you suspected, so what about putting it in the stdlib?" From ian.team.python at gmail.com Sat Mar 1 09:03:05 2014 From: ian.team.python at gmail.com (ian o) Date: Sat, 1 Mar 2014 00:03:05 -0800 (PST) Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> Message-ID: <3b02e645-b04f-4998-a3ec-ef1f21f3f4a4@googlegroups.com> > Ian, please keep in mind that you are asking people to do extra work > for you *for free*, after you have already been benefiting for years > from work that we already made available to you free of charge. The > latter part is OK, and entirely the way non-commercial open source > works, but it *does* mean that you *don't* get to tell the core > development team our priorities are wrong when you haven't paid us a > cent. Nic, Why are you so aggressive? No one is trying to 'tell' people to do something. I was proposing an idea here. I thought it was a relevant useful idea, so i have been arguing the case that idea is useful. Others argue the case that it is not useful and to me this is a constructive way to share ideas, hear other points of view so they can be considered. For commercial purposes you have managed to convince me I should cease to lobby for python to be used in the projects where I assist. Obviously commercial use is clearly not desired by the community, that is the first lesson i have learned. As I am not paid to champion python in the work environment, having been enlightened that python community does not desire commercial usage, I will cease. I came this forum hoping to contribute. I do not get paid to post here, nor will python being used in projects where i am involved generate a financial outcome for me. I simply feel a passion for the language and have been supporting the use of python in education and it helps push case for students learning python when there is also commercial usage. Is educational usage also to be discouraged? So now I am being told that not only are commercial users not to be encouraged, but also opinions and ideas of those who have been involved in commercial projects are not welcome. Disappointing. If a welcome as a result of a debate it was agreed that the approach I feel will help both library module developers and end users and was worth supporting but the community then the decision question would come as to who would donate time to implementation. While i would get no commercial benefit and do not have a lot time i would have tried to help. I think the idea has merit. But what is the point? It seems even debate on desirability of the idea in your opinion is not to be encouraged. From others I get the sense of community. But from you I get the sense of a closed club. Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Sat Mar 1 09:05:52 2014 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 1 Mar 2014 19:05:52 +1100 Subject: [Python-ideas] A python bridge between versions In-Reply-To: <3b02e645-b04f-4998-a3ec-ef1f21f3f4a4@googlegroups.com> References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> <3b02e645-b04f-4998-a3ec-ef1f21f3f4a4@googlegroups.com> Message-ID: On Sat, Mar 1, 2014 at 7:03 PM, ian o wrote: > Why are you so aggressive? > No one is trying to 'tell' people to do something. > > I was proposing an idea here. If your idea is accepted, someone has to implement it :) That's work, and a lot of it. So unless you're volunteering to actually write this thunker/bridge/shim/etc, you're asking someone else to. ChrisA From abarnert at yahoo.com Sat Mar 1 09:29:02 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Sat, 1 Mar 2014 00:29:02 -0800 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <20140301034611.GD28804@ando> References: <20140301034611.GD28804@ando> Message-ID: <807BB590-DE68-4E3C-9DC3-F37335DFBFAD@yahoo.com> On Feb 28, 2014, at 19:46, Steven D'Aprano wrote: > Something perhaps like a thunk might be appropriate? We can *almost* do > that now, since Python has a compile function: To save Haoyi Li the trouble of saying it: we _can_ do this now, since Python has import hooks, so you can use MacroPy to quote an expression, giving you an AST to evaluate later, or automatically wrapping it up in a function (like quote and function, respectively, in Lisp). There's also an in-between option of compiling it to a code object but not wrapping that in a function object. There's one other crazy option for representing quoted expressions/thunks: as lazy futures. This is how Alice does it, and it's also implicitly what dataflow languages like Oz are doing (every variable is a lazy future). In Python, this would really just be a wrapper around a function call, so I don't think it would but anything. Which one of those do people want? I'm not sure. Since you did a great job listing the problems of the string-quoting solution, we can compare the options for each one. > - You have to write the expression as a string, which means you lose any > possibility of syntax highlighting. Obviously not a problem here. > - The temptation is to pass some arbitrary untrusted string, which leads > to serious security implications. The argument here should be limited > to an actual expression, not a string containing an expression which > might have come from who knows where. Again, not a problem. > - It should be as lightweight as possible. The actual compilation of the > expression should occur at compile-time, not run-time. That implies some > sort of syntax for making thunks, rather than a function call. Not a problem for the function or code versions. For the AST version, you're doing part of the compilation at compile-time, and the rest at runtime. > - Likewise actually evaluating the thunk should be really lightweight, > which may rule out a function call to eval. A function is obviously no better or worse than using lambda today. A code object has to be evaluated by passing it to eval, or wrapping it in a function and calling it. I suspect the former may be lighter weight than calling a function, but I really don't know. The latter, or the other hand, is obviously heavier than calling a function, but not by that much. An AST has to be compiled to a code object, after which you do the same as the above. Obviously this is heavier than not having to compile. > - How should scoping work? I can see use-cases for flat scoping, static > scoping, dynamic scoping, and the ability to optionally provide custom > globals and locals, but I have no idea how practical any of them would > be or what syntax they should use. This, I think, is the big question. A function is clearly a normal, static-scoped closure. An AST or code object, you could do almost any form of scoping you want _except_ static, either by building a function around it or by calling eval on it. (You can do additional tricks with an AST, but I don't think most programs would want to. For statements, this could be useful for optional hygienic variables, but for expressions that isn't an issue.) If we want static scoping, we really need functions. At least we need some kind of object that has some form of code plus a closure mechanism--and that's pretty much all functions are. On the other hand, if we want dynamic, flat, or customizable scoping, we need something we can either build a function object out of dynamically, or evaluate dynamically--and that's pretty much what code objects are. From ian.team.python at gmail.com Sat Mar 1 09:40:58 2014 From: ian.team.python at gmail.com (ian o) Date: Sat, 1 Mar 2014 00:40:58 -0800 (PST) Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> <3b02e645-b04f-4998-a3ec-ef1f21f3f4a4@googlegroups.com> Message-ID: Chris, First the idea has to be accepted as desirable, then feasible with an agreed specification. All to no avail unless someone can then implement it. I would volunteer to assist but i assume there have to be enough others to volunteer as well if it was any help. But there is no intent to tell people to do something. There has to be sufficient enthusiasm for anyone involved to actually want to do it. But I have been told that those who would benefit are people that there is no desire to help. My suggestion that it would also be helpful to people there is a desire to help seems to have been met with the response 'we do not want to hear this'. I guess I expected a more open community. I have learned a lot, but not what I expected. I am still not sure what the criteria is to actually be welcome here. I have very much appreciated your comments though. Ian On Saturday, March 1, 2014 7:05:52 PM UTC+11, Chris Angelico wrote: > > On Sat, Mar 1, 2014 at 7:03 PM, ian o > > wrote: > > Why are you so aggressive? > > No one is trying to 'tell' people to do something. > > > > I was proposing an idea here. > > If your idea is accepted, someone has to implement it :) > > That's work, and a lot of it. So unless you're volunteering to > actually write this thunker/bridge/shim/etc, you're asking someone > else to. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python... at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.brandl at gmx.net Sat Mar 1 10:11:59 2014 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 01 Mar 2014 10:11:59 +0100 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> <3b02e645-b04f-4998-a3ec-ef1f21f3f4a4@googlegroups.com> Message-ID: Am 01.03.2014 09:40, schrieb ian o: > Chris, > > First the idea has to be accepted as desirable, then feasible with an agreed > specification. All to no avail unless someone can then implement it. > > I would volunteer to assist but i assume there have to be enough others to > volunteer as well if it was any help. > > But there is no intent to tell people to do something. There has to be > sufficient enthusiasm for anyone involved to actually want to do it. > > But I have been told that those who would benefit are people that there is no > desire to help. My suggestion that it would also be helpful to people there is > a desire to help seems to have been met with the response 'we do not want to > hear this'. > > I guess I expected a more open community. I have learned a lot, but not what I > expected. I am still not sure what the criteria is to actually be welcome here. Hi Ian, I'm sorry you feel like this. It's definitely not the intention of this list to exclude people -- just look at the wild ideas being discussed all the time... The Python 2/3 topic is simply a "sore point" for many of us, having discussed it time and again, often times with quite aggressive people (with the "why have you ruined my Python" mindset). Therefore we tend to become a little categorical faster than with other topics, even to people like you who aren't being aggressive. I hope you can forgive Nick, who has put tons of work into the excellent 2 vs 3 FAQ, being a bit thin-skinned :) In other words: Welcome to the Python community - don't let the 16-ton weight scare you off! cheers, Georg From ncoghlan at gmail.com Sat Mar 1 10:46:57 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 1 Mar 2014 19:46:57 +1000 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> <3b02e645-b04f-4998-a3ec-ef1f21f3f4a4@googlegroups.com> Message-ID: On 1 March 2014 19:11, Georg Brandl wrote: > Am 01.03.2014 09:40, schrieb ian o: >> I guess I expected a more open community. I have learned a lot, but not what I >> expected. I am still not sure what the criteria is to actually be welcome here. > > Hi Ian, > > I'm sorry you feel like this. It's definitely not the intention of this list > to exclude people -- just look at the wild ideas being discussed all the time... > > The Python 2/3 topic is simply a "sore point" for many of us, having discussed > it time and again, often times with quite aggressive people (with the "why have > you ruined my Python" mindset). Therefore we tend to become a little > categorical faster than with other topics, even to people like you who aren't > being aggressive. I hope you can forgive Nick, who has put tons of work into > the excellent 2 vs 3 FAQ, being a bit thin-skinned :) Aye, I hit the "This is holding back Python!" in Ian's original post, and subsequently interpreted the rest of the post (and thread) in an extremely negative light. We get a *lot* of people making such accusations (understandably so, even though those accusations aren't adequately backed up by the available data), so I have a very low tolerance at the moment for anything that even hints at commercial operations complaining about the quality of open source work they aren't funding (or otherwise contributing to), but are relying on anyway. However, Ian, It sounds like that wasn't your intent, so my apologies (once again) for taking it that way. Regards, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From stefan_ml at behnel.de Sat Mar 1 11:51:23 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 01 Mar 2014 11:51:23 +0100 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: ian o, 01.03.2014 04:09: > We have 3 teams working server systems currently with python as the > implementation model. All work is currently in python 2.x and with a > solution to this the work could immediately move to 3.x. You are mixing things up here. If you are developing application code, you don't really have a problem. Either you stay with 2.x or you switch to 3.x. You may even decide to stay in Py2 with some of your applications and migrate the others. Or migrate one after the other, over months or years. You really don't have to break your running systems, and definitely not all of them at once. It's entirely your choice, and doing the switch (if you want to) really isn't all that hard. Nick pointed you to a couple of resources that can help you in the progress. Many, many others have done it before, and have found that breaking all bridges after you have passed over them is a perfectly reasonable and efficient way to migrate, *specifically* for application code. The real problem, and that's what Nick was referring to, is writing and maintaining libraries that others depend on, because these others may use Python 2.x (and may not even want to switch to Py3), or they may use Python 3.x (and do not care about Python 2.x). But the library authors do not control the application code. Therefore, to cater for both user groups, library maintainers currently have to write code that works on both platforms, which is annoying and time consuming. Since you seem to be interested in migrating your application code in order to take advantage of Python 3, my advice is to (ta-da!) start migrating your code. And when that's done, stop looking back. Any "solution" that involves running a mix of Py2 and Py3 inside of one application is just screaming for endless trouble. Don't forget that "temporary solutions" tend to be the most durable in practice. Stefan From g.rodola at gmail.com Sat Mar 1 12:33:02 2014 From: g.rodola at gmail.com (Giampaolo Rodola') Date: Sat, 1 Mar 2014 12:33:02 +0100 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: On Sat, Mar 1, 2014 at 6:09 AM, Andrew Barnert wrote: > For that matter, have you actually checked whether those libraries really > are blocking you? I've lost count of the number of people who've claimed > they can't switch to Python 3 because of some library that's been ported > since 2010 or that has a 3.x-compatible drop-in replacement. > The problem you mention here is absolutely *real*. It's not only a matter of whether all your deps have currently been ported already. Software evolves over time and you can also remain stuck later, when you suddenly decide you need lib X and lib X hasn't been ported yet (uh-oh! what do I do now?). And please, note that *as of now* lib X includes names such as Twisted and Paramiko, which means hundreds of thousands of users which are stuck as we speak. How can a company decide to make the switch starting from such an assumption? The assumption that lib X or Y might not be ported soon, or even *ever*? IMHO as long as we won't get close to a 100% of libs being ported the current situation is not likely to change. FWIW here's some stats (inspired by recent Brett Cannon's post about openstack): http://stackoverflow.com/a/22113627/376587 -- Giampaolo - http://grodola.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From breamoreboy at yahoo.co.uk Sat Mar 1 16:48:48 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Sat, 01 Mar 2014 15:48:48 +0000 Subject: [Python-ideas] A python bridge between versions In-Reply-To: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> Message-ID: On 27/02/2014 23:26, ian o wrote: I have read every entry so far on this thread and have been forced to the conclusion that this is A Bridge Too Far. Sorry :( -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From Steve.Dower at microsoft.com Sat Mar 1 16:54:26 2014 From: Steve.Dower at microsoft.com (Steve Dower) Date: Sat, 1 Mar 2014 15:54:26 +0000 Subject: [Python-ideas] Update the required C compiler for Windows to a supported version. In-Reply-To: References: <3dd00aa18f174c4e93a26f6e806b8439@BLUPR03MB293.namprd03.prod.outlook.com>, Message-ID: <682219fab07d40a5acee0eaf50b7992c@BLUPR03MB389.namprd03.prod.outlook.com> Not at my desk, so I can only get you started (didn't want to keep you waiting until Monday). It'll look something like this: IF %1 eq x86 CALL bin\vcvars32.bat %* IF %1 eq amd64 CALL bin\vcvars64.bat %* (similar for x86_amd64) The file should go at C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat If you want to redistribute something that will work for others, it's possible to monkey patch distutils from your setup.py. I can't remember the specifics right now, so I can't help with that until I'm back at work. I think that's the best long term solution for 2.7 packages that want to build on Windows. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Vernon D. Cole Sent: ?3/?1/?2014 2:24 To: Steve Dower Cc: Stephen J. Turnbull; python-ideas Subject: Re: [Python-ideas] Update the required C compiler for Windows to a supported version. Sorry to resurrect this thread after so long a time, but I am starting to work on a project where I need this again... Any chance that I can get a copy (or a link to) " the vcvarsall.bat file that distutils expects. (Though it's pretty simple to add one" ? It's only simple to add one if you know what changes to make. -- VC On Wed, Nov 27, 2013 at 7:24 PM, Steve Dower > wrote: Stephen J. Turnbull wrote: > Vernon D. Cole writes: > >> I cannot compile a Python extension module with any Microsoft compiler >> I can obtain. > > Your pain is understood, but it's not simple to address it. FWIW, I'm working on making the compiler easily obtainable. The VS 2008 link that was posted is unofficial, and could theoretically disappear at any time (I'm not in control of that), but the Windows SDK for Windows 7 and .NET 3.5 SP1 (http://www.microsoft.com/en-us/download/details.aspx?id=3138) should be around for as long as Windows 7 is supported. The correct compiler (VC9) is included in this SDK, but unfortunately does not install the vcvarsall.bat file that distutils expects. (Though it's pretty simple to add one that will switch on %1 and call the correct vcvars(86|64|...).bat.) The SDK needed for Python 3.3 and 3.4 (VC10) is even worse - there are many files missing. I'm hoping we'll be able to set up some sort of downloadable package/tool that will fix this. While we'd obviously love to move CPython onto our latest compilers, it's simply not possible (for good reason). Python 3.4 is presumably locked to VC10, but hopefully 3.5 will be able to use whichever version is current when that decision is made. > The basic problem is that the ABI changes. Therefore it's going to require > a complete new set of *all* C extensions for Windows, and the duplication > of download links for all those extensions from quite a few different vendors > is likely to confuse a lot of users. Specifically, the CRT changes. The CRT is an interesting mess of data structures that are exposed in header files, which means while you can have multiple CRTs loaded, they cannot touch each other's data structures at all or things will go bad/crash, and there's no nice way to set it up to avoid this (my colleague who currently owns MSVCRT suggested a not-very-nice way to do it, but I don't think it's going to be reliable enough). Python's stable ABI helps, but does not solve this problem. The file APIs are the worst culprits. The layout of FILE* objects can and do change between CRT versions, and file descriptors are simply indices into an array of these objects that is exposed through macros rather than function calls. As a result, you cannot mix either FILE pointers or file descriptors between CRTs. The only safe option is to build with the matching CRT, and for MSVCRT, this means with the matching compiler. It's unfortunate, and the responsible teams are well aware of the limitation, but it's history at this point, so we have no choice but to work with it. Cheers, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscar.j.benjamin at gmail.com Sat Mar 1 18:34:34 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Sat, 1 Mar 2014 17:34:34 +0000 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: On 1 March 2014 03:09, ian o wrote: > >> >> And we don't actually mind all that much if applications don't migrate >> in the near term - Python 2 will have commercial support available >> well past 2020. (The developers of *those applications* might mind, >> though, just as anyone maintaining Python 2.4 compatibility for the >> benefit of RHEL/CentOS 5 typically isn't happy about it) > > Your response is most dissapointing, and I would hope does not represent the > community overall. > > We have 3 teams working server systems currently with python as the > implementation model. All work is currently in python 2.x and with a > solution to this the work could immediately move to 3.x. > > However, you state that our situation, and that of the other 60% of python > programmers as at end January 2014 who are constrained from using python 3 > by python 2 dependencies: "we don't mind about those developers" Hi Ian, In the past I've sometimes seen Nick being slightly careless with his words with the result that someone misunderstands him and gets upset. That's not what's happening here though. I'm not sure if you're wilfully misunderstanding him or just unable to see this from his perspective. Nick clearly did not say that he (or anyone else) doesn't care about any particular group of *developers*. What he meant is that if you as an application author have decided that sticking with Python 2 is the right thing to do right now then he won't try to argue with you. If your application is currently working and has a dependency on web2py and it's not worth your time/money to port web2py yourselves then sticking with Python 2 may be the right decision for you. OTOH if you were the author of web2py and said "I don't want to port web2py to Python 3" Nick would mind. He would want to know why you didn't want to port to Python 3 and whether or not there was something (reasonable) that the core Python devs could do to help. This is because if a library is not ported then that has a knock-on effect on application authors (such as you) who would like to port an existing application or write a new application for Python 3. Oscar From ncoghlan at gmail.com Sun Mar 2 01:39:17 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 2 Mar 2014 10:39:17 +1000 Subject: [Python-ideas] Update the required C compiler for Windows to a supported version. In-Reply-To: <3dd00aa18f174c4e93a26f6e806b8439@BLUPR03MB293.namprd03.prod.outlook.com> References: <3dd00aa18f174c4e93a26f6e806b8439@BLUPR03MB293.namprd03.prod.outlook.com> Message-ID: On 28 November 2013 04:24, Steve Dower wrote: > The SDK needed for Python 3.3 and 3.4 (VC10) is even worse - there are many files missing. I'm hoping we'll be able to set up some sort of downloadable package/tool that will fix this. While we'd obviously love to move CPython onto our latest compilers, it's simply not possible (for good reason). Python 3.4 is presumably locked to VC10, but hopefully 3.5 will be able to use whichever version is current when that decision is made. The main challenge we face on that front is the fact that Visual Studio 2013 is Windows 7+ only, so we'd potentially be causing problems for people still developing on XP or Vista if we update. Windows XP goes EOL next month, so that will be dropped for 3.5 next year in accordance with PEP 11. However, Vista is still in extended support until 2017 - under the current PEP 11 guidelines, that means it will be supported for at least 3.5, and likely 3.6 as well. If we update the required compiler we'd end up in a situation where CPython 3.5 nominally supports Vista, but Vista users would still need at least one Windows 7 machine to install the toolchain to create compatible C extensions. That may be OK given the number of people that jumped straight from XP to Windows 7, but it's still a consideration that would need to be taken into account. Longer term, we'd love to add a build farm to PyPI to take the drudgery out of creating pre-compiled wheel files (and MSI installers for Windows), and that would potentially address this problem as well (since the build farm would include the requisite Windows 7 images). However, I currently think it would be rather optimistic to assume that we'll have that in place by the time 3.5 rolls around (there's a lot of other things that need to be addressed before a build farm will make it to the top of the distutils-sig todo list). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From shibturn at gmail.com Sun Mar 2 12:42:52 2014 From: shibturn at gmail.com (Richard Oudkerk) Date: Sun, 02 Mar 2014 11:42:52 +0000 Subject: [Python-ideas] Update the required C compiler for Windows to a supported version. In-Reply-To: References: <3dd00aa18f174c4e93a26f6e806b8439@BLUPR03MB293.namprd03.prod.outlook.com> Message-ID: <5313193C.309@gmail.com> On 02/03/2014 12:39 am, Nick Coghlan wrote: > Windows XP goes EOL next month, so that will be dropped for 3.5 next > year in accordance with PEP 11. > > However, Vista is still in extended support until 2017 - under the > current PEP 11 guidelines, that means it will be supported for at > least 3.5, and likely 3.6 as well. BTW, Windows Server 2003 has extended support until 14 July 2015. Will it be supported in Python 3.5? -- Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at xemacs.org Sun Mar 2 15:55:43 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 02 Mar 2014 23:55:43 +0900 Subject: [Python-ideas] A python bridge between versions In-Reply-To: References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> Message-ID: <87iorwsl8w.fsf@uwakimon.sk.tsukuba.ac.jp> Stefan Behnel writes: > Since you seem to be interested in migrating your application code > in order to take advantage of Python 3, my advice is to (ta-da!) > start migrating your code. And when that's done, stop looking back. I'm sure he's thinking that way for himself. To be fair, though, as he describes it, Ian is evidently not the boss in the commercial projects he's talking about projects. He needs to convince others that Python 3 is a practical solution to their problems. This makes the idea of lobbying for Python a real enthusiasm drainer. I'm still all for it, but we should recognize the social aspects as well as the technical issues. Unfortunately, I'm not sure what, if anything, we can do to help support developers like Ian who can't impose Python 3 -- but rather has to expend personal energy and reputation in lobbying. From stephen at xemacs.org Sun Mar 2 15:37:48 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 02 Mar 2014 23:37:48 +0900 Subject: [Python-ideas] A python bridge between versions In-Reply-To: <3b02e645-b04f-4998-a3ec-ef1f21f3f4a4@googlegroups.com> References: <2d03c3e3-d036-4d68-b028-0848df54786a@googlegroups.com> <5b0b1caa-d1e1-4064-99ac-185f4dfae521@googlegroups.com> <20140301040740.GF28804@ando> <3b02e645-b04f-4998-a3ec-ef1f21f3f4a4@googlegroups.com> Message-ID: <87k3ccsm2r.fsf@uwakimon.sk.tsukuba.ac.jp> >>>>> Ian O. writes: > Nick Coghlan writes: >> Ian, please keep in mind that you are asking people to do extra work >> for you *for free*, after you have already been benefiting for years > Why are you so aggressive? > No one is trying to 'tell' people to do something. In Nick's defense, (1) he spends a *lot* of his time explaining why Python development proceeds as it does, (2) "just proposing ideas" sometimes is indeed a passive-aggressive ploy, (3) your timing is bad due to the appearance of an occasional poster who does do exactly that, and (4) Nick's probably harried with a major release in process and PyCon coming up. > For commercial purposes you have managed to convince me I should > cease to lobby for python to be used in the projects where I > assist. I think that's *exactly* the wrong lesson to learn, unless your management doesn't understand that free software is an investment and requires its users to spend resources to take advantage of it. It's just that the form of the resources required is often quite different from those required to use proprietary software. And of course it differs from product to product even within open source. So all you've learned from Nick is that Python is unlikely to dramatically reduce the resources required to migrate from Python 2 to Python 3 using technology like a "bridge". "Everyone would like a pony, but we don't have everyone's favorite pony." OTOH, it remains the case that most new applications can be written in Python 3 because there are good libraries to support them, although you may have to give up on some frameworks that depend on libraries that haven't been ported. That may be, but is not necessarily, a show-stopper. Now you say "lobbying". "Lobbying" implies effort and marshalling resources. Even if you strongly favor a particular framework that is *apparently* blocked by an unported library, it's surely theoretically possible that the shortest path to serving your company's software needs is spend company resources to port that library[1] -- as well as the personal resources to get the necessary support and resources from management! In practice, while I can't offhand give a case where a commercial company has done that port internally, I know at least one noncommercial project that is considering paying for a port of one of its Python3 blockers. I'm willing to bet you can find companies that have done 2to3 ports of libraries considering that to be the "shortest path to a product release", if you look around a bit. > Obviously commercial use is clearly not desired by the community, > that is the first lesson i have learned. As I am not paid to > champion python in the work environment, having been enlightened > that python community does not desire commercial usage, I will > cease. Are you aware how passive-aggressive your phrasing sounds? I'm sure you're well aware that not only are many Python developers involved in commercial development, but all of Python from the license on up is oriented toward encouragement of commercial use of Python. And it's been quite successful in commercial use. It would be nice if the language improvements in Python 3 came at zero cost. They don't, and we all feel that pinch at one time or another. But remember, innovations succeed not only by inventing completely new ideas that nobody ever thought of before, but also by hurdling cost barriers that others considered so high as to make known "interesting in theory" ideas "commercially impractical". I am not going to tell you that your cost barrier is lower than you think -- you know your situation, I don't. But I assure you that others, with high but not insuperable cost barriers, have indeed made that hurdle in porting libraries to Python 3, and I'm sure some are taking on new challenges today. Footnotes: [1] Just as if it were a completely different language ("that Perl module would be perfect if only it were in Python..." :-). From robert.kern at gmail.com Sun Mar 2 16:05:59 2014 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 02 Mar 2014 15:05:59 +0000 Subject: [Python-ideas] PEP-257: drop recommendation for extra line at end of multi-line docstring In-Reply-To: References: <30E13F8A-EE63-4E0F-A29A-F35B5906791C@rackspace.com> Message-ID: On 2014-02-27 22:41, Guido van Rossum wrote: > I haven't followed this recommendation for years. :-) Good riddance! FWIW, PEP 8 still suggests the old form, though the example was fixed to conform to the new suggestion: http://hg.python.org/peps/file/272debef6b77/pep-0008.txt#l548 http://hg.python.org/peps/rev/5efe00002b3e > (However, the one about two spaces after a period stands. :-) Alas! -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From guido at python.org Sun Mar 2 18:29:45 2014 From: guido at python.org (Guido van Rossum) Date: Sun, 2 Mar 2014 09:29:45 -0800 Subject: [Python-ideas] PEP-257: drop recommendation for extra line at end of multi-line docstring In-Reply-To: References: <30E13F8A-EE63-4E0F-A29A-F35B5906791C@rackspace.com> Message-ID: Fixed. Thanks for pointing this out! On Sun, Mar 2, 2014 at 7:05 AM, Robert Kern wrote: > On 2014-02-27 22:41, Guido van Rossum wrote: > >> I haven't followed this recommendation for years. :-) Good riddance! >> > > FWIW, PEP 8 still suggests the old form, though the example was fixed to > conform to the new suggestion: > > http://hg.python.org/peps/file/272debef6b77/pep-0008.txt#l548 > http://hg.python.org/peps/rev/5efe00002b3e > > > (However, the one about two spaces after a period stands. :-) >> > > Alas! > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Mon Mar 3 16:41:40 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Mon, 3 Mar 2014 09:41:40 -0600 Subject: [Python-ideas] Python3.3 Decimal Library Released Message-ID: Greetings, Python3.3 Decimal Library v0.3 is Released here: https://code.google.com/p/pythondecimallibrary/ pdeclib.py is the decimal library, pilib.py is the PI library. pdeclib.py provides scientific and transcendental functions for the C Accelerated Decimal module written by Stefan Krah. The library is open source, GLPv3, comprised of two py files. My idea for python is to two things really, 1) make floating point decimal the default floating point type in python4.x, and 2) make these functions ( pdeclib.py ) or equiv available in python4.x by default. Thank you for your consideration. -- Kind regards, Mark H. Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Mon Mar 3 16:58:02 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 03 Mar 2014 16:58:02 +0100 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: Message-ID: Hello Mark, Le 03/03/2014 16:41, Mark H. Harris a ?crit : > Greetings, > Python3.3 Decimal Library v0.3 is Released here: > > https://code.google.com/p/pythondecimallibrary/ > > pdeclib.py is the decimal library, pilib.py is the PI library. > > pdeclib.py provides scientific and transcendental functions > for the C Accelerated Decimal module written by Stefan Krah. The > library is open source, GLPv3, comprised of two py files. > > My idea for python is to two things really, 1) make floating point > decimal the default floating point type in python4.x, and 2) make > these functions ( pdeclib.py ) or equiv available in python4.x by > default. If you want to contribute those functions to Python, the first required step would be to license them under terms compatible with the contributor agreement: http://www.python.org/psf/contrib/contrib-form/ (i.e. under the Academic Free License v. 2.1 or the Apache License, Version 2.0) Regards Antoine. From harrismh777 at gmail.com Mon Mar 3 17:23:49 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Mon, 3 Mar 2014 08:23:49 -0800 (PST) Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: Message-ID: On Monday, March 3, 2014 9:58:02 AM UTC-6, Antoine Pitrou wrote: > > > Hello Mark, > > Le 03/03/2014 16:41, Mark H. Harris a ?crit : > > Greetings, > > Python3.3 Decimal Library v0.3 is Released here: > > > > https://code.google.com/p/pythondecimallibrary/ > > > > pdeclib.py is the decimal library, pilib.py is the PI library. > > > > pdeclib.py provides scientific and transcendental functions > > for the C Accelerated Decimal module written by Stefan Krah. The > > library is open source, GLPv3, comprised of two py files. > > > > My idea for python is to two things really, 1) make floating point > > decimal the default floating point type in python4.x, and 2) make > > these functions ( pdeclib.py ) or equiv available in python4.x by > > default. > > If you want to contribute those functions to Python, the first required > step would be to license them under terms compatible with the > contributor agreement: > http://www.python.org/psf/contrib/contrib-form/ > > (i.e. under the Academic Free License v. 2.1 or the Apache License, > Version 2.0) > Antoine, thank you for the response. I have e-signed the Academic Free License, and it is filed. Mark H Harris marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscar.j.benjamin at gmail.com Mon Mar 3 17:52:01 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Mon, 3 Mar 2014 16:52:01 +0000 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: Message-ID: On 3 March 2014 15:41, Mark H. Harris wrote: > Greetings, > Python3.3 Decimal Library v0.3 is Released here: > > https://code.google.com/p/pythondecimallibrary/ > > pdeclib.py is the decimal library, pilib.py is the PI library. > > pdeclib.py provides scientific and transcendental functions > for the C Accelerated Decimal module written by Stefan Krah. The > library is open source, GLPv3, comprised of two py files. > > My idea for python is to two things really, 1) make floating point decimal > the default floating point type in python4.x, This is an interesting suggestion. It's hard to judge how much code would be broken by such an explicit change. A preliminary less controversial step would just be to introduce decimal literals e.g 1.23d. > and 2) make > these functions ( pdeclib.py ) or equiv available in python4.x by > default. If there was a desire to add these then there's no reason why they would have to wait until the (hypothetical) release of Python 4.x. However I doubt that they would be accepted without having first spent some time maturing on PyPI and certainly not without unit tests. Oscar From harrismh777 at gmail.com Mon Mar 3 18:10:07 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Mon, 3 Mar 2014 09:10:07 -0800 (PST) Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: Message-ID: On Monday, March 3, 2014 10:52:01 AM UTC-6, Oscar Benjamin wrote: > > > This is an interesting suggestion. It's hard to judge how much code > would be broken by such an explicit change. A preliminary less > controversial step would just be to introduce decimal literals e.g > 1.23d. > > If there was a desire to add these then there's no reason why they > would have to wait until the (hypothetical) release of Python 4.x. > However I doubt that they would be accepted without having first spent > some time maturing on PyPI and certainly not without unit tests. > Oscar, sounds right. I would like to see it just the other way round. We have a very speedy decimal module, its 2014, and we just don't need any more of this: >>> from decimal import * >>> Decimal(.1) Decimal('0.1000000000000000055511151231257827021181583404541015625') >>> I'm from back in that day. You know, about 1982. We've embedded floats and doubles in everything from the processor to python and beyond. Memory is cheap, technology has advanced (heck, python is one of the coolest most sophisticated languages on the planet), its time to use decimal floating point. I'm thinking we ought to have decimal by default, and the binary literal 1.23b as the option. As far as how much code breaks; who knows, but it can't be any worse than moving from 2.7.x to 3.3.4. I mean, everyone thought that was going to break the world, and people have adapted just fine. Some folks are staying put on 2.7.6 (and that's fine) and some folks like me are out there on the bloody edge downloading 3.3.5 ! Thanks for the discussion Oscar. marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan_ml at behnel.de Mon Mar 3 18:24:48 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 03 Mar 2014 18:24:48 +0100 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: Message-ID: Mark H. Harris, 03.03.2014 18:10: > We > have a very speedy decimal module, its 2014, and we just don't need any > more of this: > > >>> from decimal import * > >>> Decimal(.1) > Decimal('0.1000000000000000055511151231257827021181583404541015625') I assume you are aware that the correct way to do this is >>> Decimal('0.1') Decimal('0.1') i.e., if you want exact precision, use exact literals. That being said, did you read through the previous discussions where people suggested to add decimal literals to Python? Stefan From steve at pearwood.info Mon Mar 3 18:54:29 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 4 Mar 2014 04:54:29 +1100 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: Message-ID: <20140303175429.GL28804@ando> On Mon, Mar 03, 2014 at 09:41:40AM -0600, Mark H. Harris wrote: > My idea for python is to two things really, 1) make floating point decimal > the default floating point type in python4.x, and I think it is premature to be talking about what goes into Python 4.x, which is why I refer to it as "Python 4000". There's no concrete plans for a Python 4 yet, or even whether there will be a Python 4, what the last Python 3.x version will be, or what sort of changes will be considered. But I would expect that any such Python 4 will probably be at least four years away, although given the extended life of 2.7 possibly more like eight. (Given the stress of the 2->3 migration, I think *nobody* is exactly in a hurry for yet another backwards incompatible version. Perhaps we should be delaying such things until Python 5000.) > 2) make > these functions ( pdeclib.py ) or equiv available in python4.x by > default. If it's worth having a decimal maths library, its probably worth having it in 3.5 or 3.6. -- Steven From zachary.ware+pyideas at gmail.com Mon Mar 3 19:23:58 2014 From: zachary.ware+pyideas at gmail.com (Zachary Ware) Date: Mon, 3 Mar 2014 12:23:58 -0600 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <20140303175429.GL28804@ando> References: <20140303175429.GL28804@ando> Message-ID: On Mon, Mar 3, 2014 at 11:54 AM, Steven D'Aprano wrote: > If it's worth having a decimal maths library, its probably worth having > it in 3.5 or 3.6. Agreed. I'm -1 on a decimal-specific math library, though. What I would rather see is a type-agnostic math library, that does what (IIRC) the new statistics module does: take in numbers of any type, coerce only as is strictly necessary, calculate, and return an answer of the same type as the input with the goal of correctness over performance. If all input is float (or complex), calculation could be delegated to the existing math (or cmath) libraries, and performance wouldn't be too much worse than using those libraries directly. -- Zach From ziad.sawalha at rackspace.com Mon Mar 3 19:55:17 2014 From: ziad.sawalha at rackspace.com (Ziad Sawalha) Date: Mon, 3 Mar 2014 18:55:17 +0000 Subject: [Python-ideas] PEP-257: drop recommendation for extra line at end of multi-line docstring In-Reply-To: References: <30E13F8A-EE63-4E0F-A29A-F35B5906791C@rackspace.com> <1FD9DEBB-1E68-4BB0-9349-B3FA2598D627@rackspace.com> Message-ID: <991C04FE-35F2-4641-B240-A353AD31A9E3@rackspace.com> Thanks, Guido. I?ll follow up with updates to common tools as I come across them (ex. pep257: https://github.com/GreenSteam/pep257/pull/64). Ziad On Feb 28, 2014, at 11:53 AM, Guido van Rossum > wrote: Updated! On Thu, Feb 27, 2014 at 8:58 PM, Ziad Sawalha > wrote: Approved :-) On Feb 27, 2014, at 9:33 PM, "Guido van Rossum" > wrote: How about this patch? http://codereview.appspot.com/69870043 On Thu, Feb 27, 2014 at 5:48 PM, Ziad Sawalha > wrote: On Feb 27, 2014, at 4:42 PM, "Bruce Leban" > wrote: To clarify are you asking to delete the recommendation of a blank line or the entire recommendation? That is are you suggesting the recommendation change to ?It is recommended to place the closing quotes on a line by themselves." That's right. I just want to get rid of the recommendation for the blank line. I think deleting it completely is a bad idea as otherwise it's hard to see where the docstring ends and the code begins, especially when using doctest. --- Bruce Learn how hackers think: http://j.mp/gruyere-security https://www.linkedin.com/in/bruceleban On Thu, Feb 27, 2014 at 2:06 PM, Ziad Sawalha > wrote: PEP-257 includes this recommendation: ?The BDFL [3] recommends inserting a blank line between the last paragraph in a multi-line docstring and its closing quotes, placing the closing quotes on a line by themselves. This way, Emacs' fill-paragraph command can be used on it.? I believe emacs no longer has this limitation. "If you do fill-paragraph in emacs in Python mode within a docstring, emacs already ignores the closing triple-quote. In fact, the most recent version of emacs supports several different docstring formatting styles and gives you the ability to switch between them.? - quoting Kevin L. Mitchell who is more familiar with emacs than I am. I?m considering removing that recommendation and updating some of the examples in PEP-257, but I?d like some thoughts from this group before I submit the patch. Any thoughts or references to conversations that may have already been had on this topic? Regards, Ziad _______________________________________________ Python-ideas mailing list Python-ideas at python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas at python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido) -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Mon Mar 3 20:25:50 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 03 Mar 2014 14:25:50 -0500 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <20140303175429.GL28804@ando> References: <20140303175429.GL28804@ando> Message-ID: On 3/3/2014 12:54 PM, Steven D'Aprano wrote: > I think it is premature to be talking about what goes into Python 4.x, > which is why I refer to it as "Python 4000". There's no concrete plans > for a Python 4 yet, or even whether there will be a Python 4, what the > last Python 3.x version will be, Given that Guido does not want double-digit minor version numbers, 3.9, at the latest, will be followed by 4.0. > or what sort of changes will be considered. There will be several deprecated items removed, such as http://docs.python.org/2/library/unittest.html#deprecated-aliases I think it would be worth making a consolidated list. I think a few modules that have replacements will be considered for removal. Optparse (if argparse is an adequate replacement)? Asyncore (if the new async catches on)? Changing the meaning of a core feature like float literals is a different matter. > But I would expect that any such Python 4 will probably be > at least four years away, although given the extended life of 2.7 > possibly more like eight. 3.5, ..., 3.9, 4.0 is 6 releases, which should be about 10 years. > (Given the stress of the 2->3 migration, I think *nobody* is exactly in > a hurry for yet another backwards incompatible version. Perhaps we > should be delaying such things until Python 5000.) -- Terry Jan Reedy From tjreedy at udel.edu Mon Mar 3 20:27:26 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 03 Mar 2014 14:27:26 -0500 Subject: [Python-ideas] PEP-257: drop recommendation for extra line at end of multi-line docstring In-Reply-To: <991C04FE-35F2-4641-B240-A353AD31A9E3@rackspace.com> References: <30E13F8A-EE63-4E0F-A29A-F35B5906791C@rackspace.com> <1FD9DEBB-1E68-4BB0-9349-B3FA2598D627@rackspace.com> <991C04FE-35F2-4641-B240-A353AD31A9E3@rackspace.com> Message-ID: On 3/3/2014 1:55 PM, Ziad Sawalha wrote: > Thanks, Guido. > > I?ll follow up with updates to common tools as I come across them (ex. > pep257: https://github.com/GreenSteam/pep257/pull/64). Does pep8.py try to enforce the extra blank? -- Terry Jan Reedy From p.f.moore at gmail.com Mon Mar 3 21:12:53 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 3 Mar 2014 20:12:53 +0000 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <20140303175429.GL28804@ando> Message-ID: On 3 March 2014 18:23, Zachary Ware wrote: > I'm -1 on a decimal-specific math library, though. What I would > rather see is a type-agnostic math library, that does what (IIRC) the > new statistics module does: take in numbers of any type, coerce only > as is strictly necessary, calculate, and return an answer of the same > type as the input with the goal of correctness over performance. Given that incorrect results aren't acceptable in any situation, fair enough, but what I'd like to see would be library functions that provided good performance for decimal first. If they can do so while remaining type-agnostic, then fine, but I'd favour decimal performance over the ability to calculate the sine of a rational... Ultimately, I'd like to feel that I pay a one-off cost for working with decimals (the cost of a software implementation rather than a hardware one) but I *don't* have to pay further because the algorithms used for decimals are suboptimal compared to the floating point ones. I'd say the same about rationals, but the set of functions involved is different (and basically wouldn't involve most of what's in the normal math library) Having said this, I can't actually think of a real-life domain where math-library functions (by which I assume we basically mean trancendental functions?) would be used and yet there would be a genuine need for decimal arithmetic rather than floating point. So although I'm +1 for a decimal math library in theory, I'm unsure of its practical value. Paul From mertz at gnosis.cx Mon Mar 3 21:44:12 2014 From: mertz at gnosis.cx (David Mertz) Date: Mon, 3 Mar 2014 12:44:12 -0800 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <20140303175429.GL28804@ando> Message-ID: Taking a look at the documentation for cdecimal itself (now part of Python 3.3) at http://www.bytereef.org/mpdecimal/benchmarks.html, it looks like for basic add/mul operations that don't exceed the precision of floating point, FP is more than twice as fast as optimized decimals. Of course, where the precision needed is more than FP handles at all, it's simply a choice between calculating a quantity and not doing so. This suggests to me a rather strong argument against making decimals the *default* numeric datatype. However, it *does* still remain overly cumbersome to create decimals, and a literal notation for them would be very welcomed. It is far from clear to me that decimals are generically the *right* answer to rounding issues (i.e. even if we don't care about the benchmark question). Yes, it's easier for humans who use base 10 to understand numeric results when using them. But the hardware on CPUs is oriented around binary floating point representations, and pretty much every other programming language uses BFP. It's a nice property to have 'a+b' in Python produce the same answer as 'a+b' in C, Ruby, Perl, Mathematica, Haskell, Java, etc.--I'm not saying that's the only nice property one might want, but it is one of them since data is exchanged between tools and libraries written in different languages (or even, e.g. Python often uses libraries written in C). I do recognize that in Python 4000, we *could* have default literals be decimal, and require some other literal notation for binary floating point, and that *would* be available for calculations meant to be compatible with outside tools. However, I haven't seen a case presented for why decimals are generically better as a default. Of possible note, I happen to work in a research lab where we worry a lot about bitwise identity of calculations, not merely about numeric stability. I know that is a somewhat unusual requirement, even within scientific computing. But it is one that exists, and it makes me think of (bitwise) compatibility with calculations in other programming languages. On Mon, Mar 3, 2014 at 12:12 PM, Paul Moore wrote: > On 3 March 2014 18:23, Zachary Ware > wrote: > > I'm -1 on a decimal-specific math library, though. What I would > > rather see is a type-agnostic math library, that does what (IIRC) the > > new statistics module does: take in numbers of any type, coerce only > > as is strictly necessary, calculate, and return an answer of the same > > type as the input with the goal of correctness over performance. > > Given that incorrect results aren't acceptable in any situation, fair > enough, but what I'd like to see would be library functions that > provided good performance for decimal first. If they can do so while > remaining type-agnostic, then fine, but I'd favour decimal performance > over the ability to calculate the sine of a rational... Ultimately, > I'd like to feel that I pay a one-off cost for working with decimals > (the cost of a software implementation rather than a hardware one) but > I *don't* have to pay further because the algorithms used for decimals > are suboptimal compared to the floating point ones. I'd say the same > about rationals, but the set of functions involved is different (and > basically wouldn't involve most of what's in the normal math library) > > Having said this, I can't actually think of a real-life domain where > math-library functions (by which I assume we basically mean > trancendental functions?) would be used and yet there would be a > genuine need for decimal arithmetic rather than floating point. So > although I'm +1 for a decimal math library in theory, I'm unsure of > its practical value. > > Paul > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Mon Mar 3 21:52:10 2014 From: guido at python.org (Guido van Rossum) Date: Mon, 3 Mar 2014 12:52:10 -0800 Subject: [Python-ideas] PEP-257: drop recommendation for extra line at end of multi-line docstring In-Reply-To: References: <30E13F8A-EE63-4E0F-A29A-F35B5906791C@rackspace.com> <1FD9DEBB-1E68-4BB0-9349-B3FA2598D627@rackspace.com> <991C04FE-35F2-4641-B240-A353AD31A9E3@rackspace.com> Message-ID: On Mon, Mar 3, 2014 at 11:27 AM, Terry Reedy wrote: > On 3/3/2014 1:55 PM, Ziad Sawalha wrote: > >> Thanks, Guido. >> >> I'll follow up with updates to common tools as I come across them (ex. >> pep257: https://github.com/GreenSteam/pep257/pull/64). >> > I already did that. > > Does pep8.py try to enforce the extra blank? > I dunno; it shouldn't. (I use it regularly and it doesn't complain to me.) -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Mon Mar 3 23:32:37 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Mon, 3 Mar 2014 14:32:37 -0800 (PST) Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <20140303175429.GL28804@ando> Message-ID: On Monday, March 3, 2014 2:44:12 PM UTC-6, David Mertz wrote: However, I haven't seen a case presented for why decimals are generically > better as a default. > > hi David, here is one, right out of the python3.3 docs, "Decimal ?is based on a floating-point model which was designed with people in mind, and necessarily has a paramount guiding principle ? computers must provide an arithmetic that works in the same way as the arithmetic that people learn at school.? ? excerpt from the decimal arithmetic specification. Business apps require precision (banking, sales, marketing, finance, & on and on). One big issue that is going to confront everyone sooner than later is cryptography. Fast bignum support, fast factoring, and fast transcendentals are going to become more important as firms and individuals move into their own on crypto; not too far fetched, really. We have got to come up with this on our own, because we can not trust others to get it right for us. NSA and GCHQ have made that clear. PGP was one thing, but we have got to invent something better. But, really the real reason is the first paragraph. marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Mon Mar 3 23:47:06 2014 From: mertz at gnosis.cx (David Mertz) Date: Mon, 3 Mar 2014 14:47:06 -0800 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <20140303175429.GL28804@ando> Message-ID: On Mon, Mar 3, 2014 at 2:32 PM, Mark H. Harris wrote: > Business apps require precision (banking, sales, marketing, finance, > & on and on). > I definitely agree the decimal numbers are much better for financial data than binary floating point. That's certainly a very legitimate domain. On the other hand, there are a great many other domains that are very different from this--i.e. scientific areas. For this, decimal is no better, and in many cases worse. At the very least, throwing in a 2x+ slowdown of calculations is notably worse for scientific computing. In other words, I'm glad we have decimals in Python now. I'd be more glad if they were expressed more easily (e.g. as literals), but for more domains than not, for backward and cross-language compatibility, and for speed, binary floating point remains better. > One big issue that is going to confront everyone sooner than later is > cryptography. Fast bignum support, fast factoring, and fast > transcendentals are going to become more important as firms and > individuals move into their own on crypto; not too far fetched, really. > Sounds far fetched to me to imagine that amateur cryptography will ever be of value over well-audited, well studied, crypto-analyzed techniques. But bracketing that, exceedingly few cryptographic techniques are likely to use either binary or decimal floating point operations. This is strictly the domain of integer math, so mentioning it seems like random hand waving unrelated to the topic of default or convenient representation of fractional numeric data. Yours, David... -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Mon Mar 3 23:54:08 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 04 Mar 2014 11:54:08 +1300 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <20140303175429.GL28804@ando> Message-ID: <53150810.20507@canterbury.ac.nz> Mark H. Harris wrote: > One big issue that is going to confront everyone sooner than later is > cryptography. Fast bignum support, fast factoring, and fast transcendentals > are going to become more important I don't see any reason that these have to be done in decimal, though. All the bignum arithmetic used in cryptography is integer, which is exact in any base. Also, the user never sees the resulting numbers as numbers. So the primary requirement is speed, which argues for binary rather than decimal, at least on current hardware. -- Greg From solipsis at pitrou.net Tue Mar 4 00:01:22 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 4 Mar 2014 00:01:22 +0100 Subject: [Python-ideas] Python3.3 Decimal Library Released References: <20140303175429.GL28804@ando> <53150810.20507@canterbury.ac.nz> Message-ID: <20140304000122.4f61e287@fsol> On Tue, 04 Mar 2014 11:54:08 +1300 Greg Ewing wrote: > Mark H. Harris wrote: > > One big issue that is going to confront everyone sooner than later is > > cryptography. Fast bignum support, fast factoring, and fast transcendentals > > are going to become more important > > I don't see any reason that these have to be done in > decimal, though. All the bignum arithmetic used in > cryptography is integer, which is exact in any base. > Also, the user never sees the resulting numbers as > numbers. So the primary requirement is speed, which > argues for binary rather than decimal, at least on > current hardware. For the record, int doesn't have a sqrt() method while Decimal has, so if you wanna take the exact square root of a large integer, you'd better convert it to a Decimal. Regards Antoine. From mertz at gnosis.cx Tue Mar 4 00:07:57 2014 From: mertz at gnosis.cx (David Mertz) Date: Mon, 3 Mar 2014 15:07:57 -0800 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <20140304000122.4f61e287@fsol> References: <20140303175429.GL28804@ando> <53150810.20507@canterbury.ac.nz> <20140304000122.4f61e287@fsol> Message-ID: On Mon, Mar 3, 2014 at 3:01 PM, Antoine Pitrou wrote: > For the record, int doesn't have a sqrt() method while Decimal has, so > if you wanna take the exact square root of a large integer, you'd better > convert it to a Decimal. > Well, actually, if you want to take the square root of a large integer, most times you'll need an irrational number as a value. Unfortunately, neither floats, decimals, nor fractions are able to do that (nor any finite representation that is numeric; you can only use symbolic ones). On the other hand, now that you mention it, a floor_sqrt() function that operated quickly on ints would be nice to have. But that's a different thread. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Tue Mar 4 00:10:48 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 4 Mar 2014 00:10:48 +0100 Subject: [Python-ideas] Python3.3 Decimal Library Released References: <20140303175429.GL28804@ando> <53150810.20507@canterbury.ac.nz> <20140304000122.4f61e287@fsol> Message-ID: <20140304001048.22d6442c@fsol> On Mon, 3 Mar 2014 15:07:57 -0800 David Mertz wrote: > On Mon, Mar 3, 2014 at 3:01 PM, Antoine Pitrou wrote: > > > For the record, int doesn't have a sqrt() method while Decimal has, so > > if you wanna take the exact square root of a large integer, you'd better > > convert it to a Decimal. > > > > Well, actually, if you want to take the square root of a large integer, > most times you'll need an irrational number as a value. Well, unless you know by construction that your integer is a perfect square. Regards Antoine. From rosuav at gmail.com Tue Mar 4 00:42:57 2014 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 4 Mar 2014 10:42:57 +1100 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <20140303175429.GL28804@ando> Message-ID: On Tue, Mar 4, 2014 at 7:44 AM, David Mertz wrote: > Taking a look at the documentation for cdecimal itself (now part of Python > 3.3) at http://www.bytereef.org/mpdecimal/benchmarks.html, it looks like for > basic add/mul operations that don't exceed the precision of floating point, > FP is more than twice as fast as optimized decimals. Of course, where the > precision needed is more than FP handles at all, it's simply a choice > between calculating a quantity and not doing so. > > This suggests to me a rather strong argument against making decimals the > *default* numeric datatype. However, it *does* still remain overly > cumbersome to create decimals, and a literal notation for them would be very > welcomed. You could probably make the same performance argument against making Unicode the default string datatype. But a stronger argument is that the default string should be the one that does the right thing with text. As of Python 3, that's the case. And the default integer type handles arbitrary sized integers (although Py2 went most of the way there by having automatic promotion). It's reasonable to suggest that the default non-integer numeric type should also simply do the right thing. It's a trade-off, though, and for most people, float is sufficient. Is it worth the cost of going decimal everywhere? I want to first see a decimal literal notation (eg 1.0 == float("1.0") and 1.0d == Decimal("1.0"), as has been suggested a few times), and then have a taggable float marker (1.0f == float("1.0")); then there can be consideration of a __future__ directive to change the default, which would let people try it out and see how much performance suffers.Maybe it'd be worth it for the accuracy. Maybe we'd lose less time processing than we save answering the "why does this do weird things sometimes" questions. ChrisA From random832 at fastmail.us Tue Mar 4 02:19:06 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Mon, 03 Mar 2014 20:19:06 -0500 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <20140303175429.GL28804@ando> Message-ID: <1393895946.9103.90200705.2DF58D8B@webmail.messagingengine.com> On Mon, Mar 3, 2014, at 15:12, Paul Moore wrote: > Having said this, I can't actually think of a real-life domain where > math-library functions (by which I assume we basically mean > trancendental functions?) would be used and yet there would be a > genuine need for decimal arithmetic rather than floating point. So > although I'm +1 for a decimal math library in theory, I'm unsure of > its practical value. If we count non-integer powers (though, usually they're still rational), finance. I suspect though there's a better case for an arbitrary-precision library and no reason that library shouldn't be (also) able to work in decimal. From harrismh777 at gmail.com Tue Mar 4 02:37:26 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Mon, 3 Mar 2014 17:37:26 -0800 (PST) Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: Message-ID: <53591b02-4790-4746-b6a9-10b43a864eaf@googlegroups.com> On Monday, March 3, 2014 9:41:40 AM UTC-6, Mark H. Harris wrote: > > > Python3.3 Decimal Library v0.3 is Released here: > > https://code.google.com/p/pythondecimallibrary/ > > hi Oscar, I released my pdeclib module on PyPI this afternoon (it only took four hours) but I'll never forget how to do that again ! So if anyone is interested in the pdeclib module, it may be installed with pip install pdeclib The tarball will install both pdeclib.py (decimal library) & pilib.py (PI Library). The library is beta obviously, and is licensed for contribution on PyPI. Cheers, marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Tue Mar 4 02:55:16 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 4 Mar 2014 12:55:16 +1100 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <20140303175429.GL28804@ando> Message-ID: <20140304015516.GM28804@ando> On Tue, Mar 04, 2014 at 10:42:57AM +1100, Chris Angelico wrote: > You could probably make the same performance argument against making > Unicode the default string datatype. I don't think so -- for ASCII strings the performance cost of Unicode is significantly less than the performance hit for Decimal: [steve at ando ~]$ python3.3 -m timeit -s "s = 'abcdef'*1000" "s.upper()" 100000 loops, best of 3: 8.76 usec per loop [steve at ando ~]$ python3.3 -m timeit -s "s = b'abcdef'*1000" "s.upper()" 100000 loops, best of 3: 7.05 usec per loop [steve at ando ~]$ python3.3 -m timeit -s "x = 123.4567" "x**6" 1000000 loops, best of 3: 0.344 usec per loop [steve at ando ~]$ python3.3 -m timeit -s "from decimal import Decimal" \ > -s "x = Decimal('123.4567')" "x**6" 1000000 loops, best of 3: 1.41 usec per loop That's a factor of 1.2 times slower for Unicode versus 4.1 for Decimal. I think that's *fast enough* for all but the most heavy numeric needs, but it's not something we can ignore. > But a stronger argument is that > the default string should be the one that does the right thing with > text. As of Python 3, that's the case. And the default integer type > handles arbitrary sized integers (although Py2 went most of the way > there by having automatic promotion). It's reasonable to suggest that > the default non-integer numeric type should also simply do the right > thing. Define "the right thing" for numbers. > It's a trade-off, though, and for most people, float is sufficient. That's a tricky one. For people doing quote-unquote "serious" numeric work, they'll mostly want to stick to binary floats, even if that means missing out on all the extra IEEE-754 goodies that the decimal module has but floats don't. The momentum of 40+ years of almost entirely binary floating point maths does not shift to decimal overnight. But for everyone else, binary floats are sufficient except when they aren't. Decimal, of course, won't solve all you floating point difficulties -- it's easy to demonstrate that nearly all the common pitfalls of FP maths also occurs with Decimal, with the exception of inexact conversion from decimal strings to numbers. But that one issue alone is a major cause of confusion. My personal feeling is that for Python 4000 I'd vote for the default floating point format to be decimal, with binary floats available with a b suffix. But since that could be a decade away, it's quite premature to spend too much time on this. -- Steven From python at mrabarnett.plus.com Tue Mar 4 03:10:29 2014 From: python at mrabarnett.plus.com (MRAB) Date: Tue, 04 Mar 2014 02:10:29 +0000 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <20140304015516.GM28804@ando> References: <20140303175429.GL28804@ando> <20140304015516.GM28804@ando> Message-ID: <53153615.4070304@mrabarnett.plus.com> On 2014-03-04 01:55, Steven D'Aprano wrote: > On Tue, Mar 04, 2014 at 10:42:57AM +1100, Chris Angelico wrote: > >> You could probably make the same performance argument against making >> Unicode the default string datatype. > > I don't think so -- for ASCII strings the performance cost of Unicode is > significantly less than the performance hit for Decimal: > > [steve at ando ~]$ python3.3 -m timeit -s "s = 'abcdef'*1000" "s.upper()" > 100000 loops, best of 3: 8.76 usec per loop > [steve at ando ~]$ python3.3 -m timeit -s "s = b'abcdef'*1000" "s.upper()" > 100000 loops, best of 3: 7.05 usec per loop > > [steve at ando ~]$ python3.3 -m timeit -s "x = 123.4567" "x**6" > 1000000 loops, best of 3: 0.344 usec per loop > [steve at ando ~]$ python3.3 -m timeit -s "from decimal import Decimal" \ >> -s "x = Decimal('123.4567')" "x**6" > 1000000 loops, best of 3: 1.41 usec per loop > > > That's a factor of 1.2 times slower for Unicode versus 4.1 for Decimal. > I think that's *fast enough* for all but the most heavy numeric needs, > but it's not something we can ignore. > > >> But a stronger argument is that >> the default string should be the one that does the right thing with >> text. As of Python 3, that's the case. And the default integer type >> handles arbitrary sized integers (although Py2 went most of the way >> there by having automatic promotion). It's reasonable to suggest that >> the default non-integer numeric type should also simply do the right >> thing. > > Define "the right thing" for numbers. > >> It's a trade-off, though, and for most people, float is sufficient. > > That's a tricky one. For people doing quote-unquote "serious" numeric > work, they'll mostly want to stick to binary floats, even if that means > missing out on all the extra IEEE-754 goodies that the decimal module > has but floats don't. The momentum of 40+ years of almost entirely > binary floating point maths does not shift to decimal overnight. > [snip] Won't people doing quote-unquote "serious" numeric work be using numpy? From mertz at gnosis.cx Tue Mar 4 03:17:18 2014 From: mertz at gnosis.cx (David Mertz) Date: Mon, 3 Mar 2014 18:17:18 -0800 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <20140304001048.22d6442c@fsol> References: <20140303175429.GL28804@ando> <53150810.20507@canterbury.ac.nz> <20140304000122.4f61e287@fsol> <20140304001048.22d6442c@fsol> Message-ID: On Mon, Mar 3, 2014 at 3:10 PM, Antoine Pitrou wrote: > On Mon, 3 Mar 2014 15:07:57 -0800 > David Mertz wrote: > > On Mon, Mar 3, 2014 at 3:01 PM, Antoine Pitrou > wrote: > >> > For the record, int doesn't have a sqrt() method while Decimal has, so > > > if you wanna take the exact square root of a large integer, you'd > better > > > convert it to a Decimal. > > Well, actually, if you want to take the square root of a large integer, > > most times you'll need an irrational number as a value. > > Well, unless you know by construction that your integer is a perfect > square. > Umm... if you construct your integer as a perfect square, wouldn't it be easier just to store the number it is a perfect square of than to work on optimizing the integer sqrt() function? It does make me wonder--although this is definitely not actually python-ideas--whether there is any technique to determine if a number is a perfect square that takes less work than finding its integral root. Maybe so, I don't know very much number theory. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From musicdenotation at gmail.com Tue Mar 4 04:39:27 2014 From: musicdenotation at gmail.com (Brian Nguyen) Date: Tue, 4 Mar 2014 10:39:27 +0700 Subject: [Python-ideas] Local scope for statement blocks Message-ID: do: nonlocal x k = init for i in list: k = f(i,k) n = f2(n,k) From rosuav at gmail.com Tue Mar 4 04:40:00 2014 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 4 Mar 2014 14:40:00 +1100 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <20140304015516.GM28804@ando> References: <20140303175429.GL28804@ando> <20140304015516.GM28804@ando> Message-ID: On Tue, Mar 4, 2014 at 12:55 PM, Steven D'Aprano wrote: > On Tue, Mar 04, 2014 at 10:42:57AM +1100, Chris Angelico wrote: > >> You could probably make the same performance argument against making >> Unicode the default string datatype. > > I don't think so -- for ASCII strings the performance cost of Unicode is > significantly less than the performance hit for Decimal: > > [steve at ando ~]$ python3.3 -m timeit -s "s = 'abcdef'*1000" "s.upper()" > 100000 loops, best of 3: 8.76 usec per loop > [steve at ando ~]$ python3.3 -m timeit -s "s = b'abcdef'*1000" "s.upper()" > 100000 loops, best of 3: 7.05 usec per loop > > [steve at ando ~]$ python3.3 -m timeit -s "x = 123.4567" "x**6" > 1000000 loops, best of 3: 0.344 usec per loop > [steve at ando ~]$ python3.3 -m timeit -s "from decimal import Decimal" \ >> -s "x = Decimal('123.4567')" "x**6" > 1000000 loops, best of 3: 1.41 usec per loop > > > That's a factor of 1.2 times slower for Unicode versus 4.1 for Decimal. > I think that's *fast enough* for all but the most heavy numeric needs, > but it's not something we can ignore. There is a difference of degree, yes, but Unicode-strings-as-default has had a few versions to settle in, so the figures mightn't be perfectly fair. But there's still a difference. My point is that Python should be choosing what's right over what's fast, so there's a parallel there. >> It's reasonable to suggest that >> the default non-integer numeric type should also simply do the right >> thing. > > Define "the right thing" for numbers. Yeah, and that's the issue. In this case, since computers don't have infinite computational power, "the right thing" is going to be fairly vague, but I'd define it heuristically as "what the average programmer is most likely to expect". IEEE 754 defines operations on infinity in a way that makes them do exactly what you'd expect. If that's not possible, nan. >>> inf=float("inf") >>> inf+5 inf >>> 5-inf -inf >>> 5/inf 0.0 >>> inf-inf nan A default decimal type would add to the "doing exactly what you expect" operations the obvious one of constructing an object from a series of decimal digits. If you say "0.1", you get the real number 1/10, not 3602879701896397/36028797018963968. > My personal feeling is that for Python 4000 I'd vote for the default > floating point format to be decimal, with binary floats available with a > b suffix. Quite possibly. But changing defaults is a hugely backward-incompatible change, while adding a decimal literal syntax isn't. I'd be in favour of adding decimal literals and using performance and usefulness data from that to guide any discussions about Py4K changing the default. And learn from Py3K and keep both the b and d suffixes supported in the new version :) ChrisA From rosuav at gmail.com Tue Mar 4 04:52:49 2014 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 4 Mar 2014 14:52:49 +1100 Subject: [Python-ideas] Local scope for statement blocks In-Reply-To: References: Message-ID: On Tue, Mar 4, 2014 at 2:39 PM, Brian Nguyen wrote: > do: > nonlocal x > k = init > for i in list: > k = f(i,k) > n = f2(n,k) You may need to elaborate a bit, especially as you have a declaration regarding 'x' and never use x anywhere. But if, as I suspect, you intend for this to have local k/i/n and fetch init/list/f/f2 from its parent scope, then this is something that's been discussed a few times. With the current implementation of CPython, the easiest and cleanest way to do this is with a closure. You could spell 'do' like this: def do(f): f() @do def _(): nonlocal x k = init for i in list: k = f(i,k) n = f2(n,k) Put that inside a function and it'll do most of what I think you're saying. ChrisA From aquavitae69 at gmail.com Tue Mar 4 07:02:46 2014 From: aquavitae69 at gmail.com (David Townshend) Date: Tue, 4 Mar 2014 08:02:46 +0200 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <20140301034611.GD28804@ando> References: <20140301034611.GD28804@ando> Message-ID: On 1 Mar 2014 05:46, "Steven D'Aprano" wrote: > > On Fri, Feb 28, 2014 at 11:17:18AM -0600, Ron Adam wrote: > > > > Starting new thread because this bike has a different shape and color. > > > > Yesterday I was thinking that just making the keyword lambda assignable > > like True, False, and None, would be enough. > > You can't assign to True, False or None. (You can assign to True and > False in Python 2, but shouldn't.) > > > [...] > > This morning I thought we could have in a functions definition something, > > like "*", and "**", to take an expression. Similar to Nicks idea with =:, > > but more general. > > > > The idea is to have "***" used in def mean to take "any" call expression > > and not evaluate it until *** is used on it. > [...] > > A function call that captures an expression may be tricky to do. Here's one > > approach that requires sugar when a function defined with "***" is called. > > I think it would be useful to have a way to delay execution of an > expression, that is to say, have a way to capture an expression for > later evaluation, something more lightweight than a function, but I > don't think that limiting it to inside function calls is the right > approach. > > Something perhaps like a thunk might be appropriate? We can *almost* do > that now, since Python has a compile function: > > thunk = compile("x + 3", "", "eval") > # much later > eval(thunk) What about a new code literal object, e.g. thunk = c'x + 3' thunk(x=2) The "c" prefix identifies the literal as an code so highlighters can recognise it and it can be parsed. Triple quotes could also be used to support multiline code blocks. It would also be possible to prohibit any direct conversion from a string to avoid the security problems. I'm not sure how positional arguments would be handled though, and scoping still needs to be thought through. > > Some problems with that approach: > > - You have to write the expression as a string, which means you lose any > possibility of syntax highlighting. > > - The temptation is to pass some arbitrary untrusted string, which leads > to serious security implications. The argument here should be limited > to an actual expression, not a string containing an expression which > might have come from who knows where. > > - It should be as lightweight as possible. The actual compilation of the > expression should occur at compile-time, not run-time. That implies some > sort of syntax for making thunks, rather than a function call. > > - Likewise actually evaluating the thunk should be really lightweight, > which may rule out a function call to eval. > > - How should scoping work? I can see use-cases for flat scoping, static > scoping, dynamic scoping, and the ability to optionally provide custom > globals and locals, but I have no idea how practical any of them would > be or what syntax they should use. > > > All of this is pie-in-the-sky at the moment, and not a serious proposal > for Python 3.5. > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Tue Mar 4 07:51:17 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Mon, 3 Mar 2014 22:51:17 -0800 Subject: [Python-ideas] Local scope for statement blocks In-Reply-To: References: Message-ID: On Mar 3, 2014, at 19:39, Brian Nguyen wrote: > do: > nonlocal x > k = init > for i in list: > k = f(i,k) > n = f2(n,k) You want _every_ compound statement to be a scope, or you just want to add a new one, a "do" statement, and only that new one is a scope? If the latter, i believe you can do this pretty easily with a MacroPy macro (which will expand to a def and a function call). It might be worth playing with that to get some real-life examples of using it. From abarnert at yahoo.com Tue Mar 4 08:03:03 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Mon, 3 Mar 2014 23:03:03 -0800 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: <20140301034611.GD28804@ando> Message-ID: <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> On Mar 3, 2014, at 22:02, David Townshend wrote: > What about a new code literal object, e.g. > > thunk = c'x + 3' > thunk(x=2) > Why does it need to be built from/look like a string? I think it would be just as simple for the parser, and simpler for editors, and less misleading for readers, if it used a different marker. Not that I'm seriously suggesting backticks here, but... thunk = `x + 3` Most existing editors already treat that as an expression (since in 2.x it means repr(x + 3)). No human reader is going to be misled into thinking this means there's a way to create code objects from string objects without eval (c.f. all those questions on StackOverflow about how to make a raw string from a string...). And as far as the parser is concerned, it's trivial: '`' expr '`' is a Code whose value is whatever expr parses to. Meanwhile, if this gives you a code object, what do you do with it? Using eval on something that looks like a string but isn't may be correct to anyone who understands Python deeply, but I think it could be very misleading to anyone else. And creating a FunctionType from a code object is pretty ugly for something that deserved literal support... > Triple quotes could also be used to support multiline code blocks. > That is one advantage of reusing strings. In fact, that gives us a way to embed statements in the middle of expressions. Which I'm not sure is a good thing. > I'm not sure how positional arguments would be handled though, and scoping still needs to be thought through. > If you have a code object, scoping is up to whoever evaluates it or builds a function out of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce at leapyear.org Tue Mar 4 08:26:13 2014 From: bruce at leapyear.org (Bruce Leban) Date: Mon, 3 Mar 2014 23:26:13 -0800 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> Message-ID: On Mar 3, 2014, at 22:02, David Townshend wrote: > > What about a new code literal object, e.g. > > thunk = c'x + 3' > thunk(x=2) > > This already exists. thunk = lambda: x + 3 thunk(x=2) Your original post in this thread wanted to allow functions to magically capture their parameters as code (~ call by name) and it's been pointed out that that is incompatible with the way the language is designed and function calls are implemented. Yes, there are languages where the called function gets to tell the caller how to package arguments but Python isn't one of them. Now you seem to have veered in a different direction. I have no idea what problem you are trying to solve. --- Bruce Learn how hackers think: http://j.mp/gruyere-security https://www.linkedin.com/in/bruceleban -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Tue Mar 4 09:01:44 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 4 Mar 2014 08:01:44 +0000 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <53591b02-4790-4746-b6a9-10b43a864eaf@googlegroups.com> References: <53591b02-4790-4746-b6a9-10b43a864eaf@googlegroups.com> Message-ID: On 4 March 2014 01:37, Mark H. Harris wrote: > I released my pdeclib module on PyPI this afternoon (it only took four > hours) but I'll never forget how to do that again ! So if anyone is > interested > in the pdeclib module, it may be installed with pip install pdeclib Regardless of anything else that comes out of this thread, thanks for doing that. Paul From aquavitae69 at gmail.com Tue Mar 4 10:07:28 2014 From: aquavitae69 at gmail.com (David Townshend) Date: Tue, 4 Mar 2014 11:07:28 +0200 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> Message-ID: On Tue, Mar 4, 2014 at 9:26 AM, Bruce Leban wrote: > > > On Mar 3, 2014, at 22:02, David Townshend wrote: >> >> What about a new code literal object, e.g. >> >> thunk = c'x + 3' >> thunk(x=2) >> >> This already exists. > > thunk = lambda: x + 3 > thunk(x=2) > > Your original post in this thread wanted to allow functions to magically > capture their parameters as code (~ call by name) and it's been pointed out > that that is incompatible with the way the language is designed and > function calls are implemented. Yes, there are languages where the called > function gets to tell the caller how to package arguments but Python isn't > one of them. > > Now you seem to have veered in a different direction. I have no idea what > problem you are trying to solve. > > This is my first post in this thread - I don't recall who the OP was, but it wasn't me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aquavitae69 at gmail.com Tue Mar 4 10:03:35 2014 From: aquavitae69 at gmail.com (David Townshend) Date: Tue, 4 Mar 2014 11:03:35 +0200 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> Message-ID: On Tue, Mar 4, 2014 at 9:03 AM, Andrew Barnert wrote: > On Mar 3, 2014, at 22:02, David Townshend wrote: > > What about a new code literal object, e.g. > > thunk = c'x + 3' > thunk(x=2) > > Why does it need to be built from/look like a string? I think it would be > just as simple for the parser, and simpler for editors, and less misleading > for readers, if it used a different marker. > > Not that I'm seriously suggesting backticks here, but... > > thunk = `x + 3` > > The only real reason for it looking like a string is a shortage of symbols. Backticks are off limits, and most other symbols are just plain ugly (e.g. @x + 3@ or $x + 3$) or already in use in a way that could lead to ambiguity (e.g. |x + 3|). String-like quotes seem like a better option than the alternatives. > Most existing editors already treat that as an expression (since in 2.x it > means repr(x + 3)). No human reader is going to be misled into thinking > this means there's a way to create code objects from string objects without > eval (c.f. all those questions on StackOverflow about how to make a raw > string from a string...). And as far as the parser is concerned, it's > trivial: '`' expr '`' is a Code whose value is whatever expr parses to. > > Meanwhile, if this gives you a code object, what do you do with it? Using > eval on something that looks like a string but isn't may be correct to > anyone who understands Python deeply, but I think it could be very > misleading to anyone else. And creating a FunctionType from a code object > is pretty ugly for something that deserved literal support... > My suggestion was to use c'x + 3' as an effective replacement for compile('x + 3', '', 'eval'). The use of a literal rather than compile would solve a few of the issues raised in Steven's original post. I don't see why it would be any more misleading to eval a code literal than a compiled string. I did suggest making it callable (i.e. thunk(x=3), but on second thoughts I'm not sure that's a good idea. It adds complexity without and real benefit over eval. > Triple quotes could also be used to support multiline code blocks. > > That is one advantage of reusing strings. In fact, that gives us a way to > embed statements in the middle of expressions. Which I'm not sure is a good > thing. > > I'm not sure how positional arguments would be handled though, and scoping > still needs to be thought through. > > If you have a code object, scoping is up to whoever evaluates it or builds > a function out of it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Tue Mar 4 10:18:13 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 04 Mar 2014 22:18:13 +1300 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <20140304001048.22d6442c@fsol> References: <20140303175429.GL28804@ando> <53150810.20507@canterbury.ac.nz> <20140304000122.4f61e287@fsol> <20140304001048.22d6442c@fsol> Message-ID: <53159A55.9070905@canterbury.ac.nz> Antoine Pitrou wrote: > Well, unless you know by construction that your integer is a perfect > square. If you've constructed it that way, you probably already know its square root. -- Greg From abarnert at yahoo.com Tue Mar 4 11:57:57 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Tue, 4 Mar 2014 02:57:57 -0800 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <53159A55.9070905@canterbury.ac.nz> References: <20140303175429.GL28804@ando> <53150810.20507@canterbury.ac.nz> <20140304000122.4f61e287@fsol> <20140304001048.22d6442c@fsol> <53159A55.9070905@canterbury.ac.nz> Message-ID: <3E61C95D-A73F-4E88-8E2D-5054D9D58935@yahoo.com> On Mar 4, 2014, at 1:18, Greg Ewing wrote: > Antoine Pitrou wrote: >> Well, unless you know by construction that your integer is a perfect >> square. > > If you've constructed it that way, you probably already > know its square root. Usually, but not always. For example, there are algorithms to generate squares of Pythagorean triples without generating the triples themselves. Of course there are simpler and more efficient algorithms to just generate the triples (can't get much simpler than Euclid's formula...), but there might be some reason you're using one of the square algorithms. And then, to test it, you'd need to verify that a2+b2==c2 and that all three of them are perfect squares. From steve at pearwood.info Tue Mar 4 12:09:21 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 4 Mar 2014 22:09:21 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> Message-ID: <20140304110921.GP28804@ando> On Mon, Mar 03, 2014 at 11:03:03PM -0800, Andrew Barnert wrote: > On Mar 3, 2014, at 22:02, David Townshend wrote: > > What about a new code literal object, e.g. > > > > thunk = c'x + 3' Off the top of my head, I think that looks alright. > > thunk(x=2) I'm not entirely sure about that. That basically makes these thunks just a function. I'm still not quite sure how this should actually be used in practice, so as far as I'm concerned this is just pie in the sky thinking aloud. If thunks are just functions, why not make them functions? There needs to be something extra (different scoping rules, faster/more lightweight, *something*) to make the idea worthwhile. I think I need to learn more about Algol and other languages that use call-by-name and thunks. I may be completely on a wild-goose chase here, but I'm surely not the only person who has needed to delay evaluation of an expression. http://en.wikipedia.org/wiki/Thunk > Why does it need to be built from/look like a string? I think it would > be just as simple for the parser, and simpler for editors, and less > misleading for readers, if it used a different marker. > > Not that I'm seriously suggesting backticks here, but... > > thunk = `x + 3` Actually I'd be happy with backticks, but Guido has said No Backticks Ever Again. So until the Glorious Revolution, we're stuck. > Meanwhile, if this gives you a code object, what do you do with it? > Using eval on something that looks like a string but isn't may be > correct to anyone who understands Python deeply, but I think it could > be very misleading to anyone else. And creating a FunctionType from a > code object is pretty ugly for something that deserved literal > support... Agreed. What I have in my head is some vague concept that the Python evaluation rules will somehow know when to evaluate the thunk and when to treat it as an object, which is (as I understand it) what happens in Algol. Again, just thinking aloud, perhaps we do this: thunk = `some_expression` # delays evaluation a = [0, 1 + thunk] # evaluates thunk in the current scope b = [0, `1 + thunk`] # delays evaluation and creates a thunk object # equivalent to `1 + some_expression` c = b[1] # now evaluates the thunk object d = f(2, thunk) # evaluates thunk in f's scope e = g(3, `thunk`) # passes the un-evaluated thunk object to g Consider this just a sketch, and in no way fully thought out. (This will most definitely need a PEP.) > > Triple quotes could also be used to support multiline code blocks. > > > That is one advantage of reusing strings. In fact, that gives us a way > to embed statements in the middle of expressions. Which I'm not sure > is a good thing. I have little interest in allowing thunks to be statements. If you want a delayed statement, use compile and eval. Or def. (But maybe that applies to expressions too?) Did I mention this needs a PEP? -- Steven From steve at pearwood.info Tue Mar 4 12:23:20 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 4 Mar 2014 22:23:20 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> Message-ID: <20140304112320.GQ28804@ando> On Tue, Mar 04, 2014 at 11:03:35AM +0200, David Townshend wrote: > My suggestion was to use c'x + 3' as an effective replacement for > compile('x + 3', '', 'eval'). The use of a literal rather than compile > would solve a few of the issues raised in Steven's original post. I don't > see why it would be any more misleading to eval a code literal than a > compiled string. Agreed. > I did suggest making it callable (i.e. thunk(x=3), but on > second thoughts I'm not sure that's a good idea. It adds complexity > without and real benefit over eval. I don't think calling the thunk is the right API. If we have this sort of functionality, I want calling a thunk to be treated like any other expression, thunk[0] or thunk+1. I don't want it to mean "evaluate this thunk". An example: thunk = `lambda x: x + y` def func(y, obj): return obj + 1 result = func(50, thunk(100)) (This is not a use-case, just an illustration.) In this example, the expression "thunk(1000)" is delayed until inside the func scope. Inside that scope, we evaluate this expression: (lambda x: x + y)(100) where y has the value 50, and bind the result of this to the name obj. The lambda part returns a closure, and calling that closure with argument 100 returns 150, so this is equivalent to binding obj=150. Then func continues, evaluates "obj + 1", and returns 151. -- Steven From steve at pearwood.info Tue Mar 4 12:25:35 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 4 Mar 2014 22:25:35 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <20140304110921.GP28804@ando> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> Message-ID: <20140304112535.GR28804@ando> On Tue, Mar 04, 2014 at 10:09:21PM +1100, Steven D'Aprano wrote: > Agreed. What I have in my head is some vague concept that the Python > evaluation rules will somehow know when to evaluate the thunk and when > to treat it as an object, which is (as I understand it) what happens in > Algol. Since Algol is not an OOP language, that would be "value", not "object". -- Steven From rosuav at gmail.com Tue Mar 4 13:07:46 2014 From: rosuav at gmail.com (Chris Angelico) Date: Tue, 4 Mar 2014 23:07:46 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <20140304110921.GP28804@ando> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> Message-ID: On Tue, Mar 4, 2014 at 10:09 PM, Steven D'Aprano wrote: > Agreed. What I have in my head is some vague concept that the Python > evaluation rules will somehow know when to evaluate the thunk and when > to treat it as an object, which is (as I understand it) what happens in > Algol. Again, just thinking aloud, perhaps we do this: > > thunk = `some_expression` # delays evaluation > a = [0, 1 + thunk] # evaluates thunk in the current scope > b = [0, `1 + thunk`] # delays evaluation and creates a thunk object > # equivalent to `1 + some_expression` > c = b[1] # now evaluates the thunk object > d = f(2, thunk) # evaluates thunk in f's scope > e = g(3, `thunk`) # passes the un-evaluated thunk object to g > > Consider this just a sketch, and in no way fully thought out. > > (This will most definitely need a PEP.) PEP can come later. First, let's get some solid use-cases, and start looking at implications. The way it's described here, there's effectively magic when you try to look at an object of this type, which will break a lot of assumptions. Most people expect that: foo = bar assert foo is bar to be a safe assumption, but if bar is a thunk, then it's getting evaluated separately in each of those, and that's potentially going to create different objects and/or even have side effects. That's going to surprise people. On the flip side, that's something that could be dealt with with a naming convention for thunks. We have _private, __mangled, __magic__, anticollision_, CONSTANT, Class... maybe we could have thunk__ or something. It's most confusable with magic and anticollision, but since both of those are connected with specific keywords, it's reasonably likely there'll be no actual confusion. Specific downside: There's no way to actually pass an unevaluated thunk around. Technically, `thunk__` will create a new wrapper thunk and pass that along. That'll often have the same effect, but it won't be quite identical (same as there's a difference between f(g) and f(lambda x: g(x)) in that the second one lazily looks up g), so that might cause confusion. But you could always special-case it: writing `thunk__` will be guaranteed to transmit the thunk unchanged, and if you actually mean to add another wrapper layer, use `(thunk__)` or something instead. The biggest thing to figure out is scoping. Does a thunk take a snapshot of its enclosing scope (a closure), or is it an expression that gets evaluated in the target namespace? The latter could be extremely confusing, but the former's just what a nested function does, so this'd just be a new lambda syntax. Python's existing lambda syntax has its flaws and its detractors, but it has one huge benefit over thunking: It exists. :) Thunking has to get over that difference. I'd like to see some proposals. ChrisA From masklinn at masklinn.net Tue Mar 4 13:50:19 2014 From: masklinn at masklinn.net (Masklinn) Date: Tue, 4 Mar 2014 13:50:19 +0100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> Message-ID: <931BAA6E-74DB-4997-8307-401D24B1CADF@masklinn.net> On 2014-03-04, at 13:07 , Chris Angelico wrote: > On Tue, Mar 4, 2014 at 10:09 PM, Steven D'Aprano wrote: >> Agreed. What I have in my head is some vague concept that the Python >> evaluation rules will somehow know when to evaluate the thunk and when >> to treat it as an object, which is (as I understand it) what happens in >> Algol. Again, just thinking aloud, perhaps we do this: >> >> thunk = `some_expression` # delays evaluation >> a = [0, 1 + thunk] # evaluates thunk in the current scope >> b = [0, `1 + thunk`] # delays evaluation and creates a thunk object >> # equivalent to `1 + some_expression` >> c = b[1] # now evaluates the thunk object >> d = f(2, thunk) # evaluates thunk in f's scope >> e = g(3, `thunk`) # passes the un-evaluated thunk object to g >> >> Consider this just a sketch, and in no way fully thought out. >> >> (This will most definitely need a PEP.) > > PEP can come later. First, let's get some solid use-cases, and start > looking at implications. The way it's described here, there's > effectively magic when you try to look at an object of this type, > which will break a lot of assumptions. Most people expect that: > > foo = bar > assert foo is bar > > to be a safe assumption, but if bar is a thunk, then it's getting > evaluated separately in each of those Why? Either it's forced during assignment or both names map to the same thunk, and are both forced when any of them is. That could be during the identity check, but since both names refer to the same thunk they can only yield the same value, so the identity check needs not force the thunk. An equality test would likely force the thunk. > so that > might cause confusion. But you could always special-case it: writing > `thunk__` will be guaranteed to transmit the thunk unchanged, and if > you actually mean to add another wrapper layer, use `(thunk__)` or > something instead. Is there a use case for actually thunking a thunk? > The biggest thing to figure out is scoping. Does a thunk take a > snapshot of its enclosing scope (a closure), or is it an expression > that gets evaluated in the target namespace? The latter could be > extremely confusing, but the former's just what a nested function > does, so this'd just be a new lambda syntax. That is essentially what a thunk is, at least in my experience: it is conceptually a nullary memoized function, forced (evaluated/called) if an actual value/object is ever needed but potentially thrown out during reduction. The difference, under the proposed semantics, is that the forcing of the thunk would be implicit where that of a function is explicit (not sure that's a good idea in a strict language). From python at mrabarnett.plus.com Tue Mar 4 14:30:32 2014 From: python at mrabarnett.plus.com (MRAB) Date: Tue, 04 Mar 2014 13:30:32 +0000 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> Message-ID: <5315D578.3040803@mrabarnett.plus.com> On 2014-03-04 09:03, David Townshend wrote: > > > > On Tue, Mar 4, 2014 at 9:03 AM, Andrew Barnert > wrote: > > On Mar 3, 2014, at 22:02, David Townshend > wrote: >> >> What about a new code literal object, e.g. >> >> thunk = c'x + 3' >> thunk(x=2) >> > Why does it need to be built from/look like a string? I think it > would be just as simple for the parser, and simpler for editors, and > less misleading for readers, if it used a different marker. > > Not that I'm seriously suggesting backticks here, but... > > thunk = `x + 3` > > > The only real reason for it looking like a string is a shortage of > symbols. Backticks are off limits, and most other symbols are just > plain ugly (e.g. @x + 3@ or $x + 3$) or already in use in a way that > could lead to ambiguity (e.g. |x + 3|). String-like quotes seem like a > better option than the alternatives. > [snip] I'm sure that Unicode could provide some characters/codepoints. For example: thunk = ?x + 3? From rosuav at gmail.com Tue Mar 4 15:14:09 2014 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 5 Mar 2014 01:14:09 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <931BAA6E-74DB-4997-8307-401D24B1CADF@masklinn.net> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <931BAA6E-74DB-4997-8307-401D24B1CADF@masklinn.net> Message-ID: On Tue, Mar 4, 2014 at 11:50 PM, Masklinn wrote: > On 2014-03-04, at 13:07 , Chris Angelico wrote: >> Most people expect that: >> >> foo = bar >> assert foo is bar >> >> to be a safe assumption, but if bar is a thunk, then it's getting >> evaluated separately in each of those > > Why? Either it's forced during assignment or both names map to > the same thunk, and are both forced when any of them is. > > That could be during the identity check, but since both names refer to > the same thunk they can only yield the same value, so the identity check > needs not force the thunk. An equality test would likely force the > thunk. Most certainly not. Try this: bar = `[1,2,3]` foo = bar spam = bar assert foo is spam Here's the evaluated version: foo = [1,2,3] spam = [1,2,3] assert foo is spam You can try this one out directly. They're not going to be the same object - they'll be two separate lists. They will be equal, in this case, but there's no guarantee of that either: bar = `random.random()` Separate evaluation of the same expression isn't guaranteed to have the same result, AND it might have unexpected side effects: bar = `whiskey.pop().drink()` and you might find yourself underneath the bar before you know it. ChrisA From masklinn at masklinn.net Tue Mar 4 15:55:37 2014 From: masklinn at masklinn.net (Masklinn) Date: Tue, 4 Mar 2014 15:55:37 +0100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <931BAA6E-74DB-4997-8307-401D24B1CADF@masklinn.net> Message-ID: <41D7DF2D-67B2-438D-A064-97003C595E7D@masklinn.net> On 2014-03-04, at 15:14 , Chris Angelico wrote: > On Tue, Mar 4, 2014 at 11:50 PM, Masklinn wrote: >> On 2014-03-04, at 13:07 , Chris Angelico wrote: >>> Most people expect that: >>> >>> foo = bar >>> assert foo is bar >>> >>> to be a safe assumption, but if bar is a thunk, then it's getting >>> evaluated separately in each of those >> >> Why? Either it's forced during assignment or both names map to >> the same thunk, and are both forced when any of them is. >> >> That could be during the identity check, but since both names refer to >> the same thunk they can only yield the same value, so the identity check >> needs not force the thunk. An equality test would likely force the >> thunk. > > Most certainly not. Try this: > > bar = `[1,2,3]` > foo = bar > spam = bar > assert foo is spam > > Here's the evaluated version: > > foo = [1,2,3] > spam = [1,2,3] > assert foo is spam I don't agree with this, again why would the thunk be evaluated twice? If thunks are added to *delay* expression evaluation (which is what I understood from Steven's messages) surely something akin to Haskell's semantics is simpler to understand and implement. That is, instead of thunks being sugar for: bar = lambda: expr they're sugar for bar = memoize(lambda: expr) > You can try this one out directly. They're not going to be the same > object - they'll be two separate lists. They will be equal, in this > case, but there's no guarantee of that either: > > bar = `random.random()` > > Separate evaluation of the same expression isn't guaranteed to have > the same result Obviously, but why would repeated evaluation of the expression be desirable? > AND it might have unexpected side effects: > > bar = `whiskey.pop().drink()` > > and you might find yourself underneath the bar before you know it. From rosuav at gmail.com Tue Mar 4 16:11:42 2014 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 5 Mar 2014 02:11:42 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <41D7DF2D-67B2-438D-A064-97003C595E7D@masklinn.net> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <931BAA6E-74DB-4997-8307-401D24B1CADF@masklinn.net> <41D7DF2D-67B2-438D-A064-97003C595E7D@masklinn.net> Message-ID: On Wed, Mar 5, 2014 at 1:55 AM, Masklinn wrote: > I don't agree with this, again why would the thunk be evaluated twice? > If thunks are added to *delay* expression evaluation (which is what I > understood from Steven's messages) surely something akin to Haskell's > semantics is simpler to understand and implement. That is, instead > of thunks being sugar for: > > bar = lambda: expr > > they're sugar for > > bar = memoize(lambda: expr) Okay. That's an interesting point, and a distinction from lambda. Effectively, once a thunk is evaluated once, it devolves to its value. That would be *extremely* interesting in the case of lazy evaluation - you could actually make a ternary-if function: value = true_expr if cond else false_expr def if_(cond, true_thunk, false_thunk): if cond: return true_thunk return false_thunk value = if_(cond, `true_expr`, `false_expr`) There's still the questions of scoping, but now you have the distinction between a thunk and a function. And if it's at all possible, the thunk could even replace itself in memory with its result - that would be massively implementation-dependent, but since you can't look at the identity of the thunk itself anyway, it wouldn't break anything. Effectively, as soon as you evaluate bar, it assigns to bar whatever the expression evaluates to. (Which is simpler and cleaner to explain than the memoization.) ChrisA From steve at pearwood.info Tue Mar 4 16:19:59 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 5 Mar 2014 02:19:59 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <41D7DF2D-67B2-438D-A064-97003C595E7D@masklinn.net> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <931BAA6E-74DB-4997-8307-401D24B1CADF@masklinn.net> <41D7DF2D-67B2-438D-A064-97003C595E7D@masklinn.net> Message-ID: <20140304151958.GS28804@ando> On Tue, Mar 04, 2014 at 03:55:37PM +0100, Masklinn wrote: > I don't agree with this, again why would the thunk be evaluated twice? > If thunks are added to *delay* expression evaluation (which is what I > understood from Steven's messages) surely something akin to Haskell's > semantics is simpler to understand and implement. That is, instead > of thunks being sugar for: > > bar = lambda: expr > > they're sugar for > > bar = memoize(lambda: expr) +1 -- Steven From guido at python.org Tue Mar 4 18:20:20 2014 From: guido at python.org (Guido van Rossum) Date: Tue, 4 Mar 2014 09:20:20 -0800 Subject: [Python-ideas] PEP-257: drop recommendation for extra line at end of multi-line docstring In-Reply-To: <2d6d1d67-bf89-4b33-acfe-4db2bd5e28e3@googlegroups.com> References: <30E13F8A-EE63-4E0F-A29A-F35B5906791C@rackspace.com> <1FD9DEBB-1E68-4BB0-9349-B3FA2598D627@rackspace.com> <991C04FE-35F2-4641-B240-A353AD31A9E3@rackspace.com> <2d6d1d67-bf89-4b33-acfe-4db2bd5e28e3@googlegroups.com> Message-ID: Removed. On Tue, Mar 4, 2014 at 8:51 AM, Simon Kennedy wrote: > On Monday, 3 March 2014 18:55:17 UTC, Ziad Sawalha wrote: >> >> Thanks, Guido. >> >> I'll follow up with updates to common tools as I come across them (ex. >> pep257: https://github.com/GreenSteam/pep257/pull/64). >> >> Ziad >> >> > The footnote's still in the PEP text. > > --Simon > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Tue Mar 4 23:17:17 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 05 Mar 2014 11:17:17 +1300 Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: <3E61C95D-A73F-4E88-8E2D-5054D9D58935@yahoo.com> References: <20140303175429.GL28804@ando> <53150810.20507@canterbury.ac.nz> <20140304000122.4f61e287@fsol> <20140304001048.22d6442c@fsol> <53159A55.9070905@canterbury.ac.nz> <3E61C95D-A73F-4E88-8E2D-5054D9D58935@yahoo.com> Message-ID: <531650ED.1050206@canterbury.ac.nz> Andrew Barnert wrote: > On Mar 4, 2014, at 1:18, Greg Ewing wrote: > >> If you've constructed it that way, you probably already know its square >> root. > > Usually, but not always. In any case, the fact remains that any algorithm for calculating the square root of a perfect square will work just as well in any base. There's nothing special about decimal in that regard. -- Greg From greg.ewing at canterbury.ac.nz Tue Mar 4 23:31:41 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 05 Mar 2014 11:31:41 +1300 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <20140304110921.GP28804@ando> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> Message-ID: <5316544D.7050302@canterbury.ac.nz> Steven D'Aprano wrote: > What I have in my head is some vague concept that the Python > evaluation rules will somehow know when to evaluate the thunk and when > to treat it as an object, which is (as I understand it) what happens in > Algol. But Algol has the benefit of static typing -- the procedure being called explicitly declares whether the argument is to be passed by name or value. Python has no idea about that at compile time. > b = [0, `1 + thunk`] # delays evaluation and creates a thunk object > # equivalent to `1 + some_expression` > c = b[1] # now evaluates the thunk object > d = f(2, thunk) # evaluates thunk in f's scope > e = g(3, `thunk`) # passes the un-evaluated thunk object to g When exactly does implicit evaluation of a thunk object occur? Does `b[1]` give you an unevaluated thunk object? What if b is a custom sequence type implemented in Python -- how does its __getitem__ method avoid evaluating the thunk object prematurely? None of these problems occur in Algol, because its thunks are not first-class values (you can't store them in arrays, etc.) and it uses static type information to tell when to create and evaluate them. -- Greg From rosuav at gmail.com Tue Mar 4 23:40:09 2014 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 5 Mar 2014 09:40:09 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <5316544D.7050302@canterbury.ac.nz> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> Message-ID: On Wed, Mar 5, 2014 at 9:31 AM, Greg Ewing wrote: > Does `b[1]` give you an unevaluated thunk object? I would say that `b[1]` should create a brand new thunk object of that expression. On evaluation of that, it'll look up b, subscript it, and touch the thunk. When it does, it Schrodingers itself into a value and that's that. In my opinion, __getitem__ isn't a problem, but __setitem__ is. Somewhere along the way, you have to be able to "hold" a thunk as a thunk. I've no idea how that works when you pass it around from function to function. ChrisA From solipsis at pitrou.net Wed Mar 5 00:08:12 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 5 Mar 2014 00:08:12 +0100 Subject: [Python-ideas] Python3.3 Decimal Library Released References: <20140303175429.GL28804@ando> <53150810.20507@canterbury.ac.nz> <20140304000122.4f61e287@fsol> <20140304001048.22d6442c@fsol> <53159A55.9070905@canterbury.ac.nz> <3E61C95D-A73F-4E88-8E2D-5054D9D58935@yahoo.com> <531650ED.1050206@canterbury.ac.nz> Message-ID: <20140305000812.7676feca@fsol> On Wed, 05 Mar 2014 11:17:17 +1300 Greg Ewing wrote: > Andrew Barnert wrote: > > On Mar 4, 2014, at 1:18, Greg Ewing wrote: > > > >> If you've constructed it that way, you probably already know its square > >> root. > > > > Usually, but not always. > > In any case, the fact remains that any algorithm for > calculating the square root of a perfect square will > work just as well in any base. There's nothing special > about decimal in that regard. The point was not decimal vs. binary, but arbitrarily high precision vs. fixed low precision. (i.e. if you have a 1000-digit integer, just calling N ** 0.5 will give you a very low-precision result compared to the integer's precision). Regards Antoine. From carl.input at gmail.com Wed Mar 5 00:09:02 2014 From: carl.input at gmail.com (Carl Smith) Date: Tue, 4 Mar 2014 23:09:02 +0000 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality Message-ID: The tentatively proposed idea here is using dollar signed expressions to define 'bills'. A bill object is essentially an expression which can be evaluated any number of times, potentially in different scopes. The following expression [a bill literal] would be pointless, but would define a bill that always evaluates to 1. $1 So, eval($1)==1. Some better examples... * assign a bill to `a` so that `a` will evaluate to the value of the name `foo` any time that `a` is evaluated, in the scope of that evaluation a = $foo * as above, but always plus one a = $foo + 1 * make `a` a bill that evaluates to the value of the name `foo` at the time that `a` is evaluated, in that scope, plus the value of `bar` **at the time and in the scope of the assignment to `a`** a = $foo + bar Note. Similarly to mixing floats with ints, any expression that contains a bill evaluates to a bill, so if `a` is a bill, `b=a+1` makes `b` a bill too. Passing a bill to eval should be the obvious way to get the value. The point? It allows functions to accept bills to use internally. The function would specify any names the bill can reference in the function's API, like keywords. def f(b): # the bill arg `b` can reference `item` for item in something: if eval(b): return True f($item < 0) You could also use a function call, for example `$foo()` would evaluate to a bill that evaluates to a call to `foo` in the scope and at the time of any evaluation of the bill. I've no idea if this is even possible in Python, and have no hope of implementing it, but thought I'd share :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Wed Mar 5 00:57:31 2014 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Tue, 4 Mar 2014 17:57:31 -0600 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: Only problem is that it looks a tad perlish... On Tue, Mar 4, 2014 at 5:09 PM, Carl Smith wrote: > The tentatively proposed idea here is using dollar signed expressions to > define 'bills'. A bill object is essentially an expression which can be > evaluated any number of times, potentially in different scopes. > > The following expression [a bill literal] would be pointless, but would > define a bill that always evaluates to 1. > > $1 > > So, eval($1)==1. > > Some better examples... > > * assign a bill to `a` so that `a` will evaluate to the value of the name > `foo` any time that `a` is evaluated, in the scope of that evaluation > > a = $foo > > * as above, but always plus one > > a = $foo + 1 > > * make `a` a bill that evaluates to the value of the name `foo` at the > time that `a` is evaluated, in that scope, plus the value of `bar` **at the > time and in the scope of the assignment to `a`** > > a = $foo + bar > > Note. Similarly to mixing floats with ints, any expression that contains a > bill evaluates to a bill, so if `a` is a bill, `b=a+1` makes `b` a bill > too. Passing a bill to eval should be the obvious way to get the value. > > The point? It allows functions to accept bills to use internally. The > function would specify any names the bill can reference in the function's > API, like keywords. > > def f(b): # the bill arg `b` can reference `item` > for item in something: > if eval(b): return True > > f($item < 0) > > You could also use a function call, for example `$foo()` would evaluate to > a bill that evaluates to a call to `foo` in the scope and at the time of > any evaluation of the bill. > > I've no idea if this is even possible in Python, and have no hope of > implementing it, but thought I'd share :) > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." -------------- next part -------------- An HTML attachment was scrubbed... URL: From cs at zip.com.au Wed Mar 5 01:06:10 2014 From: cs at zip.com.au (Cameron Simpson) Date: Wed, 5 Mar 2014 11:06:10 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: <20140305000610.GA3326@cskk.homeip.net> On 04Mar2014 17:57, Ryan Gonzalez wrote: > Only problem is that it looks a tad perlish... Of shellish. But worse, does nothing even remotely loke what that does in perl or shell (or basic or...). I was going to remark that in my mind I would always see: a = $foo + 1 and (1) mentally bind the "$" to "foo" alone, not treat it as a prefix to the whole expression and (2) expect "a" to evaluate right now, regardess. And then follow up that remark with a strong preference for forming the who expression inside a clear construct so you know at the outself that it is something for evaluation later. And then realised that is already spelt "lambda". I do take the point that this "bill" idea is meant to grant access to the local scope when used. Cheers, -- Cameron Simpson Take a perfectly parallel uniform plank of constant density. Balance it exactly at its centre on a frictionnless pivot. Place the hog at a known distance from this pivot. Now add stones on the other end at exactly the same distance until the plank is perfectly horizontal as measured by a precision tiltmeter. Now guess the weight of the stones. - Bob Newhart on weighing a hog From jbvsmo at gmail.com Wed Mar 5 02:05:57 2014 From: jbvsmo at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Bernardo?=) Date: Tue, 4 Mar 2014 22:05:57 -0300 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: > > * assign a bill to `a` so that `a` will evaluate to the value of the name > `foo` any time that `a` is evaluated, in the scope of that evaluation > > a = $foo > > * as above, but always plus one > > a = $foo + 1 > > * make `a` a bill that evaluates to the value of the name `foo` at the > time that `a` is evaluated, in that scope, plus the value of `bar` **at the > time and in the scope of the assignment to `a`** > > a = $foo + bar > > You can do all that programmatically. No need for magic operators. Check this module as a proof of concept: https://github.com/jbvsmo/funcbuilder foo = FuncBuilder() a = foo + 1 # Then evaluate a with a function call For it to do exactly what you want, you just need override the evaluation function (Funcbuilder.__call__) to load names from current frame locals or something. BTW, I don't recommend using that on real code because it is extremely experimental (unless you're a hipster... In this case, carry on). -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Wed Mar 5 02:05:39 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Tue, 4 Mar 2014 17:05:39 -0800 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <5316544D.7050302@canterbury.ac.nz> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> Message-ID: <6939FECB-867D-46EC-B5D2-737DA205590D@yahoo.com> On Mar 4, 2014, at 14:31, Greg Ewing wrote: > Steven D'Aprano wrote: >> What I have in my head is some vague concept that the Python evaluation rules will somehow know when to evaluate the thunk and when to treat it as an object, which is (as I understand it) what happens in Algol. > > But Algol has the benefit of static typing -- the procedure > being called explicitly declares whether the argument is to > be passed by name or value. Python has no idea about that at > compile time. This is the main reason I think it's more productive to think of this in terms of Lisp-style quoting than Algol-style thunks. The fact that quoting/thunking gives you a code object instead of an AST (sexpr) is not significant here* (unless we're also considering adding macros). The fact that it gives you a first-class value, and that we can't use the "implicit casting" syntax that comes with static typing to magically evaluate the object at the right time, is critical. This is basically the same problem I described trying to implement Boost-style auto lambdas in Python without C++-style implicit cast from lambda to function. * It is significant _elsewhere_. In an AST, "b" is just a reference to a name; in a code object, we have to have already determined whether it's a reference to a fast, closure, or global name--unless you want to do something like automatically compile `b[1]` as if it were something like vars('b')[1], or to do something equivalent like add a LOAD_DYNAMIC opcode. >> b = [0, `1 + thunk`] # delays evaluation and creates a thunk object >> # equivalent to `1 + some_expression` >> c = b[1] # now evaluates the thunk object >> d = f(2, thunk) # evaluates thunk in f's scope >> e = g(3, `thunk`) # passes the un-evaluated thunk object to g There's really no way to cleanly distinguish the c, d, and e cases. There are really only two possibilities: Magic evaluation everywhere (so d is passing in eval(thunk) to f), or explicit evaluation (whether via eval or otherwise) only (so c is just binding the unevaluated thunk). I think either of those is potentially viable, but I don't think there's anything in between. Note that you can always quote the implicit evaluation (if you go the first way) or explicitly eval anywhere you want (the second), so neither one really limits what you can do. > When exactly does implicit evaluation of a thunk object occur? > Does `b[1]` give you an unevaluated thunk object? What if b is > a custom sequence type implemented in Python -- how does its > __getitem__ method avoid evaluating the thunk object prematurely? You're creating a new thunk/quoting a new expression inside the backticks, so the issue doesn't arise. You're creating a new code object that looks up b and indexes it. The __getitem__ call doesn't happen until that new code object is evaluated. > None of these problems occur in Algol, because its thunks are > not first-class values (you can't store them in arrays, etc.) > and it uses static type information to tell when to create > and evaluate them. From abarnert at yahoo.com Wed Mar 5 02:16:38 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Tue, 4 Mar 2014 17:16:38 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: <8B8381FA-AC52-4D5A-A01C-285B21E2B5E9@yahoo.com> On Mar 4, 2014, at 17:05, Jo?o Bernardo wrote: >> * assign a bill to `a` so that `a` will evaluate to the value of the name `foo` any time that `a` is evaluated, in the scope of that evaluation >> >> a = $foo >> >> * as above, but always plus one >> >> a = $foo + 1 >> >> * make `a` a bill that evaluates to the value of the name `foo` at the time that `a` is evaluated, in that scope, plus the value of `bar` **at the time and in the scope of the assignment to `a`** >> >> a = $foo + bar > > > You can do all that programmatically. No need for magic operators. > Check this module as a proof of concept: https://github.com/jbvsmo/funcbuilder > > foo = FuncBuilder() > a = foo + 1 > # Then evaluate a with a function call > > For it to do exactly what you want, you just need override the evaluation function (Funcbuilder.__call__) to load names from current frame locals or something. > BTW, I don't recommend using that on real code because it is extremely experimental (unless you're a hipster... In this case, carry on). I posted something similar in the first of the many improving-lambda threads this month, but it had a lot of little problems and one big one. The big one is that not every expression can be caught by operator overloading (foo[i] is fine, but lst[foo] isn't). And call expressions are one of the most important kinds of expression, but you can't catch that--or, rather, if you _do_ catch it, then you have no way to call the resulting object. The same idea in C++ doesn't have that last problem because C++ is statically typed, and you can use an implicit cast from autolambda object to function object to get from an object whose call operator builds a call expression to one whose call operator evaluates the expression. But that doesn't work in Python. I wrote a blog post that gets into this further, but I can't find the link from my phone. I included it in an earlier message in the thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Wed Mar 5 02:23:13 2014 From: mertz at gnosis.cx (David Mertz) Date: Tue, 4 Mar 2014 17:23:13 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <20140305000610.GA3326@cskk.homeip.net> References: <20140305000610.GA3326@cskk.homeip.net> Message-ID: On Tue, Mar 4, 2014 at 4:06 PM, Cameron Simpson wrote: > On 04Mar2014 17:57, Ryan Gonzalez wrote: > > Only problem is that it looks a tad perlish...Of shellish. > > But worse, does nothing even remotely loke what that does in perl > or shell (or basic or...). > > I was going to remark that in my mind I would always see: > > a = $foo + 1 > > and (1) mentally bind the "$" to "foo" alone, not treat it as a > prefix to the whole expression and (2) expect "a" to evaluate right > now, regardess. > I think I could be +0 for a bit different spelling that *is* actually shell-ish. I.e. as a way to handle snippets, this doesn't seem so bad: foo = 1 a = $(foo + 1) b = eval(a) * 6 c = $(foo + a/2) print(c, eval(c)) # 2 print(a + 1) # TypeError, incompatible types for '+' operation, thunk and int That is, the whole "thunk" or really just "code-snippet" could be a shorthand way to refer to a segment of (dynamically scoped, basically) code we might use in different places. It's a lot like Ruby blocks, of course, but the difference is that it's not only in the final position of a call, but anywhere anything might be used or passed. On the other hand, this isn't *really* different from just putting snippets in strings like we can do now. The one difference I envision is that maybe these "thunks" would be completely resolved by an eval(), unlike a string. That is, 'c' is a thunk, but it's a thunk that contains another thunk. So the eval() function becomes a recursive-unthunk. Well, maybe I'm -0 rather than +0. I'm definitely -1 on the "thunks taint all expressions" approach suggested initially, which seems far too magical and implicit. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cs at zip.com.au Wed Mar 5 02:46:11 2014 From: cs at zip.com.au (Cameron Simpson) Date: Wed, 5 Mar 2014 12:46:11 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: <20140305014611.GA4396@cskk.homeip.net> On 04Mar2014 17:23, David Mertz wrote: > On Tue, Mar 4, 2014 at 4:06 PM, Cameron Simpson wrote: > > On 04Mar2014 17:57, Ryan Gonzalez wrote: > > > Only problem is that it looks a tad perlish...Of shellish. > > > > But worse, does nothing even remotely loke what that does in perl > > or shell (or basic or...). [...] > I think I could be +0 for a bit different spelling that *is* actually > shell-ish. I.e. as a way to handle snippets, this doesn't seem so bad: > > foo = 1 > a = $(foo + 1) Definitely nicer. Still irrationally uncomfortable about the "$" though. A thought, though it could break existing code (and nested tuples, alas): a = (( foo + 1 )) Still, what does this mean? a = 3 + (( foo + 1 )) I think that would need to be a syntax error, because I can't see it being anything except nonsense otherwise. That makes me think the (()) or $() is in the wrong place. Maybe: a := foo + 1 Hmm. hasn't that one already come up? > b = eval(a) * 6 This makes me unhappy. Eval parses a string and runs it, currently. I would _want_ to read that as "compute a, then eval() the result". I would prefer the occurence of "a" in an expression to cause it to be evaluated then, much as happens already. It does mean that there would be "silent" evaluation bombs lurking in expressions. For example, given a doubly linked list (to make the "reference" stuff glaring): node.right = node2 node2.left = node If node or node2 were thunks, this would be surprising to the reader. Of course, we can surprise the reader already with __getattr__ etc. But I think it would be better if: b = a just made "b" a reference to the same thunk as "a". Since I'm cavilling about "eval", how about just treating thunks like other functions (which is how we spell code to be run later presently) and have them be callables. So your "b = eval(a) * 6" would just be: b = a() * 6 That way it is glaringly obvious that "a" happens now, rather than earlier. Cheers, -- Cameron Simpson Disease and deprivation stalk the land like two giant.... stalking things. - Rowan Atkinson, _Black Adder the Third_ From mertz at gnosis.cx Wed Mar 5 03:36:40 2014 From: mertz at gnosis.cx (David Mertz) Date: Tue, 4 Mar 2014 18:36:40 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <20140305014611.GA4396@cskk.homeip.net> References: <20140305014611.GA4396@cskk.homeip.net> Message-ID: On Tue, Mar 4, 2014 at 5:46 PM, Cameron Simpson wrote: > > foo = 1 > > a = $(foo + 1) > Definitely nicer. Still irrationally uncomfortable about the "$" though. > A thought, though it could break existing code (and nested tuples, alas): > > a = (( foo + 1 )) > That looks like unresolvable ambiguity to me. I confess that I am more comfortable with '$(...)' because I'm one of those folks who actually likes bash, and uses that spelling often over there (where the meaning isn't the *same* as this, but is enough similar for the meaning to carry over) > Still, what does this mean? > a = 3 + (( foo + 1 )) > I think that would need to be a syntax error, because I can't see it being > anything except nonsense otherwise. > In my example I made it a TypeError on the grounds that a thunk and and int aren't things that can be added together. That makes more sense to me than a SyntaxError, since a thunk is a perfectly good expression (or would be if the feature is added). Besides, you really need to allow thunks in expressions, since sometimes they make sense as values to operate on, e.g. (as I wrote before): print(foo, 'foo', $(foo)) # Using my bash-like syntax # 1 foo You could also, for example, have a type of object that knew how to operate on a thunk with operators: class Thunker(object): def __radd__(self, other): if isinstance(other, thunk): ... return something sensible ... thunker = Thunker() a = thunker + $(foo + bar) > b = eval(a) * 6 > This makes me unhappy. Eval parses a string and runs it, currently. > I would _want_ to read that as "compute a, then eval() the result". > b = a() * 6 I don't think I would want a thunk to be *exactly* a callable. That feels wrong to me. But I can see that overloading the meaning of eval() to operate on either a string or a thunk might feel odd. *Except* that eval() is *already* overloaded in a similar manner: >>> exp = compile("1+2", "", "eval") >>> exp, eval(exp) ( at 0x100730ae0, file "", line 1>, 3) However, what if it was spelled differently from eval(), e.g.: b = unthunk(a) * 6 OK, I don't actually like that name, but you see what I mean that other names are perfectly possible. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Wed Mar 5 03:36:17 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Tue, 4 Mar 2014 18:36:17 -0800 (PST) Subject: [Python-ideas] Python3.3 Decimal Library Released In-Reply-To: References: <53591b02-4790-4746-b6a9-10b43a864eaf@googlegroups.com> Message-ID: <9858a1ce-2062-4460-9b8e-b13ee9f1c388@googlegroups.com> On Tuesday, March 4, 2014 2:01:44 AM UTC-6, Paul Moore wrote: > > Regardless of anything else that comes out of this thread, thanks for > doing that. > Paul > > Thank you, you are most welcome. marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From cs at zip.com.au Wed Mar 5 04:49:45 2014 From: cs at zip.com.au (Cameron Simpson) Date: Wed, 5 Mar 2014 14:49:45 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: <20140305034945.GA67087@cskk.homeip.net> On 04Mar2014 18:36, David Mertz wrote: > On Tue, Mar 4, 2014 at 5:46 PM, Cameron Simpson wrote: > > > foo = 1 > > > a = $(foo + 1) > > Definitely nicer. Still irrationally uncomfortable about the "$" though. > > A thought, though it could break existing code (and nested tuples, alas): > > > > a = (( foo + 1 )) > > That looks like unresolvable ambiguity to me. Me too. > I confess that I am more > comfortable with '$(...)' because I'm one of those folks who actually likes > bash, and uses that spelling often over there (where the meaning isn't the > *same* as this, but is enough similar for the meaning to carry over) I write a lot of shell scripts too. > > Still, what does this mean? > > a = 3 + (( foo + 1 )) > > I think that would need to be a syntax error, because I can't see it being > > anything except nonsense otherwise. > > In my example I made it a TypeError on the grounds that a thunk and and int > aren't things that can be added together. That makes more sense to me than > a SyntaxError, since a thunk is a perfectly good expression (or would be if > the feature is added). > > Besides, you really need to allow thunks in expressions, since sometimes > they make sense as values to operate on, e.g. (as I wrote before): > > print(foo, 'foo', $(foo)) # Using my bash-like syntax > # 1 foo > > You could also, for example, have a type of object that knew how to operate > on a thunk with operators: > > class Thunker(object): > def __radd__(self, other): > if isinstance(other, thunk): > ... return something sensible ... > > thunker = Thunker() > a = thunker + $(foo + bar) Hmm, yes. Ok. We should get TypeErrors for free except where some operator has been designed. > > b = eval(a) * 6 > > This makes me unhappy. Eval parses a string and runs it, currently. > > I would _want_ to read that as "compute a, then eval() the result". > > > b = a() * 6 > > I don't think I would want a thunk to be *exactly* a callable. That feels > wrong to me. Can you be more precise? It seems like exactly what's going on, semanticly. Except that there's no notion of parameters. > But I can see that overloading the meaning of eval() to > operate on either a string or a thunk might feel odd. *Except* that eval() > is *already* overloaded in a similar manner: > > >>> exp = compile("1+2", "", "eval") > >>> exp, eval(exp) > ( at 0x100730ae0, file "", line 1>, 3) Hmm. The lack of params makes eval a better match then. > However, what if it was spelled differently from eval(), e.g.: > > b = unthunk(a) * 6 > > OK, I don't actually like that name, but you see what I mean that other > names are perfectly possible. How about: a.eval() Don't make a new public function, give thunks a method. Are we still intending thunks to be effectively a calling-scope closure? That seems subject to being fragile: you can define a thunk far from where it is called/evaled and therefore keeping it in sync with the user's scope is less solid. Cheers, -- Cameron Simpson Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green. - Snooker commentator 'Whispering' Ted Lowe From harrismh777 at gmail.com Wed Mar 5 04:42:28 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Tue, 4 Mar 2014 19:42:28 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System Message-ID: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> Greetings, The purpose of this idea is to expand a bit on the decimal default idea which I submitted previously. In this idea I want to suggest the human idea of a *python number.* The concept is very simple, yet may have far reaching implications not only for future python(s) but also for the wider adaptation of python in the greater academic and professional communities. The idea of *python number* means that there are no types, no limits, no constraints, and that all *python numbers *are dynamic. The upper level syntax is also very simple; all* python numbers *are simply human. My influence for this preference is rooted in the Rexx programming language; attributed to Mike Cowlishaw, former IBM fellow. The Rexx programming language is dynamic, and has no types. To put it more succinctly for those of you who have not used Rexx, the only data type is a string of characters (that's it). *Rexx numbers* are simply those strings of characters that may be interpreted as a valid *Rexx number.* http://books.google.com/books?id=cNiVqFmPs8AC&pg=PA100&lpg=PA100&dq=rexx+numbers&source=bl&ots=SNv00ARBqU&sig=cbRb2pqCsZpYhIXtGUXTDxmtqkw&hl=en&sa=X&ei=OpQWU-XuPMT70gHhooG4BA&ved=0CDcQ6AEwAQ#v=onepage&q=rexx%20numbers&f=false The Python language might be changed to adopt the *python number* concept for *all math processing*, unless explicitly modified. This goes somewhat beyond using decimal floating point as a default numerical type. It means using human numeric expressions that meet human expectation for numeric processing by default. Under the covers (whatever we mean by that) processing is handled by decimal.Decimal, unless explicitly modified. What does this mean for python users in general? Well, no more worrying about types at all... no ints, no floats, no rationals, no irrationals, no fractions, and certainly no binaries. In short, if its a human number, its a *python number.* I am expecting that (just as in Rexx numbers) defining very clearly what is a *python number* will be key for wide adaptation of the concept. But there should be no surprises for users, particularly average users. Anyone with a middle school expectation of a numeric format should be able to use *python numbers *without surprises. However, for advanced users the full interface should be available (as is the context for Decimal) through coding based on knowledge and experience, yet the default context for Decimal should be based on average users in most environments and use cases. It is my belief that Python should lead the way in the twenty-first century for advanced computation for academic, professional, business, and scientific communities. There is a 40 year momentum for embedded binary floats & doubles, also numeric types generally, but it is time to move forward. The technology is ready, and the need is great. Let's do it. {shameless plug} pdeclib https://pypi.python.org/pypi/pdeclib Thank you for your consideration. Good evening. Mark H Harris marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at mrabarnett.plus.com Wed Mar 5 05:06:38 2014 From: python at mrabarnett.plus.com (MRAB) Date: Wed, 05 Mar 2014 04:06:38 +0000 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <20140305014611.GA4396@cskk.homeip.net> References: <20140305014611.GA4396@cskk.homeip.net> Message-ID: <5316A2CE.2040509@mrabarnett.plus.com> On 2014-03-05 01:46, Cameron Simpson wrote: > On 04Mar2014 17:23, David Mertz wrote: >> On Tue, Mar 4, 2014 at 4:06 PM, Cameron Simpson wrote: >> > On 04Mar2014 17:57, Ryan Gonzalez wrote: >> > > Only problem is that it looks a tad perlish...Of shellish. >> > >> > But worse, does nothing even remotely loke what that does in perl >> > or shell (or basic or...). > [...] >> I think I could be +0 for a bit different spelling that *is* actually >> shell-ish. I.e. as a way to handle snippets, this doesn't seem so bad: >> >> foo = 1 >> a = $(foo + 1) > > Definitely nicer. Still irrationally uncomfortable about the "$" though. > > A thought, though it could break existing code (and nested tuples, alas): > > a = (( foo + 1 )) > That's not a tuple. It's equivalent to: a = foo + 1 [snip] From cs at zip.com.au Wed Mar 5 06:15:34 2014 From: cs at zip.com.au (Cameron Simpson) Date: Wed, 5 Mar 2014 16:15:34 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <5316A2CE.2040509@mrabarnett.plus.com> References: <5316A2CE.2040509@mrabarnett.plus.com> Message-ID: <20140305051534.GA75905@cskk.homeip.net> On 05Mar2014 04:06, MRAB wrote: > On 2014-03-05 01:46, Cameron Simpson wrote: > >> a = $(foo + 1) > > > >Definitely nicer. Still irrationally uncomfortable about the "$" though. > >A thought, though it could break existing code (and nested tuples, alas): > > a = (( foo + 1 )) > > > That's not a tuple. It's equivalent to: > a = foo + 1 I know that. I should have said: though the below looks nice, in more complicated forms it fights with tuples, eg: ((1,2,3),(4,5,6)) (((1,2,3),(4,5,6))) :-( -- Cameron Simpson Theoretical Physicist,N.:A physicist whose existence is postulated, to make the numbers balance but who is never actually observed in the laboratory. From ron3200 at gmail.com Wed Mar 5 06:25:42 2014 From: ron3200 at gmail.com (Ron Adam) Date: Tue, 04 Mar 2014 23:25:42 -0600 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <6939FECB-867D-46EC-B5D2-737DA205590D@yahoo.com> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> <6939FECB-867D-46EC-B5D2-737DA205590D@yahoo.com> Message-ID: On 03/04/2014 07:05 PM, Andrew Barnert wrote: > On Mar 4, 2014, at 14:31, Greg > Ewing wrote: >>> Steven D'Aprano wrote: >>>>> What I have in my head is some vague concept that the Python >>>>> evaluation rules will somehow know when to evaluate the thunk >>>>> and when to treat it as an object, which is (as I understand it) >>>>> what happens in Algol. >>> But Algol has the benefit of static typing -- the procedure being >>> called explicitly declares whether the argument is to be passed by >>> name or value. Python has no idea about that at compile time. > This is the main reason I think it's more productive to think of this in > terms of Lisp-style quoting than Algol-style thunks. The fact that > quoting/thunking gives you a code object instead of an AST (sexpr) is > not significant here* (unless we're also considering adding macros). The > fact that it gives you a first-class value, and that we can't use the > "implicit casting" syntax that comes with static typing to magically > evaluate the object at the right time, is critical. > This is basically the same problem I described trying to implement > Boost-style auto lambdas in Python without C++-style implicit cast from > lambda to function. In a experimental language I'm writing, I use a concept I call "Context Resolution" to resolve objects to expected kinds of objects. The expected type/kind is determined in the context of how things are used together rather than by how they are defined. (That allows everything to be objects). Keywords, Names, Expressions, and CodeBlocks, etc... In python it would probably depend on AttributeError instead of the type. If an object doesn't have the needed attribute, then it could try calling a different method, possibly __resolve__. Then retry the attribute lookup again on the result. If there's no __resolve__ attribute, then the AttributeError would be raised as usual. The chained __resolve__ resolution attempts would also give a useful exception backtrace. Cheers, Ron From mertz at gnosis.cx Wed Mar 5 07:54:30 2014 From: mertz at gnosis.cx (David Mertz) Date: Tue, 4 Mar 2014 22:54:30 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <20140305034945.GA67087@cskk.homeip.net> References: <20140305034945.GA67087@cskk.homeip.net> Message-ID: On Tue, Mar 4, 2014 at 7:49 PM, Cameron Simpson wrote: > > > b = eval(a) * 6 > > > This makes me unhappy. Eval parses a string and runs it, currently. > > > I would _want_ to read that as "compute a, then eval() the result". > > > > > b = a() * 6 > > > > I don't think I would want a thunk to be *exactly* a callable. That feels > > wrong to me. > > Can you be more precise? It seems like exactly what's going on, semanticly. > Except that there's no notion of parameters. > As *I* am thinking of it, a "thunk" is really just like a C macro. Not even really like a Lisp macro. So it's not like a function in that it doesn't define a scope, doesn't have a call stack, etc. It's just "pretend I typed these other literal symbols here." Maybe I should stop calling the idea a thunk, and just call it a macro. However, I'm pulled in several directions here. On the one hand, if it really is essentially the same thing as a code object, I'm not convinced we actually need syntax for it. That is, what's really the point of having a = $(expr) # or `expr`, or `(expr), or c"expr" If it's simply a slightly shorter way of spelling: a = compile(expr, "", "eval") One thing about a code object is that it is NOT callable. Which is to say, that it's not usable as a callback. If this other thing (thunk, macro, whatever) is callable, it's usable as a callback; albeit a callback with zero arguments, which again is of limited purpose, and not really that much shorter than lambda, e.g.: b = Button(text="click me", command=lambda: print("Clicked!")) Under the callable-thunk spelling, we might have: b = Button(text="click me", command=$(print("Clicked!"))) All of this is moving me towards the -0, or even -0.5 on my own idea (even though I like my spelling in principle, but I'm having trouble seeing why I actually need it). a.eval() > Don't make a new public function, give thunks a method. > Sure, that's a nice enough spelling, but what do we really get over code objects there? Actually, here's some short and trivial code in existing Python that seems to already get *everything* we've discussed in this thread: >>> class Thunk(object): ... def __init__(self, s): ... self.code = compile(s, "", "eval") ... def __call__(self, **kws): ... return eval(self.code, globals(), kws) ... eval = __call__ ... >>> a = Thunk("foo + bar") >>> for foo, bar in enumerate(range(5,8)): ... a() ... 5 7 9 >>> for foo, bar in enumerate(range(5,8)): ... a.eval() ... 5 7 9 >>> a(foo=10, bar=20) 30 Other than using the '$' which I'm mixed about anyway, and saving two quote symbols, my Thunk class seems to be exactly what I had proposed (with Cameron's variations). -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Wed Mar 5 07:57:10 2014 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 5 Mar 2014 17:57:10 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> Message-ID: On Wed, Mar 5, 2014 at 2:42 PM, Mark H. Harris wrote: > The idea of python number means that there are no types, no limits, no > constraints, and that all python numbers are dynamic. The upper level > syntax is also very simple; all python numbers are simply human. > > My influence for this preference is rooted in the Rexx programming > language; attributed to Mike Cowlishaw, former IBM fellow. The Rexx > programming language is dynamic, and has no types. To put it more > succinctly for those of you who have not used Rexx, the only data type > is a string of characters (that's it). Rexx numbers are simply those > strings of characters that may be interpreted as a valid Rexx number. I've used REXX extensively. (It's the native scripting language of OS/2, which I first met in the early 1990s and am still using - albeit usually in a VM under Linux these days - as it's still a good thing, just a little left-behind.) There are two huge downsides to that kind of proposal. 1) Performance. Huge huge performance hit. I can take Pike to OS/2, an unoptimized build on an unsupported platform, and absolutely cream a REXX program at any sort of computational work. By specifically working with integers rather than "numbers", I can run code blazingly fast. 2) Accuracy. With REXX, all arithmetic is governed by a single setting of NUMERIC DIGITS, which specifies how many digits of accuracy you want to preserve. (Python can improve granularity with separate contexts, but the same issue will still apply - contexts just let you use different NUMERIC DIGITS settings simultaneously in one program.) Set it too high and performance suffers because the system has to calculate more than you actually care about. Set it too low and accuracy suffers. Even when you're working with integers, going past DIGITS means it goes exponential. 3) Not so huge a downside, but also worth considering: REXX doesn't have complex number support at all. You have to simulate it with two variables. There's no way for the "Python number" system to intrinsically handle complexes. So really, what you're looking at is unifying int/float/Decimal into a single data type, which is basically Decimal. I'd say merging int into that is a bad idea, but you can get most of what you want to achieve simply by encouraging the use of Decimal everywhere. Maybe in some distant future version, the Python literal 1.234 will represent a Decimal rather than a float. (And then there'd be other consequences, like what you get when you divide one integer by another.) But until then, all you can really do is encourage people to explicitly use Decimal. ChrisA From harrismh777 at gmail.com Wed Mar 5 08:34:15 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Tue, 4 Mar 2014 23:34:15 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> Message-ID: <95fffdcc-b375-4811-a102-3ca4bee6efcb@googlegroups.com> On Wednesday, March 5, 2014 12:57:10 AM UTC-6, Chris Angelico wrote: > 1) Performance. Huge huge performance hit. I can take Pike to OS/2, an > unoptimized build on an unsupported platform, and absolutely cream a > REXX program at any sort of computational work. By specifically > working with integers rather than "numbers", I can run code blazingly > fast. > > 2) Accuracy. With REXX, all arithmetic is governed by a single setting > of NUMERIC DIGITS, which specifies how many digits of accuracy you > want to preserve. (Python can improve granularity with separate > contexts, but the same issue will still apply - contexts just let you > use different NUMERIC DIGITS settings simultaneously in one program.) > hi Chris, good to hear from another Rexx programmer! Back in the day (during my 25 year tenure with IBM, I wrote thousands of scripts in Rexx for VM370 systems, and OS/2. I too still have OS/2 running. whoohoo! Thanks for your comments. I would normally have agreed with you on this but not in this case. I do not think you are wrong, I just think you may have underestimated the power of decimal.Decimal /its phenomenal--really--! Don't take the Rexx reference too much to heart, I just wanted folks to know where I got my influence on this thinking. Rexx was too slow... so was Decimal until 3.3, and then, boy has it taken off so-to-speak! Implementation details are way off in the future of course, but I am thinking AI processing on this idea. The Python system will sense and optimize the decimal contexts (local and otherwise) so that things are balanced between speed and accuracy. And I would note, that speed is not as important for most python related aspects as user clarity and modern policy and account- ability. But, I'm not the least concerned for performance being a problem, because I have thoroughly tested decimal.Decimal and it flat screams, unlike our old friend Rexx. Thanks again for your feedback on the idea. Please give it some more thought, and let me know what you think of AI for load/speed/accuracy balancing. PS Have you considered the way things might have been if Palmisano had played ball with Bill Gates and Steve Ballmer back in the day... OS/2 would rule, gnu/linux might never have been invented period, and you and I might not be having this conversation today! ha! Go Big Blue. marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Wed Mar 5 09:10:18 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Wed, 5 Mar 2014 00:10:18 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> Message-ID: <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> My previous reply got google-grouped, so let me try again. From: Mark H. Harris Sent: Tuesday, March 4, 2014 7:42 PM >? ?The Python language might be changed to adopt the python number >concept for all math?processing, unless explicitly modified. This goes? >somewhat beyond using decimal floating point as a default numerical? >type. ?It means using human numeric expressions that meet human? >expectation for numeric processing by default. Different humans have different expectations in different situations. Trying to pick a single type that can handle all such expectations is an impossible dream.? >? ?Under the covers (whatever we mean by that) processing is handled >by decimal.Decimal, unless explicitly modified. What does this mean for >python users in general? ?Well, no more worrying about types at all... no ints, >no floats, no rationals, no irrationals, no fractions, and certainly no binaries. >In short, if its a human number, its a python number. This is not really a meaningful concept. The types you dislike are not programming concepts that get in the way of human mathematics, they are human mathematical concepts. The integers, the rationals, and the reals all behave differently. And they're not the only types of numbers?Python handles complex numbers natively, and it's very easy to extend it with, say, quaternions or even arbitrary matrices that act like numbers. The types that _are_ programming concepts?decimal and binary floats?are necessary, because you simply can't store real numbers in finite storage. And the very fact that they are inexact approximations means you can't ignore the types. For some uses, IEEE binary floats are best; for others, decimal floats are best; for others, fractions are best; for others, you even want to handle symbolic numbers like pi/2 exactly. >? ?I am expecting that (just as in Rexx numbers) defining very clearly what >is a python number? will be key for wide adaptation of the concept. But there >should be no surprises for users, particularly average users. Anyone with? >a middle school expectation of a numeric format should be able to use? >python numbers without surprises. Anyone with a middle school expectation will expect 1/3 to be a fraction?or, at least, something they can multiply by 3 to get exactly 1. Using an?inexact decimal float instead of an inexact binary float is no improvement at all. Sure, it's an improvement in some _other_ cases, like 0.123, but if you want to deal with 1/3, today you can do so explicitly by using, say, Fraction(1, 3), while in your world it will no longer be possible. And if you take the obvious way around that, you run into the same problem with 2 ** 0.5. Normal humans who write that would expect to be able to square it and get back 2, not an approximation to 2. >However, for advanced users the full >interface should be available (as is the context for Decimal) through coding >based on knowledge and experience, yet the default context for Decimal? >should be based on average users in most environments and use cases. Is there a problem with the current default context? I think just using Decimal as it is in Python today gets you everything you're asking for. Sure, you might want a nicer way to type them and repr them, which goes back to the previous thread, but why do you need to get rid of all of the other types as well? From masklinn at masklinn.net Wed Mar 5 10:18:56 2014 From: masklinn at masklinn.net (Masklinn) Date: Wed, 5 Mar 2014 10:18:56 +0100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <5316544D.7050302@canterbury.ac.nz> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> Message-ID: <05894993-3C4D-42E7-9328-C3365DF92CBE@masklinn.net> On 2014-03-04, at 23:31 , Greg Ewing wrote: > Steven D'Aprano wrote: >> What I have in my head is some vague concept that the Python evaluation rules will somehow know when to evaluate the thunk and when to treat it as an object, which is (as I understand it) what happens in Algol. > > But Algol has the benefit of static typing -- the procedure > being called explicitly declares whether the argument is to > be passed by name or value. Python has no idea about that at > compile time. That's not really a blocker though, Haskell thunks are implicit and not type-encoded. A name may correspond to a (unforced) thunk or to a strict value (an already forced thunk, whether through a previous implicit forcing, through an explicit forcing ? a strict annotation ? or through a decision of the strictness analyser). >> b = [0, `1 + thunk`] # delays evaluation and creates a thunk object >> # equivalent to `1 + some_expression` >> c = b[1] # now evaluates the thunk object >> d = f(2, thunk) # evaluates thunk in f's scope >> e = g(3, `thunk`) # passes the un-evaluated thunk object to g > > When exactly does implicit evaluation of a thunk object occur? > Does `b[1]` give you an unevaluated thunk object? What if b is > a custom sequence type implemented in Python -- how does its > __getitem__ method avoid evaluating the thunk object prematurely? > > None of these problems occur in Algol, because its thunks are > not first-class values (you can't store them in arrays, etc.) > and it uses static type information to tell when to create > and evaluate them. There are definitely difficulties in deciding how the decision to force a thunk comes about. From rosuav at gmail.com Wed Mar 5 10:36:42 2014 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 5 Mar 2014 20:36:42 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <95fffdcc-b375-4811-a102-3ca4bee6efcb@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <95fffdcc-b375-4811-a102-3ca4bee6efcb@googlegroups.com> Message-ID: On Wed, Mar 5, 2014 at 6:34 PM, Mark H. Harris wrote: > hi Chris, good to hear from another Rexx programmer! Back in the day > (during > my 25 year tenure with IBM, I wrote thousands of scripts in Rexx for VM370 > systems, and OS/2. I too still have OS/2 running. whoohoo! > > Don't take the Rexx reference too much to heart, I just wanted folks to know > where I got my influence on this thinking. Rexx was too slow... so was > Decimal > until 3.3, and then, boy has it taken off so-to-speak! Yes, that's true. But I've just done some performance testing. REXX on our OS/2 VM accounting server "Stanley" calculates 10000! in 14 seconds; Pike on the same hardware calculates 100000! in 4 seconds. (I didn't bother calculating 100000! in REXX, didn't feel like waiting.) In each case it was by this naive algorithm: REXX: n=1; do i=1 to 10000; n=n*i; end Pike: int n=1; for (int i=1;i<=100000;++i) n*=i; Those were running on the same hardware, and going to a target an order of magnitude higher took a fraction of the time. That's what integer performance is like. (BTW, I set 'numeric digits' to something just a bit more than the target. REXX was pretty fast if I left digits low, and I could then look at the exponent to see what digits setting I needed. In Pike's case, the int type supports arbitrary precision anyway, so the net result is a fair comparison; I could write the digits out to a file and get the exact same result.) >From here on, I've switched computers to Sikorsky, who has more languages and more power than Stanley has. Timings here aren't technically comparable to the above ones, but they seem similar. I guess VirtualBox is doing a decent job of staying out of the way. Pike on Sikorsky: > gauge {int n=1; for (int i=1;i<=100000;++i) n*=i;}; (3) Result: 3.394805453 Okay. Now, Python. Python 3.4.0rc1+ (default:a124b981a7a3, Mar 3 2014, 01:30:30) [GCC 4.7.2] on linux >>> def fac(top): t=time.time() n=1 for i in range(1,top+1): n*=i return time.time()-t >>> fac(100000) 7.814447641372681 Roughly double Pike's time. (I suspect this may be largely because Pike has an optimization for machine-word integers. The difference is far starker if the algorithm used is less naive.) Now watch the result of a switch of data type. def fac_d_maxprec(top): from decimal import Decimal, getcontext, MAX_PREC getcontext().prec=MAX_PREC t=time.time() n=Decimal("1") for i in range(1,top+1): n*=i return time.time()-t (Note that the multiplication is still with ints. Doing all the multiplication with Decimals would mean a whole lot more calling of the constructor, which wouldn't be a fair comparison. If all of Python used Decimal, then range() would be returning Decimal.) >>> fac_d_maxprec(100000) 20.71300506591797 I also wrote an alternative version of the above which pre-calculates at low precision, then sets the precision to just enough, and recalculates. The timings were statistically identical to the above. So there you are: A three to one difference. That's pretty amazing, actually - the fact that it's not *far far* worse is a tribute to the folks who gave us this highly optimized decimal.Decimal implementation! But it's still dramatically slower than integer calculations, and as you can see from the Pike version, the integer figures can be cut a long way too. I'm not sure that I want to give that up. > But, I'm not the least concerned for performance being a problem, > because I have thoroughly tested decimal.Decimal and it flat screams, unlike > our old friend Rexx. Yes, that's true (although frankly, when I first met REXX on OS/2, it screamed compared to doing the job myself in C - sure, I could do integer calculations quicker in C, but if I wanted to go above the size of a long - 1<<32 - that was pretty hard), but the screaming isn't so impressive compared to a modern integer engine. > PS Have you considered the way things might have been if Palmisano > had played ball with Bill Gates and Steve Ballmer back in the day... OS/2 > would rule, gnu/linux might never have been invented period, and you and > I might not be having this conversation today! ha! Go Big Blue. Hmm, I don't think so. Linux had a rather different purpose, back then. But yeah, OS/2 was brilliant tech built in a hostile environment... I'd like to see some of its best parts lifted onto a Linux kernel, though (like the WorkPlace Shell - should be possible to run that on top of X11). Alas, most of OS/2 now is in the "was great in the 90s, but other things do the same job now" basket, and a closed-source system that boasts little above a GNU/Linux stack isn't really going to go anywhere much. Still, it's hanging around. It's the best way I have for running 16-bit Windows programs, believe it or not. (And yes, I did try running Pastel Accounting under Wine. Win-OS/2 still beats Wine hands-down, probably because Wine developers don't see any reason to bother with supporting anything so ancient.) ChrisA From shai at platonix.com Wed Mar 5 11:16:12 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 12:16:12 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight Message-ID: <201403051216.12392.shai@platonix.com> Hi all, This is my first post here, following a recommendation from Alexander Belopolsky to use this list, to try to convince the Python developers to reopen a ticket. I am a long-time Python user, and a Django committer. http://bugs.python.org/issue13936 is a complaint about the fact that midnight -- datetime.time(0,0,0) -- is evaluated as False in Boolean contexts. It was closed as invalid, under the claim that """It is odd, but really no odder than "zero values" of other types evaluating to false in Boolean contexts""". I would like to ask for this to be reconsidered; since the ticket was closed, two main arguments were given for this: 1) The practical argument (paraphrasing Danilo Bergen and Andreas Pelme): The current semantics is surprising and useless; users do not expect valid times to be falsey, and do not normally want code to have special behavior on midnight. Users who ask for Boolean evaluation of a variable that's supposed to hold a time value, usually write "if var" as shorthand for "if var is not None". 2) The principled argument (which I think is at the root of the practical argument); quoting myself from the ticket: """Midnight is not a "zero value", it is just a value. It does not have any special qualities analogous to those of 0, "", or the empty set. ... Midnight evaluting to false makes as much sense as date(1,1,1) -- the minimal valid date value -- evaluating to false""". Thanks, Shai. From p.f.moore at gmail.com Wed Mar 5 11:23:31 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 10:23:31 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051216.12392.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> Message-ID: On 5 March 2014 10:16, Shai Berger wrote: > http://bugs.python.org/issue13936 is a complaint about the fact that midnight > -- datetime.time(0,0,0) -- is evaluated as False in Boolean contexts. It was > closed as invalid, under the claim that """It is odd, but really no odder than > "zero values" of other types evaluating to false in Boolean contexts""". > > I would like to ask for this to be reconsidered; since the ticket was closed, > two main arguments were given for this: Why on earth would anyone check the boolean value of a time??? Before looking at whether midnight should be false or true, I'd like to be clear on why any real life code would care one way or the other. It seems to me that the correct answer would be to change the code to simply not rely on the boolean value of a time. Paul From masklinn at masklinn.net Wed Mar 5 11:31:08 2014 From: masklinn at masklinn.net (Masklinn) Date: Wed, 5 Mar 2014 11:31:08 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> On 2014-03-05, at 11:23 , Paul Moore wrote: > On 5 March 2014 10:16, Shai Berger wrote: >> http://bugs.python.org/issue13936 is a complaint about the fact that midnight >> -- datetime.time(0,0,0) -- is evaluated as False in Boolean contexts. It was >> closed as invalid, under the claim that """It is odd, but really no odder than >> "zero values" of other types evaluating to false in Boolean contexts""". >> >> I would like to ask for this to be reconsidered; since the ticket was closed, >> two main arguments were given for this: > > Why on earth would anyone check the boolean value of a time??? Side-effect of e.g. an object with an optional (nullable) time field, the developer didn't realise a time could be false-ish (because seriously?) and then it turns out code along the lines of if event.start_time: # stuff unexpectedly fails if start_time is midnight. I've actually done something close recently, didn't expect more_itertool's peekable iterator could be false-ish[0] because I'd expect empty sequences to be falsy but not empty iterators. It turned out to be useful and to simplify my code, but I can see developers not considering such edge cases unless there's a clear warning (as in ElementTree which IIRC clearly warns that an element with no children is false-ish) especially for objects for which false-ish-ness makes so little sense as a time. [0] even though the behavior is documented. From p.f.moore at gmail.com Wed Mar 5 11:44:07 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 10:44:07 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: On 5 March 2014 10:31, Masklinn wrote: > Side-effect of e.g. an object with an optional (nullable) time field, > the developer didn't realise a time could be false-ish (because > seriously?) and then it turns out code along the lines of > > if event.start_time: > # stuff > > unexpectedly fails if start_time is midnight. Yeah, I was classing that as "application bug" and it's easy to fix with an "is not None". Agreed that the odd behaviour of time in a boolean context is why this whole class of bugs exists, but it's only a subclass if the wider problem that people shouldn't truth-test values without thinking - an explicit test is always better (explicit is better than implicit and all that). I actually find the idea of truth-testing a value that's expected to have a type that is always true *more* unintuitive than an explicit "is not None", so I'd fix the above code regardless of what the truth value of midnight is. Paul From shai at platonix.com Wed Mar 5 11:59:40 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 12:59:40 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: <201403051259.40289.shai@platonix.com> On Wednesday 05 March 2014 12:44:07 Paul Moore wrote: > > I actually find the idea of truth-testing a value that's expected to > have a type that is always true *more* unintuitive than an explicit > "is not None", so I'd fix the above code regardless of what the truth > value of midnight is. > I can appreciate this point of view, but I think it is not the position generally taken by Python (if it were, Boolean evaluation of an object of a type that is always true would have raised an exception). Shai. From steve at pearwood.info Wed Mar 5 12:18:23 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 5 Mar 2014 22:18:23 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: <20140305111823.GU28804@ando> On Tue, Mar 04, 2014 at 11:09:02PM +0000, Carl Smith wrote: > The tentatively proposed idea here is using dollar signed expressions to > define 'bills'. A bill object is essentially an expression which can be > evaluated any number of times, potentially in different scopes. Please don't invent "cute" names for things which already have names. What you are describing could be considered a thunk, or a macro, or a lazily-evaluated expression, depending on the precise details of how it works. But calling it a "bill" just because it starts with a $ just makes me cringe. > The following expression [a bill literal] would be pointless, but would > define a bill that always evaluates to 1. > > $1 > > So, eval($1)==1. My personal feeling here is that if you have to explicitly call eval on the "bill" to evaluate it, it's not worth doing. If we were happy with that, we've already got compile(), or we have functions. Or just eval a string directly. My feeling is that evaluating the expression needs to be implicit, performed at need rather than up front, rather in the same way that short-circuiting operators don't actually evaluate the expression unless needed: x or expr # expr is only evaluated if x is a falsey value Yes, I know, the Zen of Python says that "explicit is better than implicit", but the Zen is intended as guidelines, not thought-blockers. We have perfectly good explicit idioms for delaying computations (eval and functions), to make the thunk/macro/whatever worth doing it has to offer something different. > Some better examples... > > * assign a bill to `a` so that `a` will evaluate to the value of the name > `foo` any time that `a` is evaluated, in the scope of that evaluation > > a = $foo > > * as above, but always plus one > > a = $foo + 1 > > * make `a` a bill that evaluates to the value of the name `foo` at the time > that `a` is evaluated, in that scope, plus the value of `bar` **at the time > and in the scope of the assignment to `a`** > > a = $foo + bar Hmmm. That implies that if you want an entire expression to have delayed evaluation, you have to tag everything with a sigil: a = $spam + $eggs - $spam*$eggs + $cheese*$spam I think it is better to have syntax with delimiters, to turn delayed evaluation ON and OFF, rather than having to tag each and every sub-expression: a = `spam + eggs - spam*eggs + cheese*spam` (disclaimer: using ` ` is just for the sake of illustration.) > Note. Similarly to mixing floats with ints, any expression that contains a > bill evaluates to a bill, so if `a` is a bill, `b=a+1` makes `b` a bill > too. Passing a bill to eval should be the obvious way to get the value. > > The point? It allows functions to accept bills to use internally. The > function would specify any names the bill can reference in the function's > API, like keywords. Well, this contradicts your previous point. If any expression that contains a "bill" is a "bill", then so is func(bill). So given that, your example here: > def f(b): # the bill arg `b` can reference `item` > for item in something: > if eval(b): return True > > f($item < 0) would actually need to be written as: eval(f($item < 0)) -- Steven From steve at pearwood.info Wed Mar 5 12:25:32 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 5 Mar 2014 22:25:32 +1100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <6939FECB-867D-46EC-B5D2-737DA205590D@yahoo.com> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> <6939FECB-867D-46EC-B5D2-737DA205590D@yahoo.com> Message-ID: <20140305112532.GV28804@ando> On Tue, Mar 04, 2014 at 05:05:39PM -0800, Andrew Barnert wrote: > On Mar 4, 2014, at 14:31, Greg Ewing wrote: > > > Steven D'Aprano wrote: > >> What I have in my head is some vague concept that the Python evaluation rules will somehow know when to evaluate the thunk and when to treat it as an object, which is (as I understand it) what happens in Algol. > > > > But Algol has the benefit of static typing -- the procedure > > being called explicitly declares whether the argument is to > > be passed by name or value. Python has no idea about that at > > compile time. I'm not convinced that this really matters, but for the sake of the argument let's say it does. > This is the main reason I think it's more productive to think of this > in terms of Lisp-style quoting than Algol-style thunks. Can you give more detail please? -- Steven From oscar.j.benjamin at gmail.com Wed Mar 5 12:29:10 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Wed, 5 Mar 2014 11:29:10 +0000 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> Message-ID: On 5 March 2014 08:10, Andrew Barnert wrote: > From: Mark H. Harris >> >> I am expecting that (just as in Rexx numbers) defining very clearly what >>is a python number will be key for wide adaptation of the concept. But there >>should be no surprises for users, particularly average users. Anyone with >>a middle school expectation of a numeric format should be able to use >>python numbers without surprises. > > Anyone with a middle school expectation will expect 1/3 to be a fraction--or, at least, something they can multiply by 3 to get exactly 1. Using an inexact decimal float instead of an inexact binary float is no improvement at all. I actually think that it is an improvement. Most people are surprised by the fact that just writing x = 0.1 causes a rounding error. Python only has dedicated syntax for specifying binary floats in terms of decimal digits meaning that there is no syntax for exactly specifying non integer numbers. I would say that that is clearly a sub-optimal situation. I don't agree with Mark's proposal in this thread but I would like to have decimal literals e.g. 1.23d, and I would also use Fraction literals if available e.g. 1/3F. Oscar From steve at pearwood.info Wed Mar 5 12:32:33 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 5 Mar 2014 22:32:33 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <20140305014611.GA4396@cskk.homeip.net> References: <20140305014611.GA4396@cskk.homeip.net> Message-ID: <20140305113233.GW28804@ando> On Wed, Mar 05, 2014 at 12:46:11PM +1100, Cameron Simpson wrote: > That makes me think the (()) or $() is in the wrong place. Maybe: > > a := foo + 1 No good. That implies that there is no way to have an anonymous thunk. You can do this: my_list = [x + 1, y + 2, # eager evaluation $(z + 3), # lazy evaluation ... ] but would have to write: temp := z + 3 my_list = [x + 1, y + 2, temp, ...] Similarly for passing a thunk into a function. > Since I'm cavilling about "eval", how about just treating thunks > like other functions (which is how we spell code to be run later > presently) and have them be callables. In which case, what's the point? What makes them different from regular functions? -- Steven From steve at pearwood.info Wed Mar 5 12:43:44 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 5 Mar 2014 22:43:44 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: <20140305034945.GA67087@cskk.homeip.net> Message-ID: <20140305114344.GX28804@ando> On Tue, Mar 04, 2014 at 10:54:30PM -0800, David Mertz wrote: > As *I* am thinking of it, a "thunk" is really just like a C macro. Not > even really like a Lisp macro. So it's not like a function in that it > doesn't define a scope, doesn't have a call stack, etc. It's just "pretend > I typed these other literal symbols here." Maybe I should stop calling the > idea a thunk, and just call it a macro. I'm intrigued by this suggestion. I think that what I'm really after is two things: lazy evaluation, and dynamic scoping. I think a macro would give us both. But hasn't Guido said No Macros at some point? > However, I'm pulled in several directions here. On the one hand, if it > really is essentially the same thing as a code object, I'm not convinced we > actually need syntax for it. That is, what's really the point of having > > a = $(expr) # or `expr`, or `(expr), or c"expr" > > If it's simply a slightly shorter way of spelling: > > a = compile(expr, "", "eval") You can't write it like that. You have to wrap the expression is quotes and turn it into a string: a = compile("expr", "", "eval") which means you lose syntax highlighting. Perhaps the ability to get syntax highlighting is not sufficient to justify this idea. Another disadvantage: the ever-present temptation to pass a user-generated string to compile: a = compile(template % some_string, "", "eval") If some_string came from an untrusted source, you are now the proud owner of a brand new code injection vulnerability. But with syntax, you cannot generate a thunk/macro except from code you write yourself. It's still code written by you, it's just that evaluation is delayed. -- Steven From cfkaran2 at gmail.com Wed Mar 5 12:53:10 2014 From: cfkaran2 at gmail.com (Cem Karan) Date: Wed, 5 Mar 2014 06:53:10 -0500 Subject: [Python-ideas] Suggestion for standardized annotations Message-ID: Hi all, I wanted to make a suggestion for a convention on how to write annotations. I know that PEP 8 says that the standard library won't use them in order to avoid setting a convention, but that could lead to confusion and conflicts in how they are used in non-standard libraries. The reason I'm thinking about this is because of how docstrings are currently used. If you use PLY (http://www.dabeaz.com/ply/) and also want to use something like Sphinx (http://sphinx-doc.org/), you're going to have a problem; PLY stores its rules in the docstring, while Sphinx parses it for documentation. I want to prevent this problem for annotations. My thought is that all annotations should be dictionaries. The keys should all be unicode strings that are uppercase UUIDs (basically, what 'uuid.uuid1().hex.upper()' returns), and the values can be anything the programmer wants. Each project can generate one (or more) UUIDs to put into the dictionary, and publicly document what the UUID's meaning is (preferably somewhere where a search engine can find it). The advantage is that since UUIDs are unique, the number of false positives you'll get while searching for it should be low; I've tested this on a different mailing list I'm on, and the UUID I generated for it has 0 false positives, while picking up the complete discussion involving it. As an example, if project A had chosen the UUID B3D2AFE8A45A11E3AE24D49A20C52EF2 and project B chose the UUID C02D7C64A45A11E39DAFD49A20C52EF2, we might annotate a function as follows: def foo(first : { B3D2AFE8A45A11E3AE24D49A20C52EF2 : {"doc" : "English documentation"}, C02D7C64A45A11E39DAFD49A20C52EF2 : {"doc" : "expression : MINUS expression %prec UMINUS"} }, second) -> {B3D2AFE8A45A11E3AE24D49A20C52EF2: {"type" : int, "doc" : "Typechecking for a linter"}}: pass You can already see the downside of this approach; it's really, really verbose. However, at least it avoids outright conflicts in usage that prevent usage of certain tools/projects together. Note that I did consider using names as keys directly (e.g. 'doc'). However, that requires a strong, universal convention on what each key means. Since we can't seem to figure that out for the docstring, I don't see why we should expect to be able to figure it out for any of proposed keys. Moreover, the set of keys would need to be documented somewhere, the documentation kept up to date, etc. It becomes a management nightmare. UUIDs have the advantage the we just tell everyone how to generate their own, and let them go at it. If someone wants to use a given project's docstring for their own purposes, it is up to them to keep the meaning the same. Thoughts/suggestions? Thanks, Cem Karan From steve at pearwood.info Wed Mar 5 13:04:10 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 5 Mar 2014 23:04:10 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> Message-ID: <20140305120410.GY28804@ando> On Wed, Mar 05, 2014 at 11:29:10AM +0000, Oscar Benjamin wrote: > I don't agree with Mark's proposal in this thread but I would like to > have decimal literals e.g. 1.23d, +1 on that. Although that will depend on how big a slowdown it causes to Python's startup time. > and I would also use Fraction > literals if available e.g. 1/3F. Out of curiosity, why F rather than f? (By the way, I think it is somewhat amusing that Python not only has a built-in complex type, but also *syntax* for creating complex numbers, but no built-in support for exact rationals.) -- Steven From oscar.j.benjamin at gmail.com Wed Mar 5 13:30:19 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Wed, 5 Mar 2014 12:30:19 +0000 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140305120410.GY28804@ando> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: On 5 March 2014 12:04, Steven D'Aprano wrote: > On Wed, Mar 05, 2014 at 11:29:10AM +0000, Oscar Benjamin wrote: > >> I don't agree with Mark's proposal in this thread but I would like to >> have decimal literals e.g. 1.23d, > > +1 on that. Although that will depend on how big a slowdown it causes to > Python's startup time. If it is a significant slowdown then it can be a delayed import that only occurs when a decimal literal is first encountered. Applications that don't need decimal won't be slowed down. Applications that do would have had to import it anyway. >> and I would also use Fraction >> literals if available e.g. 1/3F. > > Out of curiosity, why F rather than f? In C and some other languages the f suffix indicates a numeric literal that has type "float" e.g. "6.0f". You can use upper case there as well but the convention is lower case and to include the .0 when it's an integer. I just though that 3F looks sufficiently distinct from the way it's typically done in C. Oscar From rosuav at gmail.com Wed Mar 5 13:33:11 2014 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 5 Mar 2014 23:33:11 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <20140305051534.GA75905@cskk.homeip.net> References: <5316A2CE.2040509@mrabarnett.plus.com> <20140305051534.GA75905@cskk.homeip.net> Message-ID: On Wed, Mar 5, 2014 at 4:15 PM, Cameron Simpson wrote: > On 05Mar2014 04:06, MRAB wrote: >> On 2014-03-05 01:46, Cameron Simpson wrote: >> >> a = $(foo + 1) >> > >> >Definitely nicer. Still irrationally uncomfortable about the "$" though. >> >A thought, though it could break existing code (and nested tuples, alas): >> > a = (( foo + 1 )) >> > >> That's not a tuple. It's equivalent to: >> a = foo + 1 > > I know that. I should have said: though the below looks nice, in more complicated forms it fights with tuples, eg: > > ((1,2,3),(4,5,6)) > (((1,2,3),(4,5,6))) Bikeshedding the syntax without expressing an opinion on the feature: Using {{ }} would be safer. The inner one might be interpreted as a dict or a set, but neither of those can go into a set, so it'd be illogical. Whether the similarity with C-style block delimiters is a good thing or a bad thing remains to be seen :) ChrisA From oscar.j.benjamin at gmail.com Wed Mar 5 13:34:09 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Wed, 5 Mar 2014 12:34:09 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051259.40289.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> <201403051259.40289.shai@platonix.com> Message-ID: On 5 March 2014 10:59, Shai Berger wrote: > On Wednesday 05 March 2014 12:44:07 Paul Moore wrote: >> >> I actually find the idea of truth-testing a value that's expected to >> have a type that is always true *more* unintuitive than an explicit >> "is not None", so I'd fix the above code regardless of what the truth >> value of midnight is. > > I can appreciate this point of view, but I think it is not the position > generally taken by Python (if it were, Boolean evaluation of an object of a > type that is always true would have raised an exception). I think it's clear that if this were new code being added to the stdlib then the consensus would be that having midnight evaluate as False is ridiculous. The question is surely whether the issue is worth a backwards compatibility break not whether the current behaviour is a good idea (it clearly isn't). Oscar From carl.input at gmail.com Wed Mar 5 13:41:10 2014 From: carl.input at gmail.com (Carl Smith) Date: Wed, 5 Mar 2014 12:41:10 +0000 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality Message-ID: Just for the record, I never called them bills just because they contain a dollar sign! I was thinking of a short word which describes an expression who's evaluation changes depending on the local circumstances. Like a legal bill, not a dollar bill. The name macro doesn't really work, as it's only an expression, it's not a code block. --- The idea was never to start passing complex expressions around the place. It was just to allow a function to take an expression containing about one or two names, and evaluate the expression internally, so this... func(lambda foo: foo > 0) ...can become... func($foo > 0) Other uses are there, and might be helpful from time to time, but it's mainly about cleaning up APIs. I personally work with user facing Python APIs all day, and users are generally programming interactively, so perhaps my take is atypical. --- What the hell is a thunk anyway? It's a horrible name. --- On the jQuery like syntax, $(foo), that might work and might do away with the issue of expressions containing bills always evaluating to bills. I took that too far. Good point. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Wed Mar 5 13:42:14 2014 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 5 Mar 2014 23:42:14 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: On Wed, Mar 5, 2014 at 11:30 PM, Oscar Benjamin wrote: > I just though that 3F looks sufficiently distinct from the > way it's typically done in C. 3F would be about -16C wouldn't it? (Not painting any bike sheds when it's that cold, thanks!) I'm not sure I like the idea of tagging the end of the expression. Currently, the nearest Python has to that is the complex notation: >>> 1+2j (1+2j) And that works just fine when considered to be addition: >>> a=1 >>> b=2j >>> a+b (1+2j) So really, what Python has is a notation for a j-suffixed float, meaning a complex number with no real part. You can't do that with Fraction: >>> a=2 >>> b=3F >>> a/b What I'd prefer would be some modification of the division operator. We currently have two ways to divide an integer by an integer: >>> 1234/10 123.4 >>> 1234//10 123 Adding a third operator, defined only between two integers, would be cleaner than tagging one of the integer literals. Exactly what that operator would be is hard to say, but I'm sure there's a combination that would look right and not be ambiguous. >>> 1234-/-10 Fraction(617, 5) I can't think of anything good, though. ChrisA From p.f.moore at gmail.com Wed Mar 5 13:50:14 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 12:50:14 +0000 Subject: [Python-ideas] Suggestion for standardized annotations In-Reply-To: References: Message-ID: On 5 March 2014 11:53, Cem Karan wrote: > Thoughts/suggestions? I think the core/stdlib position is that agreeing conventions would be better done once some real world experience of the practical issues and benefits of annotations has been established. So while a proposal like this is not without merit, it needs to be considered in the light of how projects actually use annotations. Personally, I'm not aware of any libraries that make significant use of annotations, so a good first step would be to survey existing use, and summarise it here. That would allow you to clarify your proposal in terms of exactly how existing projects would need to modify their current code. Of course, there's likely a chicken and egg problem here - projects may be holding off using annotations through fear of issues caused by clashes. But I'm not sure that a UUID-based proposal like the above (which as you admit is very verbose, and not particularly user friendly) would be more likely to encourage use. If I were developing a library that would benefit from annotations, at this point in time I'd probably just choose whatever conventions suited me and go with those - likely marking the feature as "subject to change" initially. Then, when people raised bug reports or feature requests that asked for better interoperability, I'd look at how to achieve that in conjunction with the other project(s) that clashed with me. Paul From p.f.moore at gmail.com Wed Mar 5 13:54:27 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 12:54:27 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> <201403051259.40289.shai@platonix.com> Message-ID: On 5 March 2014 12:34, Oscar Benjamin wrote: > On 5 March 2014 10:59, Shai Berger wrote: >> On Wednesday 05 March 2014 12:44:07 Paul Moore wrote: >>> >>> I actually find the idea of truth-testing a value that's expected to >>> have a type that is always true *more* unintuitive than an explicit >>> "is not None", so I'd fix the above code regardless of what the truth >>> value of midnight is. >> >> I can appreciate this point of view, but I think it is not the position >> generally taken by Python (if it were, Boolean evaluation of an object of a >> type that is always true would have raised an exception). > > I think it's clear that if this were new code being added to the > stdlib then the consensus would be that having midnight evaluate as > False is ridiculous. > > The question is surely whether the issue is worth a backwards > compatibility break not whether the current behaviour is a good idea > (it clearly isn't). Precisely. Sorry I wasn't clear enough. And FWIW, my opinion is that the problem is not worth a compatibility break, because it's so easily solved (and the fixed code is probably an improvement in any case). Paul From oscar.j.benjamin at gmail.com Wed Mar 5 13:56:46 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Wed, 5 Mar 2014 12:56:46 +0000 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: On 5 March 2014 12:42, Chris Angelico wrote: > On Wed, Mar 5, 2014 at 11:30 PM, Oscar Benjamin > wrote: >> I just though that 3F looks sufficiently distinct from the >> way it's typically done in C. > > 3F would be about -16C wouldn't it? > > (Not painting any bike sheds when it's that cold, thanks!) > > I'm not sure I like the idea of tagging the end of the expression. > Currently, the nearest Python has to that is the complex notation: > >>>> 1+2j > (1+2j) > > And that works just fine when considered to be addition: > >>>> a=1 >>>> b=2j >>>> a+b > (1+2j) > > So really, what Python has is a notation for a j-suffixed float, > meaning a complex number with no real part. You can't do that with > Fraction: > >>>> a=2 >>>> b=3F >>>> a/b >From a syntactic perspective Python doesn't have syntax for general complex literals. There is only syntax for creating imaginary literals and it is trivial to create a complex number by adding a real and an imaginary one. 3F could create a Fraction with the integer value 3 so that a/b gives a rational number: >>> from fractions import Fraction as F >>> a = 2 >>> b = F(3) >>> a/b Fraction(2, 3) I don't understand why you say that can't be done. Oscar From kaiser.yann at gmail.com Wed Mar 5 14:09:58 2014 From: kaiser.yann at gmail.com (Yann Kaiser) Date: Wed, 5 Mar 2014 14:09:58 +0100 Subject: [Python-ideas] Suggestion for standardized annotations In-Reply-To: References: Message-ID: You could use a slight modification of sigtools.modifiers.annotate [1] to create different objects with different function annotations. That way programmers who only use one library have no change to do, and those who use more only have to add a few lines devoid of the verbosity of UUIDs. [1] http://sigtools.readthedocs.org/en/latest/#sigtools.modifiers.annotate On 5 March 2014 13:50, Paul Moore wrote: > On 5 March 2014 11:53, Cem Karan wrote: >> Thoughts/suggestions? > > I think the core/stdlib position is that agreeing conventions would be > better done once some real world experience of the practical issues > and benefits of annotations has been established. So while a proposal > like this is not without merit, it needs to be considered in the light > of how projects actually use annotations. Personally, I'm not aware of > any libraries that make significant use of annotations, so a good > first step would be to survey existing use, and summarise it here. > That would allow you to clarify your proposal in terms of exactly how > existing projects would need to modify their current code. > > Of course, there's likely a chicken and egg problem here - projects > may be holding off using annotations through fear of issues caused by > clashes. But I'm not sure that a UUID-based proposal like the above > (which as you admit is very verbose, and not particularly user > friendly) would be more likely to encourage use. > > If I were developing a library that would benefit from annotations, at > this point in time I'd probably just choose whatever conventions > suited me and go with those - likely marking the feature as "subject > to change" initially. Then, when people raised bug reports or feature > requests that asked for better interoperability, I'd look at how to > achieve that in conjunction with the other project(s) that clashed > with me. > > Paul > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From shai at platonix.com Wed Mar 5 14:10:54 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 15:10:54 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051259.40289.shai@platonix.com> Message-ID: <201403051510.54769.shai@platonix.com> On Wednesday 05 March 2014 14:34:09 Oscar Benjamin wrote: > > I think it's clear that if this were new code being added to the > stdlib then the consensus would be that having midnight evaluate as > False is ridiculous. > > The question is surely whether the issue is worth a backwards > compatibility break not whether the current behaviour is a good idea > (it clearly isn't). > If this is the case, then we should be asking a variant of Paul's question: Why would anyone check if a time is equal to midnight, by Boolean evaluation rather than comparison to midnight? Or, rather, how many people do this? We have several reports of the current behavior causing surprising, hard-to- detect bugs (a co-worker spent a couple of hours on one such bug yesterday; frankly, I'm impressed he found it that fast). Unless we have reason to think people are using this on purpose, the effect of the change will probably be to fix many more bugs than it causes. I suggest to handle the backwards-compatibility issue with a deprecation cycle: Python 3.4 is already feature frozen, so make 3.5 raise a PendingDeprecationWarning when datetime.time.__nonzero__ returns False; 3.6 a DeprecationWarning; and 3.7 return True. That's what we would do in Django. On Wednesday 05 March 2014 14:54:27 Paul Moore wrote: > > And FWIW, my opinion is that the problem is not worth a compatibility > break, because it's so easily solved (and the fixed code is probably > an improvement in any case). Ah, but it is only easily solved once it is detected; the behavior causes bugs that surface once in a blue moon (in production, and then they cannot be reproduced by developers who, usually, do not work at midnight). So, on a second thought -- an alternative solution is to make any Boolean evaluation of time objects warn the user about midnight. Thanks for your attention, Shai. From steve at pearwood.info Wed Mar 5 14:21:03 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 00:21:03 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> Message-ID: <20140305132103.GZ28804@ando> On Wed, Mar 05, 2014 at 12:10:18AM -0800, Andrew Barnert wrote: > Anyone with a middle school expectation will expect 1/3 to be a > fraction?or, at least, something they can multiply by 3 to get exactly > 1. Not a very good example -- that happens to work for Python floats (which are C doubles under the hood): py> (1/3)*3 == 1 True py> (1/3 + 1/3 + 1/3) == 1 True But it *does not work* with Decimal, at least not with the default precision: py> from decimal import Decimal py> (Decimal(1)/3)*3 Decimal('0.9999999999999999999999999999') Decimal is not a panacea! It does not eliminate floating point issues. Between 1 and 100, there are 32 Decimal numbers that fail the test that (1/n)*n == 1, and only two floats. Between 1 and 100, there are only four floats where 1/(1/n) does not equal n: 49 93 98 and 99. In comparison, there are 46 such failing Decimals, including 6 7 and 9. -- Steven From steve at pearwood.info Wed Mar 5 14:23:33 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 00:23:33 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: <20140305132333.GA28804@ando> On Wed, Mar 05, 2014 at 11:42:14PM +1100, Chris Angelico wrote: > I'm not sure I like the idea of tagging the end of the expression. > Currently, the nearest Python has to that is the complex notation: > > >>> 1+2j > (1+2j) > > And that works just fine when considered to be addition: > > >>> a=1 > >>> b=2j > >>> a+b > (1+2j) > > So really, what Python has is a notation for a j-suffixed float, > meaning a complex number with no real part. You can't do that with > Fraction: > > >>> a=2 > >>> b=3F > >>> a/b Why not? If 3d is a Decimal with the value of 3, why couldn't 3F be a Fraction with the value of 3? -- Steven From p.f.moore at gmail.com Wed Mar 5 14:26:38 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 13:26:38 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051510.54769.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051259.40289.shai@platonix.com> <201403051510.54769.shai@platonix.com> Message-ID: On 5 March 2014 13:10, Shai Berger wrote: > On Wednesday 05 March 2014 14:54:27 Paul Moore wrote: >> >> And FWIW, my opinion is that the problem is not worth a compatibility >> break, because it's so easily solved (and the fixed code is probably >> an improvement in any case). > > Ah, but it is only easily solved once it is detected; the behavior causes bugs > that surface once in a blue moon (in production, and then they cannot be > reproduced by developers who, usually, do not work at midnight). That's a fair point. But your deprecation suggestion doesn't seem to help this, unless you expect (in a realistic timescale) to be able to drop support for Python <3.7. Your users (on say 2.7 or 3.3) will still get bugs, and now your developers (using 3.7) won't even be able to reproduce the issue by staying up till midnight. And once they do find the bug they will still have to fix it by an explicit test. Again, I'm not saying the current behaviour is sensible, but I doubt the work to fix it will benefit anyone in practice. Paul. From jsbueno at python.org.br Wed Mar 5 14:40:45 2014 From: jsbueno at python.org.br (Joao S. O. Bueno) Date: Wed, 5 Mar 2014 10:40:45 -0300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051259.40289.shai@platonix.com> <201403051510.54769.shai@platonix.com> Message-ID: I agree this change would cause far more good than harm - I see that it implies an incompatible change, but lets think on "Although practicality beats purity" terms here: the only instance I see this could possibly be used by purpose is in a code to that would increase a "day counter" if the time.now() would evaluate to false. Such a piece of code would be broken in many other levels to start with. A critical session in any piece of code that has to check if "at this second now we are at midnight" should be using one of the specialized timers to take care of borderline cases, such as start and ending of D.S.T. and such. It would have to be orders of magnitude better written than "if not current_time: ... " And even in the improbable case of such a piece of code exists, the changing of behavior would make it break in the first 24 hours, and the problem would not be that hard to find out. In this light, I think having to wait for 3 major release cycles until that is gone is a lot of overkill. On 5 March 2014 10:26, Paul Moore wrote: > On 5 March 2014 13:10, Shai Berger wrote: >> On Wednesday 05 March 2014 14:54:27 Paul Moore wrote: >>> >>> And FWIW, my opinion is that the problem is not worth a compatibility >>> break, because it's so easily solved (and the fixed code is probably >>> an improvement in any case). >> >> Ah, but it is only easily solved once it is detected; the behavior causes bugs >> that surface once in a blue moon (in production, and then they cannot be >> reproduced by developers who, usually, do not work at midnight). > > That's a fair point. But your deprecation suggestion doesn't seem to > help this, unless you expect (in a realistic timescale) to be able to > drop support for Python <3.7. Your users (on say 2.7 or 3.3) will > still get bugs, and now your developers (using 3.7) won't even be able > to reproduce the issue by staying up till midnight. And once they do > find the bug they will still have to fix it by an explicit test. > > Again, I'm not saying the current behaviour is sensible, but I doubt > the work to fix it will benefit anyone in practice. > > Paul. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From stefan at bytereef.org Wed Mar 5 14:39:42 2014 From: stefan at bytereef.org (Stefan Krah) Date: Wed, 5 Mar 2014 13:39:42 +0000 (UTC) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: Steven D'Aprano: > > I don't agree with Mark's proposal in this thread but I would like to > > have decimal literals e.g. 1.23d, > > +1 on that. Although that will depend on how big a slowdown it causes to > Python's startup time. Startup time should not be a problem once http://bugs.python.org/issue19232 is dealt with. Stefan Krah From ncoghlan at gmail.com Wed Mar 5 14:45:33 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 5 Mar 2014 23:45:33 +1000 Subject: [Python-ideas] Suggestion for standardized annotations In-Reply-To: References: Message-ID: On 5 Mar 2014 22:51, "Paul Moore" wrote: > > On 5 March 2014 11:53, Cem Karan wrote: > > Thoughts/suggestions? > > I think the core/stdlib position is that agreeing conventions would be > better done once some real world experience of the practical issues > and benefits of annotations has been established. MyPy uses function annotations for optional static typing, which is pretty much the use case Guido originally had in mind and the main reason that PEP 8 doesn't make combining annotations with an associated decorator mandatory: http://www.mypy-lang.org/ You do still have to import a particular module to indicate that all annotations in the importing module are to be interpreted as type annotations. Beyond that, the guidance in PEP 8 stands: """It is recommended that third party experiments with annotations use an associated decorator to indicate how the annotation should be interpreted.""" Cheers, Nick. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Wed Mar 5 14:56:46 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 00:56:46 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> Message-ID: <20140305135646.GB28804@ando> On Tue, Mar 04, 2014 at 07:42:28PM -0800, Mark H. Harris wrote: > The idea of *python number* means that there are no types, no limits, no > constraints, and that all *python numbers *are dynamic. The upper level > syntax is also very simple; all* python numbers *are simply human. What makes this a "python number"? In what way are they "dynamic"? > My influence for this preference is rooted in the Rexx programming > language; attributed to Mike Cowlishaw, former IBM fellow. The Rexx > programming language is dynamic, and has no types. To put it more > succinctly for those of you who have not used Rexx, the only data type > is a string of characters (that's it). *Rexx numbers* are simply those > strings of characters that may be interpreted as a valid *Rexx number.* I haven't used Rexx, but I have used Hypertalk, which worked the same way. If you don't care about performance, it can work quite well. > The Python language might be changed to adopt the *python number* > concept for *all math processing*, unless explicitly modified. Well, there's a bit of a problem here. Numbers in Python are not just used for maths processing. They're also used for indexing into lists, as keys in dicts, for bitwise operations, for compatibility with external libraries that have to interface with other languages, as flags, etc. For some of these purposes, we *really do* want to distinguish between ints and floats that happen to have the same value: mylist[3] # allowed mylist[3.0] # not allowed Now, you might argue that this distinction is unnecessary, but it runs quite deep in Python. You'd need to change that philosophy for this idea to work. > This goes > somewhat beyond using decimal floating point as a default numerical > type. It means using human numeric expressions that meet human > expectation for numeric processing by default. I don't understand what that means, unless it means that you want Python to somehow, magically, make all the unintuitive issues with floating point to disappear. Good luck with that one. If you want that, Decimal is not the answer. It would have to be a Rational type, like Fraction, although even that doesn't support surds. Fractions have their own problems too. Compare the status quo: py> 3**0.5 1.7320508075688772 with a hypothetical version that treats all numbers as exact fractions: py> 3**0.5 Fraction(3900231685776981, 2251799813685248) Which do you think the average person using Python as a calculator would prefer to see? And another issue: before he invented Python, Guido spent a lot of time working with ABC, which used Fractions as the native number type. The experience soured him on the idea for nearly two decades. Although Guido has softened his stance enough to allow the fractions module into the standard library, I doubt he would allow Fractions to become the underlying implementation of numbers in Python. The problem is that fractions can be unbounded in memory, and some simple operations become extremely inefficient. For example, without converting to float, which is bigger? Fraction(296, 701) Fraction(355, 594) For many purposes, the fact that floats (whether binary or decimal) have finite precision and hence introduce rounding error is actually a good thing. Compare: py> 1e-300 + 1e300 1e+300 versus fractions: py> from fractions import Fraction as F py> F(10)**-300 + F(10)**300 Fraction(100000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000001, 100000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000) There are *very few* applications where such precision is needed or wanted. The performance hit in calculating such excessively precise numbers when the user doesn't need it will be painful. The same applies to Decimal, although to a lesser extent since Decimals do have a finite precision. Unlike fractions, they cannot grow without limit: py> Decimal("1e-300") + Decimal("1e300") Decimal('1.000000000000000000000000000E+300') -- Steven From shai at platonix.com Wed Mar 5 14:53:19 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 15:53:19 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051510.54769.shai@platonix.com> Message-ID: <201403051553.19311.shai@platonix.com> On Wednesday 05 March 2014 15:26:38 Paul Moore wrote: > On 5 March 2014 13:10, Shai Berger wrote: > > On Wednesday 05 March 2014 14:54:27 Paul Moore wrote: > >> And FWIW, my opinion is that the problem is not worth a compatibility > >> break, because it's so easily solved (and the fixed code is probably > >> an improvement in any case). > > > > Ah, but it is only easily solved once it is detected; the behavior causes > > bugs that surface once in a blue moon (in production, and then they > > cannot be reproduced by developers who, usually, do not work at > > midnight). > > That's a fair point. But your deprecation suggestion doesn't seem to > help this, unless you expect (in a realistic timescale) to be able to > drop support for Python <3.7. I expect to drop support for Python<3.7 sometime... > Your users (on say 2.7 or 3.3) will > still get bugs, and now your developers (using 3.7) won't even be able > to reproduce the issue by staying up till midnight. If my developers are using 3.7 to debug problems that user encounter with 3.3, they deserve to stay up till midnight and beyond. > And once they do > find the bug they will still have to fix it by an explicit test. The process I want to see is, that Boolean evaluations of time objects is slowly, but more-or-less completely removed from code that targets Python<3.7; then, in a few years, people can go back to writing "if event.start_time" like they do with dates and datetimes. > Again, I'm not saying the current behaviour is sensible, but I doubt > the work to fix it will benefit anyone in practice. > So, you support my other suggestion -- a warning on every use of bool(time)? Also, the work to fix it is probably less than the work invested in this discussion so far... In any case, if we all agree that http://bugs.python.org/issue13936 is a valid problem -- can we re-open it, and then discuss how (or if) we solve it? Thanks, Shai. From skip at pobox.com Wed Mar 5 15:34:16 2014 From: skip at pobox.com (Skip Montanaro) Date: Wed, 5 Mar 2014 08:34:16 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: On Wed, Mar 5, 2014 at 4:44 AM, Paul Moore wrote: >> if event.start_time: >> # stuff >> >> unexpectedly fails if start_time is midnight. > > Yeah, I was classing that as "application bug" and it's easy to fix > with an "is not None". +1, +1, +1. This is nothing more than an application bug. Issue 13936 should not be reopened. This is a very common mistake when None is used as a sentinel value (though people normally get away with it), especially by people coming from languages having NULL pointers which shall not be named. After all, "None" and "NULL" both start with the letter "N". Surely, they must represent the same fundamental concept, right? Let's change the problem slightly. Instead of time objects, let's consider the domain of possible values to be integers. Clearly, None is not a member of that set. You could thus use it as a sentinel. So, tell me, OP. Would this usage be correct? if event.some_id: # stuff I would argue, "no." I would not argue that 0 should not compare as False, however. I would fix my code: if event.some_id is not None: # stuff In contexts where None is an element of the set of possible values (and thus can't be used as a sentinel value itself), it's common to explicitly create such a (unique) value, e.g.: SENTINEL = ["xyz"] # or [None] or {} or set([sys]) or ..., but not () or 1 or True! When you check for the sentinel you have to be explicit (and you MUST check for it using the "is" operator, to drag in another recent thread): if something is SENTINEL: mix_the_special_sauce() Using None as a sentinel value is no different, it just happens to a) already exist, and b) be unique, saving you an exceedingly small amount of typing. If you were trying to be terribly clever, there are lots of other values in Python (at least in CPython) which happen to be unique (the empty tuple, small integers, True and False, ...), and could thus theoretically be used as a sentinel. Someone would eventually slap your wrist for that sort of thing though (one would hope). Two final points. 1. If you wanted to modify the language (or the standard library) in some way, perhaps the more theoretically reasonable request would be to ask that None not be usable in a boolean context. Making that change would certainly break a lot of code though, so it's too late to do that. 2. The more I think about it, the more I think None should not be used as a sentinel. Skip From p.f.moore at gmail.com Wed Mar 5 16:01:33 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 15:01:33 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051553.19311.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051510.54769.shai@platonix.com> <201403051553.19311.shai@platonix.com> Message-ID: On 5 March 2014 13:53, Shai Berger wrote: > then, in a few years, people can go back to writing "if event.start_time" like > they do with dates and datetimes. Why on earth would they do that? It's still bad practice. If you're using None as a sentinel, you should test for it explicitly. Nobody has yet suggested any other use case where this matters. >> Again, I'm not saying the current behaviour is sensible, but I doubt >> the work to fix it will benefit anyone in practice. >> > > So, you support my other suggestion -- a warning on every use of bool(time)? No. Good programming practice should cover that. We don't warn in other cases where programmers make silly coding errors. Look at Skip's message - should we also warn on uses of bool(int) because people can write bad code that fails to work properly with zero, as well? > Also, the work to fix it is probably less than the work invested in this > discussion so far... That is not obvious (given documentation, release management, etc, costs). > In any case, if we all agree that http://bugs.python.org/issue13936 is a valid > problem -- can we re-open it, and then discuss how (or if) we solve it? We don't. Can we agree that it's not a bug and abandon this fruitless discussion? Paul From kaiser.yann at gmail.com Wed Mar 5 16:08:02 2014 From: kaiser.yann at gmail.com (Yann Kaiser) Date: Wed, 5 Mar 2014 16:08:02 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: On 5 March 2014 15:34, Skip Montanaro wrote: > On Wed, Mar 5, 2014 at 4:44 AM, Paul Moore wrote: >>> if event.start_time: >>> # stuff >>> >>> unexpectedly fails if start_time is midnight. >> >> Yeah, I was classing that as "application bug" and it's easy to fix >> with an "is not None". > > +1, +1, +1. This is nothing more than an application bug. Issue 13936 > should not be reopened. > > This is a very common mistake when None is used as a sentinel value > (though people normally get away with it), especially by people coming > from languages having NULL pointers which shall not be named. After > all, "None" and "NULL" both start with the letter "N". Surely, they > must represent the same fundamental concept, right? > > Let's change the problem slightly. Instead of time objects, let's > consider the domain of possible values to be integers. Clearly, None > is not a member of that set. You could thus use it as a sentinel. So, > tell me, OP. Would this usage be correct? > > if event.some_id: > # stuff > > I would argue, "no." I would not argue that 0 should not compare as > False, however. You come up with an instance where 0 clearly does not apply as something to incur a different branch, which is very apparent in just reading the line, so very easy to spot as a mistake. But this 0 isn't a real zero. It's just a unique identifier that happens to be implemented as an integer(because it's convenient for your database, iterators and whatnot.) Let me show you an actual zero: if event.num_attendants: prepare_cake() else: cancel_event() When no one is coming to your party, is is clearly a different condition than if any number of people are coming to your event. When you read "if num_attendants", you can clearly tell this is going to do something depending on if people are coming or not. Let's read this line: if not event.date: How would you read it, knowing nothing about date objects? I would read it to mean "has no date been set?" and would naturally continue the code as such: if event.date: schedule_event() I cannot fathom one example where it could read as "does the party start at midnight?". Can you? From breamoreboy at yahoo.co.uk Wed Mar 5 16:10:28 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 15:10:28 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051510.54769.shai@platonix.com> <201403051553.19311.shai@platonix.com> Message-ID: On 05/03/2014 15:01, Paul Moore wrote: > On 5 March 2014 13:53, Shai Berger wrote: >> then, in a few years, people can go back to writing "if event.start_time" like >> they do with dates and datetimes. > > Why on earth would they do that? It's still bad practice. If you're > using None as a sentinel, you should test for it explicitly. Nobody > has yet suggested any other use case where this matters. > >>> Again, I'm not saying the current behaviour is sensible, but I doubt >>> the work to fix it will benefit anyone in practice. >>> >> >> So, you support my other suggestion -- a warning on every use of bool(time)? > > No. Good programming practice should cover that. We don't warn in > other cases where programmers make silly coding errors. Look at Skip's > message - should we also warn on uses of bool(int) because people can > write bad code that fails to work properly with zero, as well? > >> Also, the work to fix it is probably less than the work invested in this >> discussion so far... > > That is not obvious (given documentation, release management, etc, costs). > >> In any case, if we all agree that http://bugs.python.org/issue13936 is a valid >> problem -- can we re-open it, and then discuss how (or if) we solve it? > > We don't. Can we agree that it's not a bug and abandon this fruitless > discussion? > > Paul I wouldn't agree that this has been a fruitless discussion. I would agree that this is not a bug, that the code needs changing, and that at least one new test needs to be added to the unit test suite(s) for the buggy application(s). -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From shai at platonix.com Wed Mar 5 16:19:09 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 17:19:09 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051553.19311.shai@platonix.com> Message-ID: <201403051719.09276.shai@platonix.com> On Wednesday 05 March 2014 17:01:33 you wrote: > On 5 March 2014 13:53, Shai Berger wrote: > > >> Again, I'm not saying the current behaviour is sensible, but I doubt > >> the work to fix it will benefit anyone in practice. > > [...] > > In any case, if we all agree that http://bugs.python.org/issue13936 is a > > valid problem > > We don't. Can we agree that it's not a bug and abandon this fruitless > discussion? > What, other than "bug", do you call behavior that isn't sensible? From shai at platonix.com Wed Mar 5 16:15:29 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 17:15:29 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: <201403051715.29773.shai@platonix.com> On Wednesday 05 March 2014 16:34:16 Skip Montanaro wrote: > > Let's change the problem slightly. Instead of time objects, let's > consider the domain of possible values to be integers. Clearly, None > is not a member of that set. You could thus use it as a sentinel. So, > tell me, OP. Would this usage be correct? > > if event.some_id: > # stuff > > I would argue, "no." I would not argue that 0 should not compare as > False, however. What Yann said. Also, when opening this thread, I argued that 0 is special, but midnight is not -- which you completely ignore. Thanks, Shai. From rosuav at gmail.com Wed Mar 5 16:23:19 2014 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 6 Mar 2014 02:23:19 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: On Wed, Mar 5, 2014 at 11:56 PM, Oscar Benjamin wrote: > 3F could create a Fraction with the integer value 3 so that a/b gives > a rational number: > >>>> from fractions import Fraction as F >>>> a = 2 >>>> b = F(3) >>>> a/b > Fraction(2, 3) > > I don't understand why you say that can't be done. (Also Steven who said the same thing.) Uhh... brown-paper-bag moment. When I wrote up that post, I somehow blanked out the obvious fact that Fraction can happily represent an integer. Whoops... As Julia Jellicoe said, my objection falls to the ground. Very well! ChrisA From steve at pearwood.info Wed Mar 5 16:35:29 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 02:35:29 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: <20140305153529.GC28804@ando> On Wed, Mar 05, 2014 at 12:41:10PM +0000, Carl Smith wrote: > Just for the record, I never called them bills just because they contain a > dollar sign! I was thinking of a short word which describes an expression > who's evaluation changes depending on the local circumstances. Like a legal > bill, not a dollar bill. Hmmm. Well, I don't really get the connection between legal bills and delayed evaluation, and I still really dislike the name. > The name macro doesn't really work, as it's only an expression, it's not a > code block. There is nothing about macros that *require* them to accept a full block of code. In fact, there are multiple different meanings for macro, although they are all related they do have significant differences: http://en.wikipedia.org/wiki/Macro_%28computer_science%29 Macros in C are not the same kind of thing as macros in Lisp. > --- > > The idea was never to start passing complex expressions around the place. What you consider a complex expression somebody else may consider a simple expression. Unless you want to demand some arbitrary hard limit on complexity (and how do you measure complexity?) this "bill" system would have to allow the exact same types of expressions that are legal elsewhere in Python. [...] > What the hell is a thunk anyway? It's a horrible name. Wikipedia is your friend: http://en.wikipedia.org/wiki/Thunk Also, more here: http://c2.com/cgi/wiki?CallByName The meaning of thunk I'm referring to comes from the call-by-name argument passing model. Suppose we pass an expression to a function: function(arg=x-1) and the body of the function looks like this: if arg > 1: y = arg + 1 else: y = arg - 1 return y*arg In the "call-by-name" model, the function body executes like this: if (x+1) > 1: y = (x+1) + 1 else: y = (x+1) - 1 return y*(x+1) which not only duplicates the "x+1" part four times, but may require evaluating it three times. To avoid this wasteful duplication, the compiler creates a special thunk value, which is something like a function with no arguments: def thunk(): if cache is None: cache = x-1 return cache (This should be considered pseudo-code, not the exact way Algol or Haskell work -- real thunks also allow you to assign a value back to the "name". Also, technically the presence of a cache makes it call-by-need rather than call-by-name). The body of the function then becomes: if thunk() > 1: y = thunk() + 1 else: y = thunk() - 1 return y*thunk() So as you can see, what I've been calling a thunk is not precisely like Algol thunks. One thing which is missing is the dynamic scoping: in the thunk evaluation, the x comes from the caller's scope. But the delayed evaluation part is quite similar, enough that I think the name may be appropriate. Another name for this might be a "promise", as in the promise to execute a computation later. -- Steven From p.f.moore at gmail.com Wed Mar 5 16:37:14 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 15:37:14 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051719.09276.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051553.19311.shai@platonix.com> <201403051719.09276.shai@platonix.com> Message-ID: On 5 March 2014 15:19, Shai Berger wrote: > What, other than "bug", do you call behavior that isn't sensible? "Unfortunate". I'm not arguing that the behaviour is useful. Or sensible. What I'm arguing, and you're missing, is that the behaviour is as documented, and so can't be changed without backward compatibility implications. Specifically, see http://docs.python.org/3.4/library/datetime.html#time-objects: """in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that's None), the result is non-zero.""" Your code is ignoring documented behaviour. Worse, your code can clearly be improved by being explicit in your test, and yet you'd rather argue that the Python developers implement a backward compatibility break which you won't even be able to take advantage of until you drop support of versions of Python before 3.7. Paul. From ron3200 at gmail.com Wed Mar 5 16:38:27 2014 From: ron3200 at gmail.com (Ron Adam) Date: Wed, 05 Mar 2014 09:38:27 -0600 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140305120410.GY28804@ando> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: On 03/05/2014 06:04 AM, Steven D'Aprano wrote: > (By the way, I think it is somewhat amusing that Python not only has a > built-in complex type, but also*syntax* for creating complex numbers, > but no built-in support for exact rationals.) That is interesting. I think Mark is correct in unifying numbers. And also adding in decimal features. The way it should actually be done is another thing. But having an up to date package that can be used is a very good start. (Thanks Mark!) Mark describes an AI approach,, which I think he means having a internal representation that may change as needed depending on how a number can best be stored and calculated while still keeping it's accuracy. Weather or not that approach is called Decimals is another thing. It might be called "Unified Numbers".. or just Numbers. The point is for the internal representation to be an implementation detail the user doesn't need to worry about. And have Decimal features available by default. If things are decided by use case, then I can't even think of a good enough argument against having decimal features available by default. The financial use cases are that overwhelming. -Ron From p.f.moore at gmail.com Wed Mar 5 16:42:32 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 15:42:32 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: On 5 March 2014 15:08, Yann Kaiser wrote: > Let me show you an actual zero: > > if event.num_attendants: > prepare_cake() > else: > cancel_event() > > When no one is coming to your party, is is clearly a different > condition than if any number of people are coming to your event. When > you read "if num_attendants", you can clearly tell this is going to do > something depending on if people are coming or not. I'm sorry, are you really trying to say that the above code is better than if event.num_attendants != 0: prepare_cake() else: cancel_event() ? (Personally, I'd actually prefer something like "if event.num_attendants > 0" or switch the order of clauses and test for being equal to 0, but that's a minor issue. The major point is I'd prefer any of these to your version). Paul From shai at platonix.com Wed Mar 5 17:05:15 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 18:05:15 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051719.09276.shai@platonix.com> Message-ID: <201403051805.15363.shai@platonix.com> On Wednesday 05 March 2014 17:37:14 Paul Moore wrote: > On 5 March 2014 15:19, Shai Berger wrote: > > What, other than "bug", do you call behavior that isn't sensible? > > "Unfortunate". That's unfortunate. You miss a lot of bugs. > I'm not arguing that the behaviour is useful. Or > sensible. What I'm arguing, and you're missing, is that the behaviour > is as documented, and so can't be changed without backward > compatibility implications. I think I have given ample room to backwards-compatibility considerations. > Specifically, see > http://docs.python.org/3.4/library/datetime.html#time-objects: > > """in Boolean contexts, a time object is considered to be true if and > only if, after converting it to minutes and subtracting utcoffset() > (or 0 if that's None), the result is non-zero.""" > Yes, I know. It's mentioned in the bug. > Your code is ignoring documented behaviour. Worse, your code can > clearly be improved by being explicit in your test, We disagree. I don't see adding "is not None" as an improvement at all. I see it as adding unnecessary ceremony. If you really like that much explicitness, use Java. > and yet you'd > rather argue that the Python developers implement a backward > compatibility break which you won't even be able to take advantage of > until you drop support of versions of Python before 3.7. > What Ryan said: The code in question will not benefit from this change; it is Python 2.7, and will probably be rewritten from scratch before anything comes out of this. This is about fixing my projects a decade from now. Shai. From ryan at ryanhiebert.com Wed Mar 5 16:50:04 2014 From: ryan at ryanhiebert.com (Ryan Hiebert) Date: Wed, 5 Mar 2014 09:50:04 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051553.19311.shai@platonix.com> <201403051719.09276.shai@platonix.com> Message-ID: On Wed, Mar 5, 2014 at 9:37 AM, Paul Moore wrote: > On 5 March 2014 15:19, Shai Berger wrote: > > What, other than "bug", do you call behavior that isn't sensible? > > "Unfortunate". I'm not arguing that the behaviour is useful. Or > sensible. What I'm arguing, and you're missing, is that the behaviour > is as documented, and so can't be changed without backward > compatibility implications. Specifically, see > http://docs.python.org/3.4/library/datetime.html#time-objects: > > """in Boolean contexts, a time object is considered to be true if and > only if, after converting it to minutes and subtracting utcoffset() > (or 0 if that's None), the result is non-zero.""" > > Your code is ignoring documented behaviour. Worse, your code can > clearly be improved by being explicit in your test, and yet you'd > rather argue that the Python developers implement a backward > compatibility break which you won't even be able to take advantage of > until you drop support of versions of Python before 3.7. > > Or, perhaps, even though he wouldn't be able to use this change right away, he'd just like to see Python be better. I can't see that there's going to come a better time to discuss this issue than the present, thus it seems to me that you're suggesting that this odd and illogical behavior continue forever, simply because it's been documented. The backward compatibility and migration path still need to be addressed, but it seems that we are disagreeing on whether this strange behavior should ever change. I think that, at some point, it should. If we ever agree on that, then we can start thinking about when. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at ryanhiebert.com Wed Mar 5 16:55:13 2014 From: ryan at ryanhiebert.com (Ryan Hiebert) Date: Wed, 5 Mar 2014 09:55:13 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: On Wed, Mar 5, 2014 at 9:42 AM, Paul Moore wrote: > On 5 March 2014 15:08, Yann Kaiser wrote: > > Let me show you an actual zero: > > > > if event.num_attendants: > > prepare_cake() > > else: > > cancel_event() > > > > When no one is coming to your party, is is clearly a different > > condition than if any number of people are coming to your event. When > > you read "if num_attendants", you can clearly tell this is going to do > > something depending on if people are coming or not. > > I'm sorry, are you really trying to say that the above code is better than > > if event.num_attendants != 0: > prepare_cake() > else: > cancel_event() > > ? > > (Personally, I'd actually prefer something like "if > event.num_attendants > 0" or switch the order of clauses and test for > being equal to 0, but that's a minor issue. The major point is I'd > prefer any of these to your version). I suspect you'd like the whole idea of empty collections and zeroes evaluating false to go away, to force this kind of style (one right way to do it and all). Some languages do that. Python isn't one of them. I can see both sides, but I like how Python can use empty lists and zeros as false values, and I often (but not always) write code that takes advantage of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From breamoreboy at yahoo.co.uk Wed Mar 5 17:19:28 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 16:19:28 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051719.09276.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051553.19311.shai@platonix.com> <201403051719.09276.shai@platonix.com> Message-ID: On 05/03/2014 15:19, Shai Berger wrote: > On Wednesday 05 March 2014 17:01:33 you wrote: >> On 5 March 2014 13:53, Shai Berger wrote: >> >>>> Again, I'm not saying the current behaviour is sensible, but I doubt >>>> the work to fix it will benefit anyone in practice. >>> > [...] >>> In any case, if we all agree that http://bugs.python.org/issue13936 is a >>> valid problem >> >> We don't. Can we agree that it's not a bug and abandon this fruitless >> discussion? >> > > What, other than "bug", do you call behavior that isn't sensible? Documented behaviour. As opposed to insanity: doing the same thing over and over again and expecting different results. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From rosuav at gmail.com Wed Mar 5 17:20:08 2014 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 6 Mar 2014 03:20:08 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051805.15363.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051719.09276.shai@platonix.com> <201403051805.15363.shai@platonix.com> Message-ID: On Thu, Mar 6, 2014 at 3:05 AM, Shai Berger wrote: > On Wednesday 05 March 2014 17:37:14 Paul Moore wrote: >> On 5 March 2014 15:19, Shai Berger wrote: >> > What, other than "bug", do you call behavior that isn't sensible? >> >> "Unfortunate". > > That's unfortunate. You miss a lot of bugs. A bug is something where behaviour differs from documentation or intent. Differing from expectation isn't necessarily a bug (although in the absence of clear docs or statement of intent, it could be called one), partly because expectations vary. When the bulk of programmers expect one thing and the code does another, it's probably a wart or misfeature, but if it's properly documented, it can't really be called a bug. In this case, I would say that it's a wart. The fact that one timestamp happens to be treated as zero is odd, and I wouldn't advocate it, but now that it's there and documented, it's not a bug. ChrisA From p.f.moore at gmail.com Wed Mar 5 17:24:16 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 16:24:16 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: On 5 March 2014 15:55, Ryan Hiebert wrote: > I suspect you'd like the whole idea of empty collections and zeroes > evaluating false to go away, to force this kind of style (one right way to > do it and all). Some languages do that. Python isn't one of them. Not really. I just found the particular example given to be confusing. I tend to use boolean tests when I think of something as a yes/no type of thing, and the variable name implies it. If the example had referred to "event.attendees" I would probably have been fine with the check as written. The attribute in that case could be any one of a boolean flag, a count, or a list of attendees. That's actually a reasonably plausible way of writing the test to allow for later changes to the event class API. The point here is that there's more to whether code is good than just a black and white "does it work" question. But we're way off topic now - I don't even have any assurance that the OP's code is trying to test for a None sentinel and hitting a bug because not all time values evaluate as True (but if that's *not* his code, he really should have pointed that out by now!) All I can say is that *if* that is what his code is, then I think that rewriting it with an explicit test is clearer, and I'm not convinced by his assertion that "fixing" Python is a better solution. > I can see both sides, but I like how Python can use empty lists and zeros as > false values, and I often (but not always) write code that takes advantage > of it. Agreed, but that doesn't mean that code taking advantage of this is never obfuscated or hard to maintain. Paul. PS One final point, and I'll say this one last time and then shut up. I have no objection to making Python better. Nor do I insist that backward compatibility should never be broken. Nor do I wish Python were Java. Nor do I discount the issue of hard to find bugs. But equally, I don't think Python is perfect, nor do I think that this behaviour is ideal. I also don't think that the core developers have infinite time, nor do I think that every wart in Python needs to be fixed. And I trust the core developers to make the right judgements most of the time. All anyone should infer from this discussion is that I don't think that reopening the bug report referred to by the OP is productive. (You may also assume from the fact that I will drop out of this discussion now, that I no longer think that this thread is particularly productive :-() From ryan at ryanhiebert.com Wed Mar 5 16:20:57 2014 From: ryan at ryanhiebert.com (Ryan Hiebert) Date: Wed, 5 Mar 2014 09:20:57 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051510.54769.shai@platonix.com> <201403051553.19311.shai@platonix.com> Message-ID: On Wed, Mar 5, 2014 at 9:01 AM, Paul Moore wrote: > On 5 March 2014 13:53, Shai Berger wrote: > > We don't. Can we agree that it's not a bug and abandon this fruitless > discussion. Please don't abandon this discussion. The behavior we're discussing is clearly illogical and useless. If we simply removed the __nonzero__ behavior, and it did what user-created types do, then it would perform as I would expect it to. Consider also that this time has no special significance, unlike the special cases of 0, (), {}, etc. This is true also for any arbitrarily zeroed unit, such as temperature (C or F), and including datetime, date, and time. Even zero in those cases (however that is defined) is simply an arbitrary point, and not the same as a nonzero value. This is completely illogical behavior, and, IMO, is a bug. Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Wed Mar 5 17:26:09 2014 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 6 Mar 2014 03:26:09 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: On Thu, Mar 6, 2014 at 2:55 AM, Ryan Hiebert wrote: > I suspect you'd like the whole idea of empty collections and zeroes > evaluating false to go away, to force this kind of style (one right way to > do it and all). Some languages do that. Python isn't one of them. > > I can see both sides, but I like how Python can use empty lists and zeros as > false values, and I often (but not always) write code that takes advantage > of it. The broad concept is: A thing is true, a non-thing is false. The question is, though, which things are actually non-things? Since Python doesn't have a concept of not storing anything into a variable, there has to be a thing that represents the state of not being a thing, so None should be false. Python's made the choice that an empty string is a non-thing, but other languages choose instead to have a separate "Nil" value and all strings are true. Same with lists, tuples, etc. Pike's choice is that the integer 0 is false, and anything else is true, so you distinguish between having a string and not-having a string, rather than between having a non-empty string and having an empty string. Simple design choice, and one that each language follows consistently. But if you truly want to abolish the confusion, you want REXX. In REXX, 0 is false and 1 is true, and everything else is error 34, "Logical value not 0 or 1". Is that really an improvement? Not in my opinion. ChrisA From shai at platonix.com Wed Mar 5 17:38:25 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 18:38:25 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> Message-ID: <201403051838.25342.shai@platonix.com> On Wednesday 05 March 2014 18:20:08 Chris Angelico wrote: > On Thu, Mar 6, 2014 at 3:05 AM, Shai Berger wrote: > > On Wednesday 05 March 2014 17:37:14 Paul Moore wrote: > >> On 5 March 2014 15:19, Shai Berger wrote: > >> > What, other than "bug", do you call behavior that isn't sensible? > >> > >> "Unfortunate". > > > > That's unfortunate. You miss a lot of bugs. > > A bug is something where behaviour differs from documentation or > intent. Differing from expectation isn't necessarily a bug (although > in the absence of clear docs or statement of intent, it could be > called one), partly because expectations vary. When the bulk of > programmers expect one thing and the code does another, it's probably > a wart or misfeature, but if it's properly documented, it can't really > be called a bug. > > In this case, I would say that it's a wart. Fine. That is, I'm not too interested in the semantics of English, but rather in the semantics of Python. So, I rephrase my request: Would anybody object to a silent warning issued whenever a time-object is evaluated as Boolean? Something along the lines of, "Evaluating time object as Boolean: Note that time(0,0,0) evaluates to False" A silent warning, IIUC, is only printed when requested -- so it won't get in anybody's way, but still provide a tool for avoiding the bug. It can be added into Python 3.5. It could probably be added to earlier versions, but for that we'd need to consider this a bug :) Shai. From rob.cliffe at btinternet.com Wed Mar 5 18:00:40 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Wed, 05 Mar 2014 17:00:40 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: <53175838.6020100@btinternet.com> On 05/03/2014 16:24, Paul Moore wrote: >> I can see both sides, but I like how Python can use empty lists and zeros as >> false values, and I often (but not always) write code that takes advantage >> of it. > Agreed, but that doesn't mean that code taking advantage of this is > never obfuscated or hard to maintain. > > Paul. I'm with Shai and Ryan on this one. There's no such thing as a perfect language, but that doesn't mean we shouldn't strive towards it. > > PS One final point, and I'll say this one last time and then shut up. > I have no objection to making Python better. Nor do I insist that > backward compatibility should never be broken. Nor do I wish Python > were Java. Nor do I discount the issue of hard to find bugs. But > equally, I don't think Python is perfect, nor do I think that this > behaviour is ideal. I also don't think that the core developers have > infinite time, nor do I think that every wart in Python needs to be > fixed. Good. In other words, each wart should be considered on its merits, and some may be worth fixing. Changes have been made to Python where the backward compatibility issue is far greater. In this case any code that would be broken by the change is already flawed, if not broken. And I find it hard to imagine that the development effort in making this change is anything other than minimal, _compared with other comparable changes_ (I'm not trying to minimise the undoubted effort required to make _any_ change no matter how small). Rob Cliffe > And I trust the core developers to make the right judgements > most of the time. All anyone should infer from this discussion is that > I don't think that reopening the bug report referred to by the OP is > productive. (You may also assume from the fact that I will drop out of > this discussion now, that I no longer think that this thread is > particularly productive :-() > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2247 / Virus Database: 3705/6652 - Release Date: 03/04/14 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip at pobox.com Wed Mar 5 18:09:11 2014 From: skip at pobox.com (Skip Montanaro) Date: Wed, 5 Mar 2014 11:09:11 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051715.29773.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: On Wed, Mar 5, 2014 at 9:15 AM, Shai Berger wrote: > Also, when opening this thread, I argued that 0 is special, > but midnight is not -- which you completely ignore. Zero is not different, at least when considered as an element of a set (of integers, in my example). What's important is that we have a set of values (either time objects or integers in these two examples) and need some way to specify a sentinel value. That sentinel must not be in the set of valid values. In both of these cases, None fills the bill. Note that the only reasonable relationship between None and either the set of all time objects or the set of all integers is that it is not a member of either set. Testing that membership by appealing to their value cast to a boolean is simply wrong. I'll push the argument just a bit further. Suppose you have an attribute which corresponds to the setting of a two-valued sensor external to your system. You choose to represent those two values in your program as True and False. You need a way to tell if any sensor inputs have been detected yet, or not, so you initialize the attribute with a sentinel value. I don't care what value you choose out of all the possible sentinel values available to you (None, [], ["xyz"], {}, 7, 0.0, etc), treating any of them as a boolean will be wrong. If you do, you will erroneously always believe that your sensor has produced a value. I have made this sort of mistake many times over the years, and seen other people do it as well. If what you really want to test is membership of a value in a set, be explicit about it. Skip From alexander.belopolsky at gmail.com Wed Mar 5 18:27:21 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 5 Mar 2014 12:27:21 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051838.25342.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> Message-ID: On Wed, Mar 5, 2014 at 11:38 AM, Shai Berger wrote: > So, I rephrase my request: Would anybody object to a silent warning issued > whenever a time-object is evaluated as Boolean? > I would. Users should not be penalized for using a documented behavior. There are legitimate uses for bool(midnight) being False. Midnight is special in many contexts. For example, it is uncertain whether midnight belongs to the previous or next day. If your application wants to group midnight differently from other times - it is perfectly fine to use "if dt.time()" instead of a more verbose "if dt.time() != datetime.time(0, 0)". -------------- next part -------------- An HTML attachment was scrubbed... URL: From amber.yust at gmail.com Wed Mar 5 18:27:27 2014 From: amber.yust at gmail.com (Amber Yust) Date: Wed, 05 Mar 2014 17:27:27 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: Let's turn this around. Aside from backwards compatibility, what benefit is there from having midnight evaluate as false? On Wednesday, March 5, 2014 9:09:50 AM, Skip Montanaro wrote: > On Wed, Mar 5, 2014 at 9:15 AM, Shai Berger wrote: > > Also, when opening this thread, I argued that 0 is special, > > but midnight is not -- which you completely ignore. > > Zero is not different, at least when considered as an element of a set > (of integers, in my example). What's important is that we have a set > of values (either time objects or integers in these two examples) and > need some way to specify a sentinel value. That sentinel must not be > in the set of valid values. In both of these cases, None fills the > bill. Note that the only reasonable relationship between None and > either the set of all time objects or the set of all integers is that > it is not a member of either set. Testing that membership by appealing > to their value cast to a boolean is simply wrong. > > I'll push the argument just a bit further. Suppose you have an > attribute which corresponds to the setting of a two-valued sensor > external to your system. You choose to represent those two values in > your program as True and False. You need a way to tell if any sensor > inputs have been detected yet, or not, so you initialize the attribute > with a sentinel value. I don't care what value you choose out of all > the possible sentinel values available to you (None, [], ["xyz"], {}, > 7, 0.0, etc), treating any of them as a boolean will be wrong. If you > do, you will erroneously always believe that your sensor has produced > a value. > > I have made this sort of mistake many times over the years, and seen > other people do it as well. If what you really want to test is > membership of a value in a set, be explicit about it. > > Skip > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shai at platonix.com Wed Mar 5 18:24:04 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 19:24:04 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: <201403051924.05252.shai@platonix.com> On Wednesday 05 March 2014 19:09:11 Skip Montanaro wrote: > On Wed, Mar 5, 2014 at 9:15 AM, Shai Berger wrote: > > Also, when opening this thread, I argued that 0 is special, > > but midnight is not -- which you completely ignore. > > Zero is not different, at least when considered as an element of a set > (of integers, in my example). What's important is that we have a set > of values (either time objects or integers in these two examples) and > need some way to specify a sentinel value. Your argument has merit, but is besides the point. As noted by many in this thread, the idiom "if obj:" for deciding on the existence of some value is quite common. We all know it doesn't always fit, because Python chose to make some objects falsey; however, when it does fit, it makes for succinct, clear, unceremonious code. If your argument is not that "if obj:" should never be used, except when obj actually is Boolean, please elaborate. At issue here is the fact that the idiom doesn't fit where one would expect that it should. Thanks, Shai. From ryan at ryanhiebert.com Wed Mar 5 17:38:56 2014 From: ryan at ryanhiebert.com (Ryan Hiebert) Date: Wed, 5 Mar 2014 10:38:56 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: On Wed, Mar 5, 2014 at 10:24 AM, Paul Moore wrote: > > PS One final point, and I'll say this one last time and then shut up. > I have no objection to making Python better. Nor do I insist that > backward compatibility should never be broken. Nor do I wish Python > were Java. Nor do I discount the issue of hard to find bugs. But > equally, I don't think Python is perfect, nor do I think that this > behaviour is ideal. I also don't think that the core developers have > infinite time, nor do I think that every wart in Python needs to be > fixed. And I trust the core developers to make the right judgements > most of the time. All anyone should infer from this discussion is that > I don't think that reopening the bug report referred to by the OP is > productive. (You may also assume from the fact that I will drop out of > this discussion now, that I no longer think that this thread is > particularly productive :-() > Thanks for bringing this up. Even assuming that this was accepted as a bug, it's an entirely separate discussion to decide whether worth fixing or if it's worth the dev's time. I make no assertion on that, as that's their time and not mine. I hold the developers with highest regard, even in my disagreement. Python is my language of choice because of the effort of these folks, and I thank them. This seems like it could be a simple enough bug that were it allowed, it would be a fix that even someone as inexperienced with Python's internals as myself could fix. If that's not true and the issue is that it's simply too much work to change, then it should be marked "wontfix" rather than "invalid", and that's a decision that I would not contest (at least not without a working patch). I, like you, suspect that I will be abandoning further involvement, as simply arguing won't change people's minds. -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Wed Mar 5 18:58:12 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 5 Mar 2014 17:58:12 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: On 5 March 2014 17:27, Amber Yust wrote: > Let's turn this around. Aside from backwards compatibility, what benefit is > there from having midnight evaluate as false? Zero cost. Any alternative must justify the cost of making the change. Simple as that. Quantify the cost of making the change (properly!) and describe the benefits in such a way as to justify those costs. Paul From shai at platonix.com Wed Mar 5 18:56:23 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 19:56:23 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051838.25342.shai@platonix.com> Message-ID: <201403051956.24081.shai@platonix.com> On Wednesday 05 March 2014 19:27:21 Alexander Belopolsky wrote: > On Wed, Mar 5, 2014 at 11:38 AM, Shai Berger wrote: > > So, I rephrase my request: Would anybody object to a silent warning > > issued whenever a time-object is evaluated as Boolean? > > I would. Users should not be penalized for using a documented behavior. Fair enough. I would also add the warning to the documentation, and call the behavior "deprecated" (even if no steps will be taken to actually remove it). > There are legitimate uses for bool(midnight) being False. Midnight is > special in many contexts. For example, it is uncertain whether midnight > belongs to the previous or next day. If your application wants to group > midnight differently from other times - it is perfectly fine to use "if > dt.time()" instead of a more verbose "if dt.time() != datetime.time(0, 0)". The question is: Of all the Python lines in existence, where a time is evaluated as Boolean, what percentage intends to capture midnight, and what percentage intends to capture an empty field; the latter is a (user) bug, and I suspect it is the much larger part. So even though there are legitimate uses for midnight being false, keeping things as they are is setting a trap for users. It is documented, but highly unintuitive (as evidenced by many messages on this thread). I think it best if the gotcha is removed, but if not, I ask at least to have a way to mitigate the problem. Thanks, Shai. From amber.yust at gmail.com Wed Mar 5 19:12:46 2014 From: amber.yust at gmail.com (Amber Yust) Date: Wed, 5 Mar 2014 10:12:46 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: I think this is the wrong stage to evaluate cost. After all, one of the tenets of open source is that the core devs don't have to be the source of all change. I see a difference between "this could be better, but the core devs aren't going to spend time on it" and "this should not change." It would be nice if those two were not conflated so much. On Mar 5, 2014 9:58 AM, "Paul Moore" wrote: > On 5 March 2014 17:27, Amber Yust wrote: > > Let's turn this around. Aside from backwards compatibility, what benefit > is > > there from having midnight evaluate as false? > > Zero cost. Any alternative must justify the cost of making the change. > Simple as that. Quantify the cost of making the change (properly!) and > describe the benefits in such a way as to justify those costs. > > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From breamoreboy at yahoo.co.uk Wed Mar 5 19:23:12 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 18:23:12 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: On 05/03/2014 18:12, Amber Yust wrote: > I think this is the wrong stage to evaluate cost. After all, one of the > tenets of open source is that the core devs don't have to be the source > of all change. > But the core devs have to review the change and ultimately decide whether or not to commit it. In this case it looks as if a patch would not be accepted, so why keep going on about it, especially when there's a known work around? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From amber.yust at gmail.com Wed Mar 5 19:26:59 2014 From: amber.yust at gmail.com (Amber Yust) Date: Wed, 5 Mar 2014 10:26:59 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: Where did you see an indication that a patch would not be accepted? On Mar 5, 2014 10:24 AM, "Mark Lawrence" wrote: > On 05/03/2014 18:12, Amber Yust wrote: > >> I think this is the wrong stage to evaluate cost. After all, one of the >> tenets of open source is that the core devs don't have to be the source >> of all change. >> >> > But the core devs have to review the change and ultimately decide whether > or not to commit it. In this case it looks as if a patch would not be > accepted, so why keep going on about it, especially when there's a known > work around? > > -- > My fellow Pythonistas, ask not what our language can do for you, ask what > you can do for our language. > > Mark Lawrence > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip at pobox.com Wed Mar 5 19:33:08 2014 From: skip at pobox.com (Skip Montanaro) Date: Wed, 5 Mar 2014 12:33:08 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051924.05252.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> <201403051924.05252.shai@platonix.com> Message-ID: On Wed, Mar 5, 2014 at 11:24 AM, Shai Berger wrote: > If your argument is not that "if obj:" should never be used, except > when obj actually is Boolean, please elaborate. My approach continues to be to consider the overall set of objects from which you draw values to assign to obj. Call that set V. If this expression is true: len([bool(x) for x in V]) == 1 then using "if obj:" might be valid (if the one "false" value of that set is some sort of distinguishing characteristic, as it often is). If, however, the length of that set is greater than one, you must be explicit in your conditional expressions. It is unfortunate for your purposes that bool(datetime.time(0, 0, 0)) is False, but it's a documented property of that object, and is highly unlikely to change. In your case V is None plus the set of all time objects. That has two values which evaluate to False, so "if obj:" is not appropriate. If, on the other hand, the set of all values is the set of all strings or the set of all integers or the set of all lists, then maybe the falsity of the zero values in those sets ("", 0, []) has some use. My last comment on this topic. I will invoke the Uncle Timmy rule (which I just made up). Never contradict a decision Uncle Timmy made. He had his reasons. They were very good reasons. They were almost certainly better than any reasons you can come up with as counterarguments. Deal with it. :-) Skip From shai at platonix.com Wed Mar 5 19:33:43 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 20:33:43 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: <201403052033.44162.shai@platonix.com> On Wednesday 05 March 2014 20:23:12 Mark Lawrence wrote: > On 05/03/2014 18:12, Amber Yust wrote: > > I think this is the wrong stage to evaluate cost. After all, one of the > > tenets of open source is that the core devs don't have to be the source > > of all change. > > But the core devs have to review the change and ultimately decide > whether or not to commit it. In this case it looks as if a patch would > not be accepted, so why keep going on about it, especially when there's > a known work around? As noted before, the workaround is trivial once you detect the problem. Detecting the problem is not easy. Shai. From shai at platonix.com Wed Mar 5 19:44:55 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 20:44:55 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> Message-ID: <201403052044.55720.shai@platonix.com> On Wednesday 05 March 2014 20:33:08 Skip Montanaro wrote: > On Wed, Mar 5, 2014 at 11:24 AM, Shai Berger wrote: > > If your argument is not that "if obj:" should never be used, except > > when obj actually is Boolean, please elaborate. > > My approach continues to be to consider the overall set of objects > from which you draw values to assign to obj. Call that set V. If this > expression is true: > > len([bool(x) for x in V]) == 1 > > then using "if obj:" might be valid (if the one "false" value of that > set is some sort of distinguishing characteristic, as it often > is). If, however, the length of that set is greater than one, you must > be explicit in your conditional expressions. No argument so far. > It is unfortunate for your purposes that bool(datetime.time(0, 0, 0)) is > False, but it's a documented property of that object, and is highly unlikely > to change. I think this is what's called 'begging the question' -- this discussion was not about the validity of boolean testing in general, but about the validity of this property of time objects. Yes, it's documented. I'm trying to make it change. There is a lot of support for that, and the opposition seems to be centered on "because it's documented" -- with the two exceptions being an edge use-case (actually checking midnight) and your call to authority below. It's a gotcha. Let's remove it. If we don't remove it, let's give ourselves a tool to detect it. > My last comment on this topic. I will invoke the Uncle Timmy rule > (which I just made up). Never contradict a decision Uncle Timmy > made. He had his reasons. They were very good reasons. They were > almost certainly better than any reasons you can come up with as > counterarguments. Deal with it. :-) > The reason he actually gave (on the ticket)? "because it's documented". Shai. From breamoreboy at yahoo.co.uk Wed Mar 5 19:47:02 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 18:47:02 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403052033.44162.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403052033.44162.shai@platonix.com> Message-ID: On 05/03/2014 18:33, Shai Berger wrote: > On Wednesday 05 March 2014 20:23:12 Mark Lawrence wrote: >> On 05/03/2014 18:12, Amber Yust wrote: >>> I think this is the wrong stage to evaluate cost. After all, one of the >>> tenets of open source is that the core devs don't have to be the source >>> of all change. >> >> But the core devs have to review the change and ultimately decide >> whether or not to commit it. In this case it looks as if a patch would >> not be accepted, so why keep going on about it, especially when there's >> a known work around? > > As noted before, the workaround is trivial once you detect the problem. > Detecting the problem is not easy. > > Shai. Use mocks in unit testing? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From breamoreboy at yahoo.co.uk Wed Mar 5 19:59:37 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 18:59:37 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: On 05/03/2014 18:26, Amber Yust wrote: > Where did you see an indication that a patch would not be accepted? > > On Mar 5, 2014 10:24 AM, "Mark Lawrence" > > wrote: > > On 05/03/2014 18:12, Amber Yust wrote: > > I think this is the wrong stage to evaluate cost. After all, one > of the > tenets of open source is that the core devs don't have to be the > source > of all change. > > > But the core devs have to review the change and ultimately decide > whether or not to commit it. In this case it looks as if a patch > would not be accepted, so why keep going on about it, especially > when there's a known work around? > > -- > My fellow Pythonistas, ask not what our language can do for you, ask > what you can do for our language. > > Mark Lawrence > > --- http://bugs.python.org/issue13936 has been closed as invalid and I don't see a rush of core devs backing this proposal. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From amber.yust at gmail.com Wed Mar 5 20:06:50 2014 From: amber.yust at gmail.com (Amber Yust) Date: Wed, 5 Mar 2014 11:06:50 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: It was closed by one or two individuals, and there has been significant comment since then. Asking to revisit a decision isn't crazy, and there have been reasonable suggestions made. I don't see a lack of core dev "jumping upon" as an active indication that patches would be rejected; merely that core devs are unlikely to produce such a patch themselves. On Mar 5, 2014 11:00 AM, "Mark Lawrence" wrote: > On 05/03/2014 18:26, Amber Yust wrote: > >> Where did you see an indication that a patch would not be accepted? >> >> On Mar 5, 2014 10:24 AM, "Mark Lawrence" >> > > wrote: >> >> On 05/03/2014 18:12, Amber Yust wrote: >> >> I think this is the wrong stage to evaluate cost. After all, one >> of the >> tenets of open source is that the core devs don't have to be the >> source >> of all change. >> >> >> But the core devs have to review the change and ultimately decide >> whether or not to commit it. In this case it looks as if a patch >> would not be accepted, so why keep going on about it, especially >> when there's a known work around? >> >> -- >> My fellow Pythonistas, ask not what our language can do for you, ask >> what you can do for our language. >> >> Mark Lawrence >> >> --- >> > > http://bugs.python.org/issue13936 has been closed as invalid and I don't > see a rush of core devs backing this proposal. > > -- > My fellow Pythonistas, ask not what our language can do for you, ask what > you can do for our language. > > Mark Lawrence > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From breamoreboy at yahoo.co.uk Wed Mar 5 20:19:11 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 19:19:11 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> Message-ID: On 05/03/2014 19:06, Amber Yust wrote: > It was closed by one or two individuals, and there has been significant > comment since then. Asking to revisit a decision isn't crazy, and there > have been reasonable suggestions made. I don't see a lack of core dev > "jumping upon" as an active indication that patches would be rejected; > merely that core devs are unlikely to produce such a patch themselves. > > On Mar 5, 2014 11:00 AM, "Mark Lawrence" > > wrote: > > On 05/03/2014 18:26, Amber Yust wrote: > > Where did you see an indication that a patch would not be accepted? > > On Mar 5, 2014 10:24 AM, "Mark Lawrence" > > >> > wrote: > > On 05/03/2014 18:12, Amber Yust wrote: > > I think this is the wrong stage to evaluate cost. After > all, one > of the > tenets of open source is that the core devs don't have > to be the > source > of all change. > > > But the core devs have to review the change and ultimately > decide > whether or not to commit it. In this case it looks as if a > patch > would not be accepted, so why keep going on about it, > especially > when there's a known work around? > > -- > My fellow Pythonistas, ask not what our language can do for > you, ask > what you can do for our language. > > Mark Lawrence > > --- > > http://bugs.python.org/__issue13936 > has been closed as invalid and I > don't see a rush of core devs backing this proposal. > There can be lots of comments by Her Majesty Queen Elizabeth II or President Obama but they don't really count unless they put forward arguments to pursuade the core devs to change their minds about this issue. I see no evidence here that this is likely to happen, or do the core devs all come to life at the same time as they're all in the same time zone? A patch can be placed on the issue but if a core dev reviews and it and decides not to commit it nothing happens? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From shai at platonix.com Wed Mar 5 20:18:37 2014 From: shai at platonix.com (Shai Berger) Date: Wed, 5 Mar 2014 21:18:37 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403052033.44162.shai@platonix.com> Message-ID: <201403052118.38295.shai@platonix.com> On Wednesday 05 March 2014 20:47:02 Mark Lawrence wrote: > On 05/03/2014 18:33, Shai Berger wrote: > > On Wednesday 05 March 2014 20:23:12 Mark Lawrence wrote: > >> On 05/03/2014 18:12, Amber Yust wrote: > >>> I think this is the wrong stage to evaluate cost. After all, one of the > >>> tenets of open source is that the core devs don't have to be the source > >>> of all change. > >> > >> But the core devs have to review the change and ultimately decide > >> whether or not to commit it. In this case it looks as if a patch would > >> not be accepted, so why keep going on about it, especially when there's > >> a known work around? > > > > As noted before, the workaround is trivial once you detect the problem. > > Detecting the problem is not easy. > > > > Shai. > > Use mocks in unit testing? Unless you're aware of the issue, you are not going to unit-test specifically for midnight. If you are aware, you don't need to detect it, you write "is not None". From steve at pearwood.info Wed Mar 5 20:24:19 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 06:24:19 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403052044.55720.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> Message-ID: <20140305192419.GD28804@ando> On Wed, Mar 05, 2014 at 08:44:55PM +0200, Shai Berger wrote: > > It is unfortunate for your purposes that bool(datetime.time(0, 0, 0)) is > > False, but it's a documented property of that object, and is highly unlikely > > to change. > > I think this is what's called 'begging the question' -- this discussion was > not about the validity of boolean testing in general, but about the validity > of this property of time objects. Yes, it's documented. I'm trying to make it > change. There is a lot of support for that, and the opposition seems to be > centered on "because it's documented" -- with the two exceptions being an edge > use-case (actually checking midnight) and your call to authority below. There are some very powerful practical reasons for leaving the status quo, namely backwards-compatibility and code-churn. These are real costs, not for the person who writes the patch, or the people who write the tests, and document the change. But these are potential costs for the millions of people using Python who may be *relying* on midnight being falsey, or nevertheless will have to change their code if this change occurs. There's also the argument from consistency: midnight is the zero point of the day, and zero is falsey. It would be surprising if something which is essentially zero became truthy. Compared to those costs, the benefits are insignificant. For library authors, they cannot take advantage of this new always-truthy time objects for probably eight or ten years, when they drop all support for any prior to 3.6 or 3.7. A tiny benefit, discounted even further because it is so far in the distance, versus significant costs. Application authors, only using a single version of Python, may be able to make use of this rather sooner: perhaps as little as three years from now. > It's a gotcha. Let's remove it. If we don't remove it, let's give ourselves a > tool to detect it. Um, it's easy to detect it. not time_obj returns True if time_obj is midnight and therefore falsey. -- Steven From cfkaran2 at gmail.com Wed Mar 5 20:24:57 2014 From: cfkaran2 at gmail.com (CFK) Date: Wed, 5 Mar 2014 14:24:57 -0500 Subject: [Python-ideas] Suggestion for standardized annotations In-Reply-To: References: Message-ID: On Wed, Mar 5, 2014 at 8:45 AM, Nick Coghlan wrote: > On 5 Mar 2014 22:51, "Paul Moore" wrote: > > > > On 5 March 2014 11:53, Cem Karan wrote: > > > Thoughts/suggestions? > > > > I think the core/stdlib position is that agreeing conventions would be > > better done once some real world experience of the practical issues > > and benefits of annotations has been established. > > MyPy uses function annotations for optional static typing, which is pretty > much the use case Guido originally had in mind and the main reason that PEP > 8 doesn't make combining annotations with an associated decorator > mandatory: http://www.mypy-lang.org/ > > You do still have to import a particular module to indicate that all > annotations in the importing module are to be interpreted as type > annotations. > > Beyond that, the guidance in PEP 8 stands: > > """It is recommended that third party experiments with annotations use an > associated decorator to indicate how the annotation should be > interpreted.""" > I like what all of you are suggesting; decorators are the way to go. If a project defines its own annotation decorators as sigtools.modifiers.annotate, mypy, or pyannodo, then it shouldn't be too hard for a project to add its own UUID to the annotation dictionary. I'll spend a little while this weekend seeing if I can come up with some proof-of-concept code to make this work in a portable way. If the signatures looked vaguely like the following: @type_annotation(some_arg, int) @return_type_annotation(int) def function(some_arg): pass Would that be appealing to everyone? One question though, are we allowed to modify a functions __annotation__ dictionary directly? I know that I can do it, I just don't know if it is discouraged. Thanks, Cem Karan -------------- next part -------------- An HTML attachment was scrubbed... URL: From breamoreboy at yahoo.co.uk Wed Mar 5 20:35:29 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 19:35:29 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403052118.38295.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403052033.44162.shai@platonix.com> <201403052118.38295.shai@platonix.com> Message-ID: On 05/03/2014 19:18, Shai Berger wrote: > On Wednesday 05 March 2014 20:47:02 Mark Lawrence wrote: >> On 05/03/2014 18:33, Shai Berger wrote: >>> On Wednesday 05 March 2014 20:23:12 Mark Lawrence wrote: >>>> On 05/03/2014 18:12, Amber Yust wrote: >>>>> I think this is the wrong stage to evaluate cost. After all, one of the >>>>> tenets of open source is that the core devs don't have to be the source >>>>> of all change. >>>> >>>> But the core devs have to review the change and ultimately decide >>>> whether or not to commit it. In this case it looks as if a patch would >>>> not be accepted, so why keep going on about it, especially when there's >>>> a known work around? >>> >>> As noted before, the workaround is trivial once you detect the problem. >>> Detecting the problem is not easy. >>> >>> Shai. >> >> Use mocks in unit testing? > > Unless you're aware of the issue, you are not going to unit-test specifically > for midnight. If you are aware, you don't need to detect it, you write "is not > None". So you have your solution. Good, now can we please move on as this is getting tedious. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From rymg19 at gmail.com Wed Mar 5 20:44:01 2014 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Wed, 5 Mar 2014 13:44:01 -0600 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: <20140305014611.GA4396@cskk.homeip.net> Message-ID: On Tue, Mar 4, 2014 at 8:36 PM, David Mertz wrote: > On Tue, Mar 4, 2014 at 5:46 PM, Cameron Simpson wrote: > >> > foo = 1 >> > a = $(foo + 1) >> Definitely nicer. Still irrationally uncomfortable about the "$" though. >> A thought, though it could break existing code (and nested tuples, alas): >> >> a = (( foo + 1 )) >> > > That looks like unresolvable ambiguity to me. I confess that I am more > comfortable with '$(...)' because I'm one of those folks who actually likes > bash, and uses that spelling often over there (where the meaning isn't the > *same* as this, but is enough similar for the meaning to carry over) > > But this is Python, which is 10x better. And besides, that syntax gives me GNU make nightmares. > Still, what does this mean? >> a = 3 + (( foo + 1 )) >> I think that would need to be a syntax error, because I can't see it being >> anything except nonsense otherwise. > > I see it as: Create an anonymous function object that adds foo to 1. Then, try and add 3 to that resulting object(which obviously would fail). It'd be kind of like: a = 3 + (lambda: foo+1) a.k.a: def myfunc(): return foo+1 a = 3+myfunc or(somewhat clearer in C++): SomeType a = 3 + [&]() { return foo+1; }; It's a bit more obvious of the error in the C++ example(or, at least to me). ... > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." -------------- next part -------------- An HTML attachment was scrubbed... URL: From haoyi.sg at gmail.com Wed Mar 5 20:50:36 2014 From: haoyi.sg at gmail.com (Haoyi Li) Date: Wed, 5 Mar 2014 11:50:36 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: <20140305014611.GA4396@cskk.homeip.net> Message-ID: > The idea was never to start passing complex expressions around the place. It was just to allow a function to take an expression containing about one or two names, and evaluate the expression internally, so this... > > func(lambda foo: foo > 0) > > ...can become... > > func($foo > 0) >>> from macropy.quick_lambda import macros, f, _ >>> map(f[_ + 1], [1, 2, 3]) [2, 3, 4] >From an external API, it seems exactly the same. From an internal point of view, you have to pass *foo* explicitly to the function you capture, but I'd argue that that's probably a good thing in the majority of cases. There are cases where you'd want to "evaluate the expression internally" to automagically inject identifiers into the scope of the expression, but those are few and far between. On Wed, Mar 5, 2014 at 11:44 AM, Ryan Gonzalez wrote: > On Tue, Mar 4, 2014 at 8:36 PM, David Mertz wrote: > >> On Tue, Mar 4, 2014 at 5:46 PM, Cameron Simpson wrote: >> >>> > foo = 1 >>> > a = $(foo + 1) >>> Definitely nicer. Still irrationally uncomfortable about the "$" though. >>> A thought, though it could break existing code (and nested tuples, alas): >>> >>> a = (( foo + 1 )) >>> >> >> That looks like unresolvable ambiguity to me. I confess that I am more >> comfortable with '$(...)' because I'm one of those folks who actually likes >> bash, and uses that spelling often over there (where the meaning isn't the >> *same* as this, but is enough similar for the meaning to carry over) >> >> > > But this is Python, which is 10x better. And besides, that syntax gives me > GNU make nightmares. > > >> Still, what does this mean? >>> a = 3 + (( foo + 1 )) >>> I think that would need to be a syntax error, because I can't see it >>> being >>> anything except nonsense otherwise. >> >> > I see it as: > > Create an anonymous function object that adds foo to 1. Then, try and add > 3 to that resulting object(which obviously would fail). It'd be kind of > like: > > a = 3 + (lambda: foo+1) > > a.k.a: > > def myfunc(): return foo+1 > a = 3+myfunc > > or(somewhat clearer in C++): > > SomeType a = 3 + [&]() { return foo+1; }; > > It's a bit more obvious of the error in the C++ example(or, at least to > me). > > ... >> -- >> Keeping medicines from the bloodstreams of the sick; food >> from the bellies of the hungry; books from the hands of the >> uneducated; technology from the underdeveloped; and putting >> advocates of freedom in prisons. Intellectual property is >> to the 21st century what the slave trade was to the 16th. >> > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Wed Mar 5 21:30:23 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Wed, 5 Mar 2014 12:30:23 -0800 (PST) Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <20140305112532.GV28804@ando> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> <6939FECB-867D-46EC-B5D2-737DA205590D@yahoo.com> <20140305112532.GV28804@ando> Message-ID: <1394051423.82411.YahooMailNeo@web181001.mail.ne1.yahoo.com> From: Steven D'Aprano Sent: Wednesday, March 5, 2014 3:25 AM > On Tue, Mar 04, 2014 at 05:05:39PM -0800, Andrew Barnert wrote: >> On Mar 4, 2014, at 14:31, Greg Ewing > wrote: >> >> > Steven D'Aprano wrote: >> >> What I have in my head is some vague concept that the Python > evaluation rules will somehow know when to evaluate the thunk and when to treat > it as an object, which is (as I understand it) what happens in Algol. >> > >> > But Algol has the benefit of static typing -- the procedure >> > being called explicitly declares whether the argument is to >> > be passed by name or value. Python has no idea about that at >> > compile time. > > I'm not convinced that this really matters, but for the sake of the > argument let's say it does. It's not really static typing that's key here; it's that, unless you have explicit syntax for all uses of thunks, you either need implicit type casts, and static typing is necessary for implicit type casts. (However, as I said before, this?doesn't have to be a deal-breaker. You can probably get away with making all references either immediate or delayed, so long as the syntax for doing the other explicitly?isn't too obtrusive and the performance cost isn't too high. For example, if referencing a thunk always evaluates, `thunk` just creates a new thunk that will evaluate the old one, and you could optimize that into not much heavier than just passing the old one around?with a JIT, like PyPy, you could even optimize it into just passing the old one around.) >> This is the main reason I think it's more productive to think of this >> in terms of Lisp-style quoting than Algol-style thunks. > > Can you give more detail please? I think I've already explained it, but let me try again in more detail. A quoted expression and a thunk are similar things: ways to turn a language expression into something that can be evaluated or executed later. But there are two major differences. First, quoted expressions are first-class values, while thunks are not. Second, quoted expressions have an inspectable (or pattern-matchable) structure, while thunks do not. You could relate that second difference to ASTs vs. code objects in Python?but since idiomatic Python does not use macros or any other generation or parsing of ASTs, it really isn't a visible difference, so the first one is more important.* And then there's the historical difference: thunks come from static languages, quoting from dynamic languages. Together with being first-class values,?this means quoted expressions need explicit but not-too-intrusive syntax not just for creating them, but also either for evaluating them, or for continuing to delay them. So, that's why I think quoting is a more apt model for what we're trying to accomplish in this thread. * As I mentioned before, it does actually matter for _implementation_ whether we use ASTs or code objects, at least if we want dynamic or flat in-place scoping, because the former would allow us to look up names at execution time, while the latter would not, unless we either add a LOAD_DYNAMIC opcode or compile name lookup into explicit dynamic lookup code. But as long as we define what the scoping rules are, users won't care how that's implemented. From abarnert at yahoo.com Wed Mar 5 21:32:38 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Wed, 5 Mar 2014 12:32:38 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> Message-ID: <1394051558.18502.YahooMailNeo@web181005.mail.ne1.yahoo.com> From: Oscar Benjamin Sent: Wednesday, March 5, 2014 3:29 AM > On 5 March 2014 08:10, Andrew Barnert wrote: >> From: Mark H. Harris >>> >>> ? I am expecting that (just as in Rexx numbers) defining very clearly > what >>> is a python number? will be key for wide adaptation of the concept. But > there >>> should be no surprises for users, particularly average users. Anyone > with >>> a middle school expectation of a numeric format should be able to use >>> python numbers without surprises. >> >> Anyone with a middle school expectation will expect 1/3 to be a > fraction--or, at least, something they can multiply by 3 to get exactly 1. Using > an inexact decimal float instead of an inexact binary float is no improvement at > all. > > I actually think that it is an improvement. Most people are surprised > by the fact that just writing x = 0.1 causes a rounding error. Python > only has dedicated syntax for specifying binary floats in terms of > decimal digits meaning that there is no syntax for exactly specifying > non integer numbers. I would say that that is clearly a sub-optimal > situation. > > I don't agree with Mark's proposal in this thread but I would like to > have decimal literals e.g. 1.23d, and I would also use Fraction > literals if available e.g. 1/3F. I agree with you completely on that. That's kind of my point?your suggestion is almost the _opposite_ of the proposal in this thread. You want to make it easier for people to use the appropriate type for each use case; he wants to eliminate that choice entirely so you never have to make it. The latter would be nice if it were doable, but it's not even possible in principle. So the former is the best choice. From bruce at leapyear.org Wed Mar 5 22:04:56 2014 From: bruce at leapyear.org (Bruce Leban) Date: Wed, 5 Mar 2014 13:04:56 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140305192419.GD28804@ando> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Wed, Mar 5, 2014 at 11:24 AM, Steven D'Aprano wrote: > There's also the argument from consistency: midnight is the zero point > of the day, and zero is falsey. It would be surprising if something > which is essentially zero became truthy. > I don't think it's consistent now. In Boolean contexts ... - a timedelta object is considered to be true if and only if it isn't equal to timedelta(0). - all date objects are considered to be true. - all datetime objects are considered to be true. - a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that's None), the result is non-zero. And the documentation is not exactly clear for understanding when a time object is falsey. In particular, the "converting it to minutes" part seems irrelevant as a time of 1 microsecond from midnight is truthy and timedeltas are not numbers and are not in minutes. Perhaps a reasonable improvement would be to change this to: - a time object is considered to be true unless it represents exactly midnight local time, that is, it's false if subtracting the utcoffset() from the time produces an all-zero result (or it's all-zero to start with if the utcoffset is None). --- Bruce Learn how hackers think: http://j.mp/gruyere-security https://www.linkedin.com/in/bruceleban -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Wed Mar 5 22:10:12 2014 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 5 Mar 2014 21:10:12 +0000 (UTC) Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight References: <201403051216.12392.shai@platonix.com> Message-ID: Shai Berger writes: > > Hi all, > > This is my first post here, following a recommendation from Alexander > Belopolsky to use this list, to try to convince the Python developers to > reopen a ticket. I am a long-time Python user, and a Django committer. > > http://bugs.python.org/issue13936 is a complaint about the fact that midnight I strongly support fixing this issue. This behavior is so fundamentally nonsensical that resolving it is worth the potential compatibility issues. First, I'd like to dispense with the notion that ``if foo`` is somehow a bad practice. This is an EXTREMELY common practice as a shorthand for checking for None, a great many people consider it more idiomatic, this really isn't a place to bikeshed that particlar idiom. Now I'd like to address whether this is correct behavior: midnight is not a special time. It does not differ from other times in magnitutde (as with a container), it is not equivilant to the False value (as with 0). It is simply, sometimes, represented as 00:00:00 (or 12:00:00!). The fact that it's representation is composed of zeros no more makes it false than the point in 3-space at (0, 0, 0) is false. It's still a completely normal time, which in no way distinguishes itself from any other. I don't have a strong perspective on what the exact deprecation or breakage cycle should like, but it's very clear to me that this behavior is nonsensical. Out of a sample of half-a-dozen python programmers I've told about this, the *universal* response was confusion and revulsion. I strongly suspect that the majority of people writing ``if time_object`` have a bug in their code. Alex From ron3200 at gmail.com Wed Mar 5 22:13:29 2014 From: ron3200 at gmail.com (Ron Adam) Date: Wed, 05 Mar 2014 15:13:29 -0600 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <1394051558.18502.YahooMailNeo@web181005.mail.ne1.yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <1394051558.18502.YahooMailNeo@web181005.mail.ne1.yahoo.com> Message-ID: On 03/05/2014 02:32 PM, Andrew Barnert wrote: >>> I don't agree with Mark's proposal in this thread but I would like >>> to have decimal literals e.g. 1.23d, and I would also use Fraction >>> literals if available e.g. 1/3F. > > I agree with you completely on that. That's kind of my point?your > suggestion is almost the_opposite_ of the proposal in this thread. You > want to make it easier for people to use the appropriate type for each > use case; he wants to eliminate that choice entirely so you never have > to make it. The latter would be nice if it were doable, but it's not > even possible in principle. So the former is the best choice. It's also a matter of how far in the future you are looking. If he waited until later to propose something like this, it most likely wouldn't get in. I'm not sure he's expecting a firm answer now, but probably is hoping for a "hey lets look into this more and see if it's really possible" kind of maybe. For that, it's good to start early. On the near term, adding literal syntax's as you describe here would get all the pieces into python. Then an import from future could enable what Mark is thinking. He really needs to flesh out the details first before we can make any objective opinions about how it would actually work. The way I see it, with a unified number type, we will still need context like api's to get the more specialised behaviours. The difference may be a decorator on a function that specifies some subset of number types to use rather than notating each literal and casting each value. @numbers(int, decimal) def acounting_foo(...): ... # using ints for integers # using decimal for reals ... That just a guess... maybe Mark can give some examples how what he's proposing would work. ? Cheers, Ron From mertz at gnosis.cx Wed Mar 5 22:20:59 2014 From: mertz at gnosis.cx (David Mertz) Date: Wed, 5 Mar 2014 13:20:59 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <20140305114344.GX28804@ando> References: <20140305034945.GA67087@cskk.homeip.net> <20140305114344.GX28804@ando> Message-ID: On Wed, Mar 5, 2014 at 3:43 AM, Steven D'Aprano wrote: > >That is, what's really the point of having > > > > a = $(expr) # or `expr`, or `(expr), or c"expr" > > > > If it's simply a slightly shorter way of spelling: > > > > a = compile(expr, "", "eval") > > You can't write it like that. You have to wrap the expression is quotes > and turn it into a string: > > a = compile("expr", "", "eval") > True, I misspelled my example. Or maybe my 'expr' implicitly meant string_expr :-). But the basic point that the literal for a "thunk" is already essentially available with compile() remains. > which means you lose syntax highlighting. Perhaps the ability to get > syntax highlighting is not sufficient to justify this idea. > There's no reason you even NEED to lose syntax highlighting. A code editor could perfectly well have a highlight rule that strings inside compile() calls get highlighted. Sure, that's a pretty special language mode, but there's nothing that an editor couldn't do in principle. > Another disadvantage: the ever-present temptation to pass a > user-generated string to compile: > > a = compile(template % some_string, "", "eval") > > If some_string came from an untrusted source, you are now the proud > owner of a brand new code injection vulnerability. But with syntax, you > cannot generate a thunk/macro except from code you write yourself. It's > still code written by you, it's just that evaluation is delayed. > The literal hardly saves you from injection attacks. I could write this too under the proposed idea: foo = get_string_from_attacker() a = $(foo) b = a.eval() Now one can say "don't do that!" ... but that advice applies just as well to 'compile(unsafe_string, ...)' -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Wed Mar 5 22:31:36 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 16:31:36 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: On Mar 5, 2014, at 4:10 PM, Alex Gaynor wrote: > Shai Berger writes: > >> >> Hi all, >> >> This is my first post here, following a recommendation from Alexander >> Belopolsky to use this list, to try to convince the Python developers to >> reopen a ticket. I am a long-time Python user, and a Django committer. >> >> http://bugs.python.org/issue13936 is a complaint about the fact that midnight > > > I strongly support fixing this issue. This behavior is so fundamentally > nonsensical that resolving it is worth the potential compatibility issues. > > First, I'd like to dispense with the notion that ``if foo`` is somehow a bad > practice. This is an EXTREMELY common practice as a shorthand for checking for > None, a great many people consider it more idiomatic, this really isn't a place > to bikeshed that particlar idiom. > > Now I'd like to address whether this is correct behavior: midnight is not a > special time. It does not differ from other times in magnitutde (as with a > container), it is not equivilant to the False value (as with 0). It is simply, > sometimes, represented as 00:00:00 (or 12:00:00!). The fact that it's > representation is composed of zeros no more makes it false than the point in > 3-space at (0, 0, 0) is false. It's still a completely normal time, which in > no way distinguishes itself from any other. > > I don't have a strong perspective on what the exact deprecation or breakage > cycle should like, but it's very clear to me that this behavior is nonsensical. > Out of a sample of half-a-dozen python programmers I've told about this, the > *universal* response was confusion and revulsion. I strongly suspect that the > majority of people writing ``if time_object`` have a bug in their code. > > Alex > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ I completely agree with Alex here. This is a ridiculous behavior and it should be fixed. I find the argument that it would only be fixed in 3.something and thus not be really fixed for X years disingenuous at best. That fact is true for *ALL* bug fixes in Python so by that logic we should simply give up on fixing anything in Python ever? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rosuav at gmail.com Wed Mar 5 22:31:47 2014 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 6 Mar 2014 08:31:47 +1100 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: <20140305034945.GA67087@cskk.homeip.net> <20140305114344.GX28804@ando> Message-ID: On Thu, Mar 6, 2014 at 8:20 AM, David Mertz wrote: > The literal hardly saves you from injection attacks. I could write this too > under the proposed idea: > > foo = get_string_from_attacker() > a = $(foo) > b = a.eval() > > Now one can say "don't do that!" ... but that advice applies just as well to > 'compile(unsafe_string, ...)' That'll just be like doing: b = foo So it's still safe. That's the point. ChrisA From alexander.belopolsky at gmail.com Wed Mar 5 22:36:14 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 5 Mar 2014 16:36:14 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: On Wed, Mar 5, 2014 at 4:10 PM, Alex Gaynor wrote: > I strongly support fixing this issue. This behavior is so fundamentally > nonsensical that resolving it is worth the potential compatibility issues. > Does anyone know a language that (a) has a time-of-day class in stdlib; (b) allows instances of that class to be used in boolean context, and (c) has a midnight represented by an instance that is truthy? Here is my example of an entirely independent of Python language [1] that nevertheless has the same behavior for time-of-day objects: q)`boolean$00:00:00.000 0b q)`boolean$00:00:00.001 1b [1] http://code.kx.com/wiki/Reference/Datatypes -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Wed Mar 5 22:40:25 2014 From: mertz at gnosis.cx (David Mertz) Date: Wed, 5 Mar 2014 13:40:25 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: <20140305034945.GA67087@cskk.homeip.net> <20140305114344.GX28804@ando> Message-ID: On Wed, Mar 5, 2014 at 1:31 PM, Chris Angelico wrote: > On Thu, Mar 6, 2014 at 8:20 AM, David Mertz wrote: > > The literal hardly saves you from injection attacks. I could write this > too > > under the proposed idea: > > > > foo = get_string_from_attacker() > > a = $(foo) > > b = a.eval() > > > > Now one can say "don't do that!" ... but that advice applies just as > well to > > 'compile(unsafe_string, ...)' > > That'll just be like doing: > > b = foo > > So it's still safe. That's the point. > Doh! You are right. The literal does make it somewhat harder to shoot yourself in the foot with code injection, I had a thinko there. Still, advice in the docs not to do 'compile(untrusted_string, ...)' feels like it pretty much does what we actually need. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Wed Mar 5 22:50:06 2014 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 6 Mar 2014 08:50:06 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: On Thu, Mar 6, 2014 at 8:36 AM, Alexander Belopolsky wrote: > On Wed, Mar 5, 2014 at 4:10 PM, Alex Gaynor wrote: >> >> I strongly support fixing this issue. This behavior is so fundamentally >> nonsensical that resolving it is worth the potential compatibility issues. > > > Does anyone know a language that (a) has a time-of-day class in stdlib; (b) > allows > instances of that class to be used in boolean context, and (c) has a > midnight > represented by an instance that is truthy? Pike fits all three of those, but (c) is trivially true: any object in Pike is truthy. Of course, you can choose to represent time-of-day with an integer, in which case an integer of 0 will be false; but if you use floating-point (for sub-second accuracy), then it's still safe, because any float is truthy (even 0.0 - and if you think that's illogical, consider that expecting 0.0 to be false is effectively making an implicit equality comparison, with all the issues of equality comparisons on floats _plus_ the issues of doing that implicitly). If Python didn't have to worry about backward compatibility (that is, if this were being implemented new now), then I'd say a null time range should be false, but any date, datetime, or time, regardless of what it represents, is true. Maybe there could be a "null date" value that isn't a date, but None should be able to do that. ChrisA From greg.ewing at canterbury.ac.nz Wed Mar 5 22:51:13 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 10:51:13 +1300 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <05894993-3C4D-42E7-9328-C3365DF92CBE@masklinn.net> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> <05894993-3C4D-42E7-9328-C3365DF92CBE@masklinn.net> Message-ID: <53179C51.4020001@canterbury.ac.nz> Masklinn wrote: > On 2014-03-04, at 23:31 , Greg Ewing wrote: > >>But Algol has the benefit of static typing > > That's not really a blocker though, Haskell thunks are implicit and not > type-encoded. A name may correspond to a (unforced) thunk or to a strict > value That comes at the expense of making *everything* a thunk until its value is needed. This would be a big, far-reaching change in the way Python works. Also, Haskell has the advantage of knowing that the value won't change, so it can replace the thunk with its value once it's been calculated. Python would have to keep it as a thunk and reevaluate it every time. And Haskell doesn't have to provide a way of passimg the thunk around *without* evaluating it. -- Greg From mal at egenix.com Wed Mar 5 23:04:05 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 05 Mar 2014 23:04:05 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: <53179F55.3080501@egenix.com> I don't know what all the fuzz is about. There are lots of types in Python that evaluate to False in certain corner cases, e.g. "", (), [], {}, 0, 0.0, 0j, None, etc. datetime.time(0,0,0) is just another one :-) BTW: If you want to test for None, well, then do test for None and not for some property of None: if x is None: print ("x is None, which implies it's False") print ("Oh, and do note that the inverse is not necessarily true :-)") In logic: A -> B does not imply B -> A; it only implies (not B) -> (not A). in Python again: if bool(x) is not False: print ("x is not None") -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 05 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From donald at stufft.io Wed Mar 5 23:10:28 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 17:10:28 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53179F55.3080501@egenix.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> Message-ID: On Mar 5, 2014, at 5:04 PM, M.-A. Lemburg wrote: > I don't know what all the fuzz is about. There are lots of types > in Python that evaluate to False in certain corner cases, e.g. > "", (), [], {}, 0, 0.0, 0j, None, etc. > > datetime.time(0,0,0) is just another one :-) > > BTW: If you want to test for None, well, then do test for None and > not for some property of None: > > if x is None: > print ("x is None, which implies it's False") > print ("Oh, and do note that the inverse is not necessarily true :-)") > > In logic: > > A -> B does not imply B -> A; it only implies (not B) -> (not A). > > in Python again: > > if bool(x) is not False: > print ("x is not None") > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Mar 05 2014) >>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ Most of those are pretty easy to reason about being ?False?, they all have some concept of empty, nothing, etc. Midnight however is not any more or less a time than one minute past midnight. Even worse, if you consider not explicitly checking for None a bug in that application code, debugging that code is made much more difficult because of the fact that for some reason "midnight" is considered False. That is the real problem here, sure people should be using ``is None`` checks but until people are perfect and never write buggy code, we have to contend with the fact that sometimes people will not write ``is None``. Making that particular error harder to debug is doing nothing but wasting their time and having Python be punitive for what in many cases may be a mistake. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ben+python at benfinney.id.au Wed Mar 5 23:16:06 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Thu, 06 Mar 2014 09:16:06 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> Message-ID: <85siqwcmvt.fsf@benfinney.id.au> "M.-A. Lemburg" writes: > I don't know what all the fuzz is about. There are lots of types > in Python that evaluate to False in certain corner cases, e.g. > "", (), [], {}, 0, 0.0, 0j, None, etc. > > datetime.time(0,0,0) is just another one :-) The salient difference is: With the former set, they all embody concepts of either ?empty? or ?zero magnitude?. They strongly connote ?not there? within their domain of values, hence map well to Boolean false. With ?datetime.time? there is no equivalent: midnight is not special in the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point on a continuum, and is not a ?not there? value. It should not be Boolean false any more than any other time. -- \ ?What is it that makes a complete stranger dive into an icy | `\ river to save a solid gold baby? Maybe we'll never know.? ?Jack | _o__) Handey | Ben Finney From mal at egenix.com Wed Mar 5 23:27:07 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 05 Mar 2014 23:27:07 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> Message-ID: <5317A4BB.1090303@egenix.com> On 05.03.2014 23:10, Donald Stufft wrote: > > On Mar 5, 2014, at 5:04 PM, M.-A. Lemburg wrote: > >> I don't know what all the fuzz is about. There are lots of types >> in Python that evaluate to False in certain corner cases, e.g. >> "", (), [], {}, 0, 0.0, 0j, None, etc. >> >> datetime.time(0,0,0) is just another one :-) >> > Most of those are pretty easy to reason about being ?False?, they all have some > concept of empty, nothing, etc. Midnight however is not any more or less a time > than one minute past midnight. Even worse, if you consider not explicitly > checking for None a bug in that application code, debugging that code is made > much more difficult because of the fact that for some reason "midnight" is > considered False. The reasoning becomes clear if you regard a time value as number of seconds since midnight (the time of day is a relative measure). This is 0 for time(0,0,0). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 05 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From donald at stufft.io Wed Mar 5 23:28:08 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 17:28:08 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317A4BB.1090303@egenix.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <5317A4BB.1090303@egenix.com> Message-ID: On Mar 5, 2014, at 5:27 PM, M.-A. Lemburg wrote: > On 05.03.2014 23:10, Donald Stufft wrote: >> >> On Mar 5, 2014, at 5:04 PM, M.-A. Lemburg wrote: >> >>> I don't know what all the fuzz is about. There are lots of types >>> in Python that evaluate to False in certain corner cases, e.g. >>> "", (), [], {}, 0, 0.0, 0j, None, etc. >>> >>> datetime.time(0,0,0) is just another one :-) >>> >> Most of those are pretty easy to reason about being ?False?, they all have some >> concept of empty, nothing, etc. Midnight however is not any more or less a time >> than one minute past midnight. Even worse, if you consider not explicitly >> checking for None a bug in that application code, debugging that code is made >> much more difficult because of the fact that for some reason "midnight" is >> considered False. > > The reasoning becomes clear if you regard a time value as > number of seconds since midnight (the time of day is a relative > measure). This is 0 for time(0,0,0). Except time isn?t number of seconds since midnight. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Mar 05 2014) >>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mal at egenix.com Wed Mar 5 23:35:02 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 05 Mar 2014 23:35:02 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <85siqwcmvt.fsf@benfinney.id.au> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> Message-ID: <5317A696.8040605@egenix.com> On 05.03.2014 23:16, Ben Finney wrote: > "M.-A. Lemburg" writes: > >> I don't know what all the fuzz is about. There are lots of types >> in Python that evaluate to False in certain corner cases, e.g. >> "", (), [], {}, 0, 0.0, 0j, None, etc. >> >> datetime.time(0,0,0) is just another one :-) > > The salient difference is: > > With the former set, they all embody concepts of either ?empty? or ?zero > magnitude?. They strongly connote ?not there? within their domain of > values, hence map well to Boolean false. > > With ?datetime.time? there is no equivalent: midnight is not special in > the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point > on a continuum, and is not a ?not there? value. This is true in a date/time continuum, but not true if you regard time as "time of day". In the latter interpretation, the day starts at midnight, so the day is "not there" yet at midnight. > It should not be Boolean false any more than any other time. Just like with most interpretations, you can just as easily find one which implies the exact opposite. It's all smoke and mirrors anyway :-) Perhaps Tim just wanted to be able to make float(time(0,0,0)) return 0.0 seconds some day. That's what mxDateTime does for time values. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 05 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From greg.ewing at canterbury.ac.nz Wed Mar 5 23:36:09 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 11:36:09 +1300 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140305120410.GY28804@ando> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: <5317A6D9.5040704@canterbury.ac.nz> Steven D'Aprano wrote: > (By the way, I think it is somewhat amusing that Python not only has a > built-in complex type, but also *syntax* for creating complex numbers, > but no built-in support for exact rationals.) I gather that Guido's experiences with ABC have led him to believe such a feature would be an attractive nuisance. Rationals have some nasty performance traps if you use them without being fully aware of what you're doing. -- Greg From donald at stufft.io Wed Mar 5 23:38:12 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 17:38:12 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317A696.8040605@egenix.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> Message-ID: On Mar 5, 2014, at 5:35 PM, M.-A. Lemburg wrote: > On 05.03.2014 23:16, Ben Finney wrote: >> "M.-A. Lemburg" writes: >> >>> I don't know what all the fuzz is about. There are lots of types >>> in Python that evaluate to False in certain corner cases, e.g. >>> "", (), [], {}, 0, 0.0, 0j, None, etc. >>> >>> datetime.time(0,0,0) is just another one :-) >> >> The salient difference is: >> >> With the former set, they all embody concepts of either ?empty? or ?zero >> magnitude?. They strongly connote ?not there? within their domain of >> values, hence map well to Boolean false. >> >> With ?datetime.time? there is no equivalent: midnight is not special in >> the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point >> on a continuum, and is not a ?not there? value. > > This is true in a date/time continuum, but not true if you regard > time as "time of day". In the latter interpretation, the day starts > at midnight, so the day is "not there" yet at midnight. The day is absolutely here at midnight. Midnight isn?t some void where time ceases to exist. > >> It should not be Boolean false any more than any other time. > > Just like with most interpretations, you can just as easily find > one which implies the exact opposite. > > It's all smoke and mirrors anyway :-) > > Perhaps Tim just wanted to be able to make float(time(0,0,0)) return > 0.0 seconds some day. That's what mxDateTime does for time values. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Mar 05 2014) >>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alexander.belopolsky at gmail.com Wed Mar 5 23:38:53 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 5 Mar 2014 17:38:53 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <85siqwcmvt.fsf@benfinney.id.au> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> Message-ID: On Wed, Mar 5, 2014 at 5:16 PM, Ben Finney wrote: > .. midnight is not special in > the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point > on a continuum, .. > Tell that to people who gather in the Times Square on New Year Eve! It is very common to implement time-of-day in the languages that lack a dedicated class as seconds since midnight or fraction of a 24 hour day or any similar scheme. In all these schemes midnight is false in boolean context. Note that when datetime module was introduced, Python did not have a time class and people were using int or float to denote time-of-day. Compatibility with older schemes could be part of the original motivation. It also made more sense when the dunder method was spelled __nonzero__. Whatever the reason was - this is a well established feature and it won't change. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Wed Mar 5 23:43:59 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 6 Mar 2014 08:43:59 +1000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> Message-ID: On 6 Mar 2014 08:11, "Donald Stufft" wrote: > > Most of those are pretty easy to reason about being "False", they all have some > concept of empty, nothing, etc. Midnight however is not any more or less a time > than one minute past midnight. Even worse, if you consider not explicitly > checking for None a bug in that application code, debugging that code is made > much more difficult because of the fact that for some reason "midnight" is > considered False. > > That is the real problem here, sure people should be using ``is None`` checks > but until people are perfect and never write buggy code, we have to contend > with the fact that sometimes people will not write ``is None``. Making that > particular error harder to debug is doing nothing but wasting their time and > having Python be punitive for what in many cases may be a mistake. Right, the core problem here is changing an often harmless style problem into a subtle behavioural bug. I changed the title on http://bugs.python.org/issue13936 accordingly, reopened it and described the appropriate next steps for anyone that is motivated enough about the issue to actually do the work. We'll see if the enthusiasm for changing the behaviour translates into anyone being sufficiently interested to work out the details of the deprecation warning and the associated documentation and test updates. Regards, Nick. > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Wed Mar 5 23:45:34 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 17:45:34 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> Message-ID: <6A78ACBF-1628-499D-9A31-F951DDF062D1@stufft.io> On Mar 5, 2014, at 5:43 PM, Nick Coghlan wrote: > > On 6 Mar 2014 08:11, "Donald Stufft" wrote: > > > > Most of those are pretty easy to reason about being ?False?, they all have some > > concept of empty, nothing, etc. Midnight however is not any more or less a time > > than one minute past midnight. Even worse, if you consider not explicitly > > checking for None a bug in that application code, debugging that code is made > > much more difficult because of the fact that for some reason "midnight" is > > considered False. > > > > That is the real problem here, sure people should be using ``is None`` checks > > but until people are perfect and never write buggy code, we have to contend > > with the fact that sometimes people will not write ``is None``. Making that > > particular error harder to debug is doing nothing but wasting their time and > > having Python be punitive for what in many cases may be a mistake. > > Right, the core problem here is changing an often harmless style problem into a subtle behavioural bug. I changed the title on http://bugs.python.org/issue13936 accordingly, reopened it and described the appropriate next steps for anyone that is motivated enough about the issue to actually do the work. > > We'll see if the enthusiasm for changing the behaviour translates into anyone being sufficiently interested to work out the details of the deprecation warning and the associated documentation and test updates. > > Regards, > Nick. > > > > > ----------------- > > Donald Stufft > > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas at python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ Thanks Nick :) ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From breamoreboy at yahoo.co.uk Wed Mar 5 23:47:45 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 22:47:45 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> Message-ID: On 05/03/2014 22:38, Alexander Belopolsky wrote: > > On Wed, Mar 5, 2014 at 5:16 PM, Ben Finney > wrote: > > .. midnight is not special in > the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point > on a continuum, .. > > > Tell that to people who gather in the Times Square on New Year Eve! > > It is very common to implement time-of-day in the languages that lack a > dedicated class as seconds since midnight or fraction of a 24 hour day > or any similar scheme. In all these schemes midnight is false in > boolean context. > > Note that when datetime module was introduced, Python did not have a > time class and people were using int or float to denote time-of-day. > Compatibility with older schemes could be part of the original > motivation. It also made more sense when the dunder method was spelled > __nonzero__. > > Whatever the reason was - this is a well established feature and it > won't change. > Have you looked at the issue recently? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From greg.ewing at canterbury.ac.nz Wed Mar 5 23:49:25 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 11:49:25 +1300 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> Message-ID: <5317A9F5.8050704@canterbury.ac.nz> Oscar Benjamin wrote: > In C and some other languages the f suffix indicates a numeric literal > that has type "float" e.g. "6.0f". You can use upper case there as > well but the convention is lower case and to include the .0 when it's > an integer. I just though that 3F looks sufficiently distinct from the > way it's typically done in C. I'm not sure it's different enough; I've been looking at Java code recently that uses uppercase F. An alternative would be to use 'r' or 'R' for 'rational', which would eliminate any chance of confusion. -- Greg From alexander.belopolsky at gmail.com Wed Mar 5 23:55:46 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 5 Mar 2014 17:55:46 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> Message-ID: On Wed, Mar 5, 2014 at 5:47 PM, Mark Lawrence wrote: > Have you looked at the issue recently? :) Yes, and I added one more myself: http://bugs.python.org/issue20855 let's see which one fares better. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From breamoreboy at yahoo.co.uk Thu Mar 6 00:02:50 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Wed, 05 Mar 2014 23:02:50 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> Message-ID: On 05/03/2014 22:55, Alexander Belopolsky wrote: > > On Wed, Mar 5, 2014 at 5:47 PM, Mark Lawrence > > wrote: > > Have you looked at the issue recently? :) > > > Yes, and I added one more myself: > > http://bugs.python.org/issue20855 > > let's see which one fares better. :-) > As 20855 has already been closed, with a comment that I tend to agree with, I think it's time for me to grab my trenching tool, tin hat, camouflage net and flak jacket and start running before the Batley Townswomen Guild get involved. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From masklinn at masklinn.net Thu Mar 6 00:07:06 2014 From: masklinn at masklinn.net (Masklinn) Date: Thu, 6 Mar 2014 00:07:06 +0100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <53179C51.4020001@canterbury.ac.nz> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> <05894993-3C4D-42E7-9328-C3365DF92CBE@masklinn.net> <53179C51.4020001@canterbury.ac.nz> Message-ID: <29275C71-F3DC-4D4A-A251-B56AED14E6C1@masklinn.net> On 2014-03-05, at 22:51 , Greg Ewing wrote: > Masklinn wrote: >> On 2014-03-04, at 23:31 , Greg Ewing wrote: >>> But Algol has the benefit of static typing >> That's not really a blocker though, Haskell thunks are implicit and not >> type-encoded. A name may correspond to a (unforced) thunk or to a strict >> value > > That comes at the expense of making *everything* a thunk > until its value is needed. Of course not, Haskell allows explicitly forcing a thunk and the compiler/runtime pair can use strictness analysis and not create thunks in the first place. > This would be a big, far-reaching > change in the way Python works. Having Haskell-type thunks does not mean using the same default as Haskell. Python would have the opposite one, instead of creating thunks by default it would create them only when requested. > Also, Haskell has the advantage of knowing that the value > won't change I do not see why that would be relevant to thunks. The result of the thunk may be mutable, so what? > so it can replace the thunk with its value > once it's been calculated. Python would have to keep it > as a thunk and reevaluate it every time. See above, I do not see why that would happen. Consider that a thunk is a deferral of an expression's evaluation, why would said expression's evaluation happen more than once? The only thing which changes is *when* the actual evaluation happens. > And Haskell doesn't have to provide a way of passimg the > thunk around *without* evaluating it. Well no, instead it takes the sensible option to force thunks when they need to be forced (or when their forcing is explicitly requested e.g. using ($!) or "bang pattern" extensions, but the need for those is mostly because haskell defaults to creating thunks I would say). Why would passing a reference around force a thunk in the first place? From mal at egenix.com Thu Mar 6 00:08:20 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 00:08:20 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> Message-ID: <5317AE64.90007@egenix.com> On 05.03.2014 23:38, Donald Stufft wrote: > > On Mar 5, 2014, at 5:35 PM, M.-A. Lemburg wrote: > >> On 05.03.2014 23:16, Ben Finney wrote: >>> "M.-A. Lemburg" writes: >>> >>>> I don't know what all the fuzz is about. There are lots of types >>>> in Python that evaluate to False in certain corner cases, e.g. >>>> "", (), [], {}, 0, 0.0, 0j, None, etc. >>>> >>>> datetime.time(0,0,0) is just another one :-) >>> >>> The salient difference is: >>> >>> With the former set, they all embody concepts of either ?empty? or ?zero >>> magnitude?. They strongly connote ?not there? within their domain of >>> values, hence map well to Boolean false. >>> >>> With ?datetime.time? there is no equivalent: midnight is not special in >>> the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point >>> on a continuum, and is not a ?not there? value. >> >> This is true in a date/time continuum, but not true if you regard >> time as "time of day". In the latter interpretation, the day starts >> at midnight, so the day is "not there" yet at midnight. > > The day is absolutely here at midnight. Midnight isn?t some void where > time ceases to exist. No, but midnight starts the day, just like 0 starts the positive real numbers (itself not being positive) :-) >>> It should not be Boolean false any more than any other time. >> >> Just like with most interpretations, you can just as easily find >> one which implies the exact opposite. >> >> It's all smoke and mirrors anyway :-) >> >> Perhaps Tim just wanted to be able to make float(time(0,0,0)) return >> 0.0 seconds some day. That's what mxDateTime does for time values. >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Source (#1, Mar 05 2014) >>>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >> ________________________________________________________________________ >> 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go >> >> ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 05 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From donald at stufft.io Thu Mar 6 00:10:12 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 18:10:12 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317AE64.90007@egenix.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <5317AE64.90007@egenix.com> Message-ID: <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> On Mar 5, 2014, at 6:08 PM, M.-A. Lemburg wrote: > On 05.03.2014 23:38, Donald Stufft wrote: >> >> On Mar 5, 2014, at 5:35 PM, M.-A. Lemburg wrote: >> >>> On 05.03.2014 23:16, Ben Finney wrote: >>>> "M.-A. Lemburg" writes: >>>> >>>>> I don't know what all the fuzz is about. There are lots of types >>>>> in Python that evaluate to False in certain corner cases, e.g. >>>>> "", (), [], {}, 0, 0.0, 0j, None, etc. >>>>> >>>>> datetime.time(0,0,0) is just another one :-) >>>> >>>> The salient difference is: >>>> >>>> With the former set, they all embody concepts of either ?empty? or ?zero >>>> magnitude?. They strongly connote ?not there? within their domain of >>>> values, hence map well to Boolean false. >>>> >>>> With ?datetime.time? there is no equivalent: midnight is not special in >>>> the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point >>>> on a continuum, and is not a ?not there? value. >>> >>> This is true in a date/time continuum, but not true if you regard >>> time as "time of day". In the latter interpretation, the day starts >>> at midnight, so the day is "not there" yet at midnight. >> >> The day is absolutely here at midnight. Midnight isn?t some void where >> time ceases to exist. > > No, but midnight starts the day, just like 0 starts the positive > real numbers (itself not being positive) :-) And yet 0 is False not because it starts the positive real numbers (not sure what that has to do with a value in an integer type) but because it signifies an empty or zero magnitude object. > >>>> It should not be Boolean false any more than any other time. >>> >>> Just like with most interpretations, you can just as easily find >>> one which implies the exact opposite. >>> >>> It's all smoke and mirrors anyway :-) >>> >>> Perhaps Tim just wanted to be able to make float(time(0,0,0)) return >>> 0.0 seconds some day. That's what mxDateTime does for time values. >>> >>> -- >>> Marc-Andre Lemburg >>> eGenix.com >>> >>> Professional Python Services directly from the Source (#1, Mar 05 2014) >>>>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >>> ________________________________________________________________________ >>> 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go >>> >>> ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: >>> >>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>> http://www.egenix.com/company/contact/ >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Mar 05 2014) >>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tjreedy at udel.edu Thu Mar 6 00:20:45 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 05 Mar 2014 18:20:45 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: On 3/5/2014 4:10 PM, Alex Gaynor wrote: > First, I'd like to dispense with the notion that ``if foo`` is somehow a bad > practice. It is when one means 'if foo is not None' as it is as fragile, and in the same way, in the same way as using 'a and b or c' as a conditional expression. > This is an EXTREMELY common practice as a shorthand for checking for > None, a great many people consider it more idiomatic, In what universe. I was originally for changing datetime, but seems the issue being used as a vehicle to justify and promote buggy programming has changed my mind. -- Terry Jan Reedy From abarnert at yahoo.com Thu Mar 6 00:20:12 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Wed, 5 Mar 2014 15:20:12 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <20140305153529.GC28804@ando> References: <20140305153529.GC28804@ando> Message-ID: On Mar 5, 2014, at 7:35, Steven D'Aprano wrote: > So as you can see, what I've been calling a thunk is not precisely like > Algol thunks. One thing which is missing is the dynamic scoping: in the > thunk evaluation, the x comes from the caller's scope. But the delayed > evaluation part is quite similar, enough that I think the name may be > appropriate. Another name for this might be a "promise", as in the > promise to execute a computation later. As I mentioned in one of the previous threads, Alice does lazy evaluation with futures and promises--the same construct it uses for concurrent scheduling, closely related to what Python has in concurrent.futures (Python merges futures and promises into a single object with two different APIs, but the idea is the same). If `expr` evaluated to an object with the same API as a concurrent.futures.Future, that's not a terrible form of explicit evaluation. But if it's doing something like dynamic scoping, it might look pretty misleading. From mal at egenix.com Thu Mar 6 00:22:38 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 00:22:38 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <5317AE64.90007@egenix.com> <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> Message-ID: <5317B1BE.4090804@egenix.com> On 06.03.2014 00:10, Donald Stufft wrote: > > On Mar 5, 2014, at 6:08 PM, M.-A. Lemburg wrote: > >> On 05.03.2014 23:38, Donald Stufft wrote: >>> >>> On Mar 5, 2014, at 5:35 PM, M.-A. Lemburg wrote: >>> >>>> On 05.03.2014 23:16, Ben Finney wrote: >>>>> "M.-A. Lemburg" writes: >>>>> >>>>>> I don't know what all the fuzz is about. There are lots of types >>>>>> in Python that evaluate to False in certain corner cases, e.g. >>>>>> "", (), [], {}, 0, 0.0, 0j, None, etc. >>>>>> >>>>>> datetime.time(0,0,0) is just another one :-) >>>>> >>>>> The salient difference is: >>>>> >>>>> With the former set, they all embody concepts of either ?empty? or ?zero >>>>> magnitude?. They strongly connote ?not there? within their domain of >>>>> values, hence map well to Boolean false. >>>>> >>>>> With ?datetime.time? there is no equivalent: midnight is not special in >>>>> the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point >>>>> on a continuum, and is not a ?not there? value. >>>> >>>> This is true in a date/time continuum, but not true if you regard >>>> time as "time of day". In the latter interpretation, the day starts >>>> at midnight, so the day is "not there" yet at midnight. >>> >>> The day is absolutely here at midnight. Midnight isn?t some void where >>> time ceases to exist. >> >> No, but midnight starts the day, just like 0 starts the positive >> real numbers (itself not being positive) :-) > > And yet 0 is False not because it starts the positive real numbers (not sure > what that has to do with a value in an integer type) but because it signifies > an empty or zero magnitude object. Well, the duration between the start of day and midnight is zero and returning to the interpretation of time of day being a measurement relative to midnight, this makes time(0,0,0) a zero magnitude object. q.e.d. Anyway, it's all up in the air for interpretation :-) There are reasons to have time(0,0,0) be False just as there are reasons for it not to be False. There's no clear answer. >>>>> It should not be Boolean false any more than any other time. >>>> >>>> Just like with most interpretations, you can just as easily find >>>> one which implies the exact opposite. >>>> >>>> It's all smoke and mirrors anyway :-) >>>> >>>> Perhaps Tim just wanted to be able to make float(time(0,0,0)) return >>>> 0.0 seconds some day. That's what mxDateTime does for time values. >>>> >>>> -- >>>> Marc-Andre Lemburg >>>> eGenix.com >>>> >>>> Professional Python Services directly from the Source (#1, Mar 05 2014) >>>>>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>>>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >>>> ________________________________________________________________________ >>>> 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go >>>> >>>> ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: >>>> >>>> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>>> Registered at Amtsgericht Duesseldorf: HRB 46611 >>>> http://www.egenix.com/company/contact/ >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>> >>> ----------------- >>> Donald Stufft >>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >>> >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Source (#1, Mar 05 2014) >>>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ >> ________________________________________________________________________ >> 2014-04-09: PyCon 2014, Montreal, Canada ... 35 days to go >> >> ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From alexander.belopolsky at gmail.com Thu Mar 6 00:22:54 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 5 Mar 2014 18:22:54 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <5317AE64.90007@egenix.com> <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> Message-ID: On Wed, Mar 5, 2014 at 6:10 PM, Donald Stufft wrote: > And yet 0 is False not because it starts the positive real numbers (not > sure > what that has to do with a value in an integer type) but because it > signifies > an empty or zero magnitude object. > No. It is False because it equals False: >>> 0 == False True Numbers are not containers. You cannot tell whether a number is empty or not. Python interpretation of numbers in boolean context is different from that of containers. I think the disagreement stems from different view on what time-of-day is. For me, it is the fraction of the day that passed or distance from midnight and in any case fundamentally some kind of number expressed in a Babylonian base-60 notation. I think proponents of bool(time(0)) == True view it as a container of hours, minutes and seconds. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Thu Mar 6 00:23:03 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 12:23:03 +1300 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: References: Message-ID: <5317B1D7.4090305@canterbury.ac.nz> Carl Smith wrote: > I was thinking of a short word which describes an > expression who's evaluation changes depending on the local > circumstances. Like a legal bill, not a dollar bill. Oh. Well, I must say that this was very far from being the first interpretation of the word "bill" that sprang to mind when I saw it. I wasn't even aware of this meaning of the term "legal bill" (although admittedly I'm not used to living in a country where the laws vary wildly from one place to another). -- Greg From greg.ewing at canterbury.ac.nz Thu Mar 6 00:23:15 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 12:23:15 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> <201403051259.40289.shai@platonix.com> Message-ID: <5317B1E3.9020409@canterbury.ac.nz> Oscar Benjamin wrote: > The question is surely whether the issue is worth a backwards > compatibility break not whether the current behaviour is a good idea > (it clearly isn't). The currrent behaviour is sufficiently useless that it seems unlikely there would be much code out there relying on it. -- Greg From greg.ewing at canterbury.ac.nz Thu Mar 6 00:23:28 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 12:23:28 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: <5317B1F0.3070408@canterbury.ac.nz> Paul Moore wrote: > Agreed that the odd behaviour of time in a > boolean context is why this whole class of bugs exists, but it's only > a subclass if the wider problem that people shouldn't truth-test > values without thinking But this bites you even if you *do* think, because there is no reason to suspect that any time value should be regarded as false, especially since the docs make no mention of this. Note that "fix the docs" is *not* the right response to this, IMO -- that would just be enshrining a bad design decision. Better to fix the design while we have the chance. -- Greg From oscar.j.benjamin at gmail.com Thu Mar 6 00:24:46 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Wed, 5 Mar 2014 23:24:46 +0000 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <5317A6D9.5040704@canterbury.ac.nz> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <20140305120410.GY28804@ando> <5317A6D9.5040704@canterbury.ac.nz> Message-ID: On 5 March 2014 22:36, Greg Ewing wrote: > Steven D'Aprano wrote: >> >> (By the way, I think it is somewhat amusing that Python not only has a >> built-in complex type, but also *syntax* for creating complex numbers, but >> no built-in support for exact rationals.) > > I gather that Guido's experiences with ABC have led him > to believe such a feature would be an attractive nuisance. > Rationals have some nasty performance traps if you use > them without being fully aware of what you're doing. I've read statement's to that effect but they were specifically about having rational as the *default* mode for integer division which I am not suggesting. It's already possible to opt-in to using Fractions so that rationals are used for division. Currently you have to import a module and write F(1, 7) or F('1/7') everywhere in your code. If it were possible to write 1/7F or 1/7r or whatever then I've personally written code where I would have used that so that it would be easier to read, would look more natural with syntax highlighting etc. Oscar From donald at stufft.io Thu Mar 6 00:28:12 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 18:28:12 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317B1F0.3070408@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> <5317B1F0.3070408@canterbury.ac.nz> Message-ID: <39FD7C84-C7AB-47EA-9A9C-9216DAE5D286@stufft.io> On Mar 5, 2014, at 6:23 PM, Greg Ewing wrote: > Paul Moore wrote: >> Agreed that the odd behaviour of time in a >> boolean context is why this whole class of bugs exists, but it's only >> a subclass if the wider problem that people shouldn't truth-test >> values without thinking > > But this bites you even if you *do* think, because there > is no reason to suspect that any time value should be > regarded as false, especially since the docs make no > mention of this. > > Note that "fix the docs" is *not* the right response to > this, IMO -- that would just be enshrining a bad design > decision. Better to fix the design while we have the > chance. > > -- > Greg > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ The docs do mention it: > in Boolean contexts, a time object is considered to be true if and only > if, after converting it to minutes and subtracting utcoffset() (or 0 if that?s > None), the result is non-zero. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From greg.ewing at canterbury.ac.nz Thu Mar 6 00:33:49 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 12:33:49 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051553.19311.shai@platonix.com> <201403051719.09276.shai@platonix.com> Message-ID: <5317B45D.6000606@canterbury.ac.nz> Paul Moore wrote: > """in Boolean contexts, a time object is considered to be true if and > only if, after converting it to minutes and subtracting utcoffset() > (or 0 if that's None), the result is non-zero.""" Aaaaargh... I didn't know this had since been documented. Wy opinion still stands -- documenting this was the wrong thing to do. I hope it can still be fixed. -- Greg From rob.cliffe at btinternet.com Thu Mar 6 01:21:36 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Thu, 06 Mar 2014 00:21:36 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> Message-ID: <5317BF90.9030901@btinternet.com> On 05/03/2014 17:27, Alexander Belopolsky wrote: > > On Wed, Mar 5, 2014 at 11:38 AM, Shai Berger > wrote: > > So, I rephrase my request: Would anybody object to a silent > warning issued > whenever a time-object is evaluated as Boolean? > > > I would. Users should not be penalized for using a documented behavior. We hope that the Python documentation describes the semantics of the language and packages as completely as is reasonably possible. So you are effectively saying that no backwards-incompatible change should ever be made. If we accepted that, this discussion would end now. > There are legitimate uses for bool(midnight) being False. Midnight > is special in many contexts. For example, it is uncertain whether > midnight belongs to the previous or next day. If your application > wants to group midnight differently from other times - it is perfectly > fine to use "if dt.time()" instead of a more verbose "if dt.time() != > datetime.time(0, 0)". > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2247 / Virus Database: 3705/6655 - Release Date: 03/05/14 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Thu Mar 6 01:40:17 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Wed, 5 Mar 2014 16:40:17 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> <1394051558.18502.YahooMailNeo@web181005.mail.ne1.yahoo.com> Message-ID: On Wednesday, March 5, 2014 3:13:29 PM UTC-6, Ron Adam wrote: > > It's also a matter of how far in the future you are looking. If he waited > > until later to propose something like this, it most likely wouldn't get in. > > I'm not sure he's expecting a firm answer now, but probably is hoping > for > > a "hey lets look into this more and see if it's really possible" kind of > maybe. For that, it's good to start early. > hi Ron, yes, correct. Something like this would require huge effort, determined strategy, and possibly years of planning. Its not going to happen over-night, but in stages could be brought to fruition given some thought and a lot of dialogue. kind regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Thu Mar 6 01:30:58 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Wed, 5 Mar 2014 16:30:58 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <1394007018.19177.YahooMailNeo@web181004.mail.ne1.yahoo.com> Message-ID: <28d03184-4934-4840-8f92-082901ae0c30@googlegroups.com> On Wednesday, March 5, 2014 2:10:18 AM UTC-6, Andrew Barnert wrote: The types you dislike are not programming concepts that get in the way of > human mathematics, they are human mathematical concepts. The integers, the > rationals, and the reals all behave differently. And they're not the only > types of numbers?Python handles complex numbers natively, and it's very > easy to extend it with, say, quaternions or even arbitrary matrices that > act like numbers. > hi Andrew, your response reminds me of that scene from 'Star Trek: First Contact,' when Data was getting a little lippy with her eminence The Borg (the one who is many) (he was trying to explain to her why she doesn't exist, since her ship was destroyed just after coming through the chronometric particle vortex--time travel--) and she responded, "You think so three dimensionally... " When asked about the Borg hierarchy she stated simply, "You imply disparity where none exists..." Now, that was one hot cybernetic babe. My point is philosophical, really. I do not dislike numerical types. I simply do not believe they are necessary. In fact, Rexx (in a simple way) and other languages too for that matter, have demonstrated that types are superficial paradigms in symbolic thought that can quite readily be eliminated for most AI applications given enough memory, and enough time. Fortunately, memory is becoming more plentiful (less expensive) and time is shrinking away through processor speed, pipe-lining, and software engineering like decimal.Decimal. Keep in mind that I am NOT proposing the elimination of numbers, I am proposing the abstraction of *python numbers (yes, all of them...) *in such a way that programmers and specialists, and accountants and grade school teachers may use Python without having to be computer scientists (all of the work happens under the covers, written by someone like me, or you) and everything at the top is simple and human readable; for them. Yes, its work. And, its doable. A *number *should be no more convoluted in a modern age of symbol set processing than any other abstract idea (just because of arbitrary limits and abstraction paradigms). Unifying *python numbers *requires a high order paradigm shift for sure; but the concept is absolutely doable. kind regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Thu Mar 6 01:52:53 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 5 Mar 2014 19:52:53 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317BF90.9030901@btinternet.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> Message-ID: On Wed, Mar 5, 2014 at 7:21 PM, Rob Cliffe wrote: > So you are effectively saying that no backwards-incompatible change should > ever be made. > If we accepted that, this discussion would end now. > This was the rule for the datetime module for many years and we were able to put in many nice enhancements in a fully backward compatible way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Thu Mar 6 02:06:38 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Wed, 5 Mar 2014 17:06:38 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140305135646.GB28804@ando> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: On Wednesday, March 5, 2014 7:56:46 AM UTC-6, Steven D'Aprano wrote: > > On Tue, Mar 04, 2014 at 07:42:28PM -0800, Mark H. Harris wrote: > > > The idea of *python number* means that there are no types, no limits, > no > > constraints, and that all *python numbers *are dynamic. The upper level > > syntax is also very simple; all* python numbers *are simply human. > > What makes this a "python number"? In what way are they "dynamic"? > > At this point in the discussion please try not to think "implementation," rather think conceptually in an open framework where anything is possible. Dynamic in terms of *python numbers *is not that far off from the concept of dynamic name binding used everywhere else in python. In terms of unifying numbers as *python numbers *which needs to be defined at some point, the idea of dynamic binding means first that numeric symbol sets have no type, and are not 'bound' until run-time, if at all. Consider: What is this? ===> PI / 2 Is it two numbers with a divisor,? or a Decimal and an int with a divisor,? or a *python number ?* Or, is it a string of characters that are readily recognizable to humans that means 'the top of the unit circle," or half_of_PI whatever I mean by that, or '1.57079632679489661923132169163975144209858469968755291048747229615390820314' Dynamic means the symbols sets are bound (name-wise, abstraction-wise) only at run-time, and with some 'smarts' as it were (AI) so that the right things happen under the covers (not magic) because the machine has been taught to think, as it were, about numbers and symbols the way normal humans do (in the kitchen, at high school, at the university, in science and business). Another way to think of this Steven is to think of 'pretty print' on the TI 89 Platinum edition graphical programming calculator (my personal favorite). Anyone who plays with it the first time is frustrated because *numbers *are symbolized instead of printed out in strings of numerals. So if I enter {1} [/] {3} and press enter, I get 1/3 <==== Yes, I can press evaluate and get .33333333333333333 but 1/3 is just as good a number as any other number (and what type is it???) PI / 2 is another example. That's a great number and I don't really need to see a numeric list of digits to use it, do I... and what is its type??? who cares. Another very simple (and not quite good enough) example is the pdeclib file I just created over the past couple of days. I have a need within the module to use PI or half_PI for some method or function (but I don't need the user to know that, and I don't want to calculate it over and over, and I want it within accuracy for the context on demand)... so what? I created __gpi__ global PI. It is reset to Decimal(0) if the dscale(n) precision context changes. Then, and function that requires PI of half_PI can check first to see if it is cached as __gpi__ and if so pull it back, or if not calculate it. If the context does not change than I half some whopping value of PI for the duration of the context (but, and this is the big but, if I don't need it --- then it never gets bound). Binding for *python numbers * must be dynamic, typeless, limitless, and no constraints. If I enter a formula of symbols into python (whatever I mean by that) python just handles it dynamically just like the TI 89--- if I want explicit control of the processing, I am free to ask for that too, just like the TI 89. By the by, complex numbers are no different what-so-ever, nor fractions either, nor any other *number.* The system needs to be able to parse symbol sets intelligently (Alonzo Church, Alan Turning, and John McCarthy dreamed of this, but had no way to accomplish it in their day) and then dynamically bind the naming / representation to the abstraction (or implementation) that makes sense for that symbol set in 'that' context, for 'that' problem. This is not simply business as usual... it requires AI, it requires a severe paradigm shift of a very high order. Kind regards, marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at mrabarnett.plus.com Thu Mar 6 02:27:45 2014 From: python at mrabarnett.plus.com (MRAB) Date: Thu, 06 Mar 2014 01:27:45 +0000 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <5317B1D7.4090305@canterbury.ac.nz> References: <5317B1D7.4090305@canterbury.ac.nz> Message-ID: <5317CF11.20100@mrabarnett.plus.com> On 2014-03-05 23:23, Greg Ewing wrote: > Carl Smith wrote: >> I was thinking of a short word which describes an >> expression who's evaluation changes depending on the local >> circumstances. Like a legal bill, not a dollar bill. > > Oh. Well, I must say that this was very far from being > the first interpretation of the word "bill" that sprang > to mind when I saw it. > > I wasn't even aware of this meaning of the term "legal > bill" (although admittedly I'm not used to living in a > country where the laws vary wildly from one place > to another). > In the UK we talk about "Bills" being put before Parliament. It reminds me of that quotation about the UK and US: ?Two nations divided by a common language?. In the UK you can pay a bill using a cheque; in the US you can pay the check using bills (but a "check" is also a (UK) cheque!). From tim.peters at gmail.com Thu Mar 6 02:34:13 2014 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 5 Mar 2014 19:34:13 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317BF90.9030901@btinternet.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> Message-ID: [Rob Cliffe ] > We hope that the Python documentation describes the semantics of the > language and packages as completely as is reasonably possible. > So you are effectively saying that no backwards-incompatible change should > ever be made. > If we accepted that, this discussion would end now. There should be a very high bias against changing documented behavior that is in fact working as documented. The document is a contract with users. Contracts shouldn't be violated without truly compelling cause. "I am altering the deal. Pray I don't alter it any further." There's a reason Darth Vader wasn't proclaimed Python's BDFL ;-) From tim.peters at gmail.com Thu Mar 6 02:37:37 2014 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 5 Mar 2014 19:37:37 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317B45D.6000606@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <201403051553.19311.shai@platonix.com> <201403051719.09276.shai@platonix.com> <5317B45D.6000606@canterbury.ac.nz> Message-ID: [Paul Moore] >> """in Boolean contexts, a time object is considered to be true if and >> only if, after converting it to minutes and subtracting utcoffset() >> (or 0 if that's None), the result is non-zero.""" [Greg Ewing] > Aaaaargh... I didn't know this had since been documented. > > Wy opinion still stands -- documenting this was the > wrong thing to do. I hope it can still be fixed. The quoted text has always been there, from datetime's initial release: http://docs.python.org/2.3/lib/datetime-time.html That was a bit over 9 years ago. From donald at stufft.io Thu Mar 6 02:38:41 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 20:38:41 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> Message-ID: On Mar 5, 2014, at 8:34 PM, Tim Peters wrote: > [Rob Cliffe ] >> We hope that the Python documentation describes the semantics of the >> language and packages as completely as is reasonably possible. >> So you are effectively saying that no backwards-incompatible change should >> ever be made. >> If we accepted that, this discussion would end now. > > There should be a very high bias against changing documented behavior > that is in fact working as documented. The document is a contract > with users. Contracts shouldn't be violated without truly compelling > cause. > > "I am altering the deal. Pray I don't alter it any further." There's > a reason Darth Vader wasn't proclaimed Python's BDFL ;-) > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ When the documented behavior is both nonsensical and the cause of hard to debug bugs that is a pretty compelling use case to me, unless you actively enjoy being user hostile. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tim.peters at gmail.com Thu Mar 6 02:53:02 2014 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 5 Mar 2014 19:53:02 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: [Bruce Leban] > And the documentation is not exactly clear for understanding when a time > object is falsey. In particular, the "converting it to minutes" part seems > irrelevant That's there because `utcoffset()` is defined to return minutes. A rule is needed to specify how the naive time object and `utcoffset()` interact to define the result. > as a time of 1 microsecond from midnight is truthy and timedeltas > are not numbers and are not in minutes timedeltas have nothing to do with this. The docs could be expanded to specify precisely how the naive time object is converted to minutes, but I think that's so obvious it would just be tedious to do so. > Perhaps a reasonable improvement would be to change this to: > > a time object is considered to be true unless it represents exactly midnight > local time, that is, it's false if subtracting the utcoffset() from the time > produces an all-zero result (or it's all-zero to start with if the utcoffset > is None). You still need a rule to define _how_ "subtracting the utcoffset() from the time" is intended to work, since arithmetic on naive time objects is not defined. Add "convert it to minutes" ;-) From tim.peters at gmail.com Thu Mar 6 03:08:56 2014 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 5 Mar 2014 20:08:56 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317A696.8040605@egenix.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> Message-ID: [M.-A. Lemburg] > ... > Perhaps Tim just wanted to be able to make float(time(0,0,0)) return > 0.0 seconds some day. That's what mxDateTime does for time values. Now you're getting close :-) There was an endless list of features various people said they wanted in a datetime module. At the time, we picked a large subset we could do in time, and released it. There was every expectation that more features may be added later. Among them were various kinds of conversions and various kinds of arithmetic enhancements. For example, modular arithmetic on time objects was a possibility. In that case, time(0, 0, 0) would become "a zero value" just as much as 0 or 0.0 or 0j or 0x00 are zero values. But if it weren't _treated_ as "a zero value" from the start, backward compatibility would prevent it from being treated as a zero value for the first time later. So, what the heck - like all other zero/empty objects, time(0, 0, 0) was fiddled to evaluate to False in a Boolean context, AND (something nobody seems to have noticed yet) plain time() was fiddled to return it: >>> bool(int()) is bool(complex()) is bool(float()) is bool(datetime.time()) True People can say that "midnight" isn't a compelling "sentinel value", and I agree about the "compelling" part, but in all implementation respects it does _act_ as "a sentinel value". If people don't want to use it as one, fine, that's their choice. I've used it as one, and it works fine for that purpose. As things turned out, nobody seemed to care much about modular (are any other kind of) arithmetic on time objects after all. Nevertheless, we went about 9 years before anyone complained about the code added to support the _possibility_ for doing that cleanly. The "seconds from midnight" view was also in play, with a view toward clean conversions to float-ish types. From alexander.belopolsky at gmail.com Thu Mar 6 03:12:17 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 5 Mar 2014 21:12:17 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Wed, Mar 5, 2014 at 8:53 PM, Tim Peters wrote: > > That's there because `utcoffset()` is defined to return minutes. More accurately, it returns "a timedelta object representing a whole number of minutes": time.utcoffset() If tzinfo is None, returns None, else returns self.tzinfo.utcoffset(None), and raises an exception if the latter doesn?t return None or a timedelta object representing a whole number of minutes with magnitude less than one day. http://docs.python.org/3/library/datetime.html#datetime.time.utcoffset -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Thu Mar 6 03:14:57 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 13:14:57 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: <20140306021457.GF28804@ando> On Wed, Mar 05, 2014 at 04:31:36PM -0500, Donald Stufft wrote: > I find the argument that it would only be fixed in 3.something and thus not be really > fixed for X years disingenuous at best. That fact is true for *ALL* bug fixes in Python > so by that logic we should simply give up on fixing anything in Python ever? Not at all. But it does mean that the benefit of fixing it needs to be worth the wait. Suppose we said "Sure, we'll fix it, but you have to pay for the fix." How much would you be willing to pay to have it fixed? ("Pay" doesn't have to mean money. It can also mean, how much pain or inconvenience are you willing to experience, or how much time and effort are you willing to out into this.) If I said, "Oh by the way, although you have to pay right now, you won't see any benefit until 2024", now how much are you willing to pay? Design flaws are more costly to fix than outright bugs, not because they take more time and effort to change, but because you're changing behaviour that *somebody out there is relying on*. What you consider a terrible misfeature is *somebody's* critical feature, and you're proposing that we take that away. That's okay, we can do that after a suitable deprecation period. (You wouldn't want us to break your code, so you ought to extend the same courtesy to other people.) But even if there isn't anyone relying on this, and we fix it as soon as possible (which will be 3.5), your library *still* can't rely on it until it drops all support for versions below 3.5. Since you can't rely on that feature being present, you have to write your library code as if it wasn't present. So there is *absolutely no difference* between your library with this (alleged) bug being fixed, or it not being fixed. The situation for application developers is a bit different. An application developer can simply say, I'm going to immediately migrate to 3.5 to take advantage of this new feature/bug fix. That's okay too. The job of the core developers is to balance all these competing interests: the library developers, the application developers, the users who don't care one way or another but do care about some other bug that's not being fixed because people are arguing about this one, the people (actual or hypothetical) who actually like this (mis)feature the way it is, people who don't like it but have written code that relies on it, and, yes, even the core developers themselves, who are perfectly entitled to say that the effort in fixing this is greater than the benefit so they're not going to do it. If you haven't already read Nick's blog posts on these issues, you should: http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html http://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html For what it's worth, I think the current behaviour is a misfeature, and in a perfect world it would be fixed. But the cost of this is so miniscule, and the work-around so trivial, that although the fix is cheap, the benefit is even lower. I've only spent a few minutes reading and responding to this thread. Those few minutes are already worth far more than any benefit to me in fixing this. That's *my* personal opinion on this, others may differ, so I'm a +0 on deprecating the behaviour in 3.5 and changing it in 3.6 or 3.7, and -0.5 on changing it immediately in 3.5. -- Steven From tim.peters at gmail.com Thu Mar 6 03:15:59 2014 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 5 Mar 2014 20:15:59 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> Message-ID: [Donald Stufft] > When the documented behavior is both nonsensical and the cause of hard > to debug bugs that is a pretty compelling use case to me, unless you actively > enjoy being user hostile. Breaking code that currently works is as hostile as hostile gets. Where is the evidence that no code relies on the current behavior? For that matter, where is the evidence that the current behavior is a significant cause of bugs? I know I've used "if some_time_object:", but it did exactly what I expected it to do. From steve at pearwood.info Thu Mar 6 03:19:48 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 13:19:48 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <85siqwcmvt.fsf@benfinney.id.au> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> Message-ID: <20140306021948.GG28804@ando> On Thu, Mar 06, 2014 at 09:16:06AM +1100, Ben Finney wrote: > With ?datetime.time? there is no equivalent: midnight is not special in > the way ?empty? or ?zero magnitude? are. Midnight is an arbitrary point > on a continuum, and is not a ?not there? value. It should not be Boolean > false any more than any other time. It may only be a convention that an instant before midnight is the end of the day and midnight the beginning of the next, but it is a convention: midnight is the origin (i.e. zero point) of the day. That makes it arguably as falsey as 0, 0.0 and 0j. -- Steven From donald at stufft.io Thu Mar 6 03:23:37 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 21:23:37 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> Message-ID: <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> On Mar 5, 2014, at 9:15 PM, Tim Peters wrote: > [Donald Stufft] >> When the documented behavior is both nonsensical and the cause of hard >> to debug bugs that is a pretty compelling use case to me, unless you actively >> enjoy being user hostile. > > Breaking code that currently works is as hostile as hostile gets. > Where is the evidence that no code relies on the current behavior? > For that matter, where is the evidence that the current behavior is a > significant cause of bugs? I know I've used "if some_time_object:", > but it did exactly what I expected it to do. Forgive me if I?m wrong, but aren?t you the author of the date time module? If that?s the case what you expect it to do isn?t particularly relevant as you?re intimately aware of it?s implementation. It?s hard to do any sort of search for this, however in an informal poll where I?ve shown people this code not a single person thought it made sense, and most of them responded with ?wtf??. I?ve also seen first hand through Django (which is why the person who started this thread) get caught by this bug and have to spend hours trying to figure out why it?s behaving that way. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From donald at stufft.io Thu Mar 6 03:33:24 2014 From: donald at stufft.io (Donald Stufft) Date: Wed, 5 Mar 2014 21:33:24 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306021457.GF28804@ando> References: <201403051216.12392.shai@platonix.com> <20140306021457.GF28804@ando> Message-ID: <18676193-CEEA-40E2-B996-ECDCDB01A365@stufft.io> On Mar 5, 2014, at 9:14 PM, Steven D'Aprano wrote: > On Wed, Mar 05, 2014 at 04:31:36PM -0500, Donald Stufft wrote: > >> I find the argument that it would only be fixed in 3.something and thus not be really >> fixed for X years disingenuous at best. That fact is true for *ALL* bug fixes in Python >> so by that logic we should simply give up on fixing anything in Python ever? > > Not at all. But it does mean that the benefit of fixing it needs to be > worth the wait. Suppose we said "Sure, we'll fix it, but you have > to pay for the fix." How much would you be willing to pay to have it > fixed? > > ("Pay" doesn't have to mean money. It can also mean, how much pain or > inconvenience are you willing to experience, or how much time and effort > are you willing to out into this.) > > If I said, "Oh by the way, although you have to pay right now, you won't > see any benefit until 2024", now how much are you willing to pay? Well I?ve offered to not only write the patch (assuming that someone else doesn?t do it before me since my time is limited), but also shepherd it through review and commit it myself. So I?m willing to pay with my free time which is a very limited resource :) In general I agree that everything has to go through a cost/benefit analysis, and in this case the cost and benefit are both fairly low in the grand scheme of things but the benefit does outweigh the cost as far as I?m concerned because the workaround requires you to know that the workaround is even required at all. > > Design flaws are more costly to fix than outright bugs, not because they > take more time and effort to change, but because you're changing > behaviour that *somebody out there is relying on*. What you consider a > terrible misfeature is *somebody's* critical feature, and you're > proposing that we take that away. That's okay, we can do that after a > suitable deprecation period. (You wouldn't want us to break your code, > so you ought to extend the same courtesy to other people.) It?s not obvious to me that design flaws are more costly to fix because people rely on even buggy behavior :) I don?t think i?ve advocated for not sending this through a normal deprecation process at all. > > But even if there isn't anyone relying on this, and we fix it as soon as > possible (which will be 3.5), your library *still* can't rely on it > until it drops all support for versions below 3.5. Since you can't rely > on that feature being present, you have to write your library code as if > it wasn't present. So there is *absolutely no difference* between your > library with this (alleged) bug being fixed, or it not being fixed. > There is a difference in the future when 3.5 (or whatever) is a reasonable minimum for a library. People say the same sort of thing about *anything* that is fixed or added to Python 3.x only that can?t be backported easily. There is a wait time until library authors can depend on anything new or changed in Python and there always has been an always will be. All that means is that a change now won?t be widely useful until some years down the road. But that?s true for *anything*, asyncio, PEP453, yield from, and this change too. > The situation for application developers is a bit different. An > application developer can simply say, I'm going to immediately migrate > to 3.5 to take advantage of this new feature/bug fix. That's okay too. > > The job of the core developers is to balance all these competing > interests: the library developers, the application developers, the users > who don't care one way or another but do care about some other bug > that's not being fixed because people are arguing about this one, the > people (actual or hypothetical) who actually like this (mis)feature the > way it is, people who don't like it but have written code that relies on > it, and, yes, even the core developers themselves, who are perfectly > entitled to say that the effort in fixing this is greater than the > benefit so they're not going to do it. > > If you haven't already read Nick's blog posts on these issues, you > should: > > http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html > http://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html I?ve read them. I have ~opinions~ about them but I?m not going to derail this thread with them. > > > For what it's worth, I think the current behaviour is a misfeature, and > in a perfect world it would be fixed. But the cost of this is so > miniscule, and the work-around so trivial, that although the fix is > cheap, the benefit is even lower. I've only spent a few minutes reading > and responding to this thread. Those few minutes are already worth far > more than any benefit to me in fixing this. That's *my* personal opinion > on this, others may differ, so I'm a +0 on deprecating the behaviour in > 3.5 and changing it in 3.6 or 3.7, and -0.5 on changing it immediately > in 3.5. > > As I said, the work around is trivial, *once you know it is needed*. This change is reducing the cognitive burden and chance for mishap for users who aren?t aware of this misfeature. It?s making Python a friendlier language to use. > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tim.peters at gmail.com Thu Mar 6 03:33:53 2014 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 5 Mar 2014 20:33:53 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> Message-ID: > Forgive me if I'm wrong, but aren't you the author of the date time module? Yes. > If that's the case what you expect it to do isn't particularly relevant as you're > intimately aware of it's implementation. Drat! Checkmated again! I get tired of putting smileys after everything ;-) > It's hard to do any sort of search for this, however in an informal poll where I've shown > people this code Precisely which code did you show them? What were the backgrounds of these people? Etc etc etc. > not a single person thought it made sense, and most of them responded > with "wtf?" Which, via amazing coincidence or foresight, is exactly what I bet you were expecting ;-) >. I've also seen first hand through Django (which is why the person who started > this thread) get caught by this bug and have to spend hours trying to figure out why it's > behaving that way. Too sketchy to say much about. If this is a variation of testing "if object:" as a shorthand for testing "if object is None:", little sympathy from me. In any case, this took more of my time so far than any possible outcome would be worth to me, so I'll just close with -0 on changing it (would rather not bother, but won't complain if it is changed). From harrismh777 at gmail.com Thu Mar 6 03:21:37 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Wed, 5 Mar 2014 18:21:37 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> > > > Then, and function that requires PI > of half_PI can check first to see if it is cached as __gpi__ and if so > pull it back, or if not calculate > it. If the context does not change than I half some whopping value of PI > for the duration of the > context (but, and this is the big but, if I don't need it --- then it > never gets bound). > > um, sorry, I wixed my mords... please forgive, "Then, and only then, a function that requires PI or half_PI will first check to see if __gpi__ has been cached and if so pull it back, or if not calculate it (once). If the context does not change then the function can take half of some whopping value of PI, for the duration of the context, and use that, but if not needed for the context will never bind it ! marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Thu Mar 6 04:00:02 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 14:00:02 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> Message-ID: <20140306030002.GH28804@ando> On Wed, Mar 05, 2014 at 09:23:37PM -0500, Donald Stufft wrote: > It?s hard to do any sort of search for this, however in an informal poll where I?ve shown > people this code not a single person thought it made sense, and most of them responded > with ?wtf??. Well I don't know who these people are, what their background is, or exactly how you phrased the question. But in my experience, most programmers have extremely strongly held opinions about the sensibility of certain features that have little or nothing with any rational analysis of the pros and cons and far more likely to be "that's different from the first language I learned, therefore it's rubbish". Having read Tim's explanation for why time() is falsey, I no longer think it's a misfeature, and am now -0.5 on changing it at all. > I?ve also seen first hand through Django (which is why the person who > started this thread) get caught by this bug and have to spend hours > trying to figure out why it?s behaving that way. Again, I don't know the background here, and we all know that sometimes tracking down bugs can be difficult, but if somebody is spending "hours" trying to debug why "if time_value" sometimes does the wrong thing, *without* bothering to read the documentation for time objects to find out how they're supposed to behave, then I don't have a lot of sympathy. Also, if you write "if spam" as a short-cut for "if spam is not None", then again any bugs you experience are self-inflicted. -- Steven From guido at python.org Thu Mar 6 04:47:24 2014 From: guido at python.org (Guido van Rossum) Date: Wed, 5 Mar 2014 19:47:24 -0800 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> Message-ID: I wonder if we need yet another list, python-speculative-ideas? Or python-waxing-philosophically? I've got a feeling were straying quite far from the topic of the design of even Python 4, let alone what could possibly happen in Python 3. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Thu Mar 6 04:54:24 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 06 Mar 2014 04:54:24 +0100 Subject: [Python-ideas] Add "goto fail" to Python? Message-ID: "goto fail" is a well-known error handling mechanism in open source software, widely reputed for its robusteness: http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150ccbdf0aec1878a41c17c41d358a3b:lib/x509/verify.c I believe Python needs to add support for this superior paradigm. It would involve a new keyword "fail" and some means of goto'ing to it. I suggest "raise to fail": if (some_error): raise to fail fail: Unless there are many objections, this fantastic idea might be submitted in a (short) PEP somewhere around the beginning of next month. There is some obvious overlap with the rejected "goto PEP" (PEP 3163) and the Python 2.3 goto module. However, the superiority of goto fail as error generation and error handling paradigm has since then been thoroughly proven. http://legacy.python.org/dev/peps/pep-3136/ http://entrian.com/goto/download.html Regards, Sturla Molden From bruce at leapyear.org Thu Mar 6 05:00:35 2014 From: bruce at leapyear.org (Bruce Leban) Date: Wed, 5 Mar 2014 20:00:35 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Wed, Mar 5, 2014 at 5:53 PM, Tim Peters wrote: > That's there because `utcoffset()` is defined to return minutes. > It returns either minutes *or a timedelta*: datetime.utcoffset()? If tzinfo is None, returns None, else returns self.tzinfo.utcoffset(self), and raises an exception if the latter doesn't return None, or a timedelta object representing a whole number of minutes with magnitude less than one day. tzinfo.utcoffset(*self*, *dt*) Return offset of local time from UTC, in minutes east of UTC. If local time is west of UTC, this should be negative. Note that this is intended to be the total offset from UTC; for example, if atzinfo object represents both time zone and DST adjustments, utcoffset() should return their sum. If the UTC offset isn't known, return None. Else the value returned must be a timedeltaobject specifying a whole number of minutes in the range -1439 to 1439 inclusive (1440 = 24*60; the magnitude of the offset must be less than one day). A > rule is needed to specify how the naive time object and `utcoffset()` > interact to define the result. > Not sure why you attach 'naive' to time. Time objects carry units with them, unlike integers. I would say 'naive time value' in reference to an integer. Combining a time and an integer can be done by converting the time to minutes (which is a bit confusing since in most contexts in this class, minutes values are integers) or it can be done by interpreting the integer utcoffset result as minutes (as it is documented). > > Perhaps a reasonable improvement would be to change this to: > > > > a time object is considered to be true unless it represents exactly > midnight > > local time, > The above part is the key part of my suggested improvement. Reading the current documentation, the fact that it means midnight local time is falsey is not obvious. --- Bruce Learn how hackers think: http://j.mp/gruyere-security https://www.linkedin.com/in/bruceleban -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Thu Mar 6 05:07:13 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Wed, 5 Mar 2014 20:07:13 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> Message-ID: On Mar 5, 2014, at 17:34, Tim Peters wrote: > "I am altering the deal. Pray I don't alter it any further." There's > a reason Darth Vader wasn't proclaimed Python's BDFL ;-) I always assumed it was because he never contributed even a single patch. From tim.peters at gmail.com Thu Mar 6 05:13:59 2014 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 5 Mar 2014 22:13:59 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: [Tim] >> That's there because `utcoffset()` is defined to return minutes. [Bruce Leban] > It returns either minutes or a timedelta: I wrote the code and I wrote the docs. I know what it does ;-) Going into tedious detail (as the docs do) is simply irrelevant to the point here: utcoffset() returns minutes. Whether that's _spelled_ as an integer or as a timedelta, minutes is minutes is minutes. > ... >> A rule is needed to specify how the naive time object and `utcoffset()` >> interact to define the result. > Not sure why you attach 'naive' to time. Time objects carry units with them, > unlike integers. I would say 'naive time value' in reference to an integer. Start with the second paragraph of the datetime docs: There are two kinds of date and time objects: "naive" and "aware". Etc. I attached "naive" to "time" to make clear that I mean the time object stripped of its tzinfo attribute. An aware time object is a naive time object with a non-None tzinfo attribute. > .... > The above part is the key part of my suggested improvement. Reading the > current documentation, the fact that it means midnight local time is falsey > is not obvious. Before this thread, I had never heard anyone express it as "midnight local time" before. Now that I have heard it, eh - I don't find it a helpful way to view it. From alexander.belopolsky at gmail.com Thu Mar 6 05:15:31 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 5 Mar 2014 23:15:31 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Wed, Mar 5, 2014 at 11:00 PM, Bruce Leban wrote: > Not sure why you attach 'naive' to time. 'naive' is a defined term in the context of the datetime module. It means tzinfo is None. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Thu Mar 6 05:16:52 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Wed, 5 Mar 2014 20:16:52 -0800 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <5317CF11.20100@mrabarnett.plus.com> References: <5317B1D7.4090305@canterbury.ac.nz> <5317CF11.20100@mrabarnett.plus.com> Message-ID: <5119B096-30C7-4B36-BB59-BE0FEC9B599D@yahoo.com> On Mar 5, 2014, at 17:27, MRAB wrote: > In the UK we talk about "Bills" being put before Parliament. In the US also, except it's Congress, and most of our political discussion isn't about bills before Congress or anything else of political consequence. > It reminds me of that quotation about the UK and US: ?Two nations > divided by a common language?. In the UK you can pay a bill using a > cheque; in the US you can pay the check using bills (but a "check" is > also a (UK) cheque!). How many restaurants still accept cheques (or checks)? The only thing they're really used for anymore is paying money to the government... So this bit of confusion will die away. Pants, on the other hand, aren't going away any time soon. From greg.ewing at canterbury.ac.nz Thu Mar 6 05:41:11 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 17:41:11 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140305192419.GD28804@ando> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: <5317FC67.7060600@canterbury.ac.nz> Steven D'Aprano wrote: > There's also the argument from consistency: midnight is the zero point > of the day, and zero is falsey. Regarding midnight as a "zero point" is an arbitrary convention. The integer zero is not arbitrary, because it's the additive identity. There is no corresponding additive identity for times, because you can't add two times. -- Greg From greg.ewing at canterbury.ac.nz Thu Mar 6 05:46:46 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 17:46:46 +1300 Subject: [Python-ideas] Suggestion for standardized annotations In-Reply-To: References: Message-ID: <5317FDB6.5000806@canterbury.ac.nz> CFK wrote: > then it shouldn't be too hard > for a project to add its own UUID to the annotation dictionary. I can't see what benefit there is in bringing UIIDs into the picture. If you're suggesting that people write the UUIDs directly into their code as literals, that's *not* going to fly. It would be appallingly ugly and error-prone. The only way to make it usable would be to import the UUIDs from somewhere under human-readable names. But then there's no need to use UUIDs, any set of unique sentinel objects will do. -- Greg From mertz at gnosis.cx Thu Mar 6 05:59:48 2014 From: mertz at gnosis.cx (David Mertz) Date: Wed, 5 Mar 2014 20:59:48 -0800 Subject: [Python-ideas] Add "goto fail" to Python? In-Reply-To: References: Message-ID: This is *exactly* what Python does right now! class ToFailError(Exception): pass try: do_some_stuff() if (some_error): raise ToFailError do_other_stuff() try: thing_that_might_fail() except SomeOtherError: handle_it() except ToFailError: here_we_are() On Wed, Mar 5, 2014 at 7:54 PM, Sturla Molden wrote: > "goto fail" is a well-known error handling mechanism in open source > software, widely reputed for its robusteness: > > http://opensource.apple.com/source/Security/Security- > 55471/libsecurity_ssl/lib/sslKeyExchange.c > > https://www.gitorious.org/gnutls/gnutls/source/ > 6aa26f78150ccbdf0aec1878a41c17c41d358a3b:lib/x509/verify.c > > I believe Python needs to add support for this superior paradigm. > > It would involve a new keyword "fail" and some means of goto'ing to it. I > suggest "raise to fail": > > if (some_error): > raise to fail > > fail: > > > Unless there are many objections, this fantastic idea might be submitted > in a (short) PEP somewhere around the beginning of next month. > > There is some obvious overlap with the rejected "goto PEP" (PEP 3163) and > the Python 2.3 goto module. However, the superiority of goto fail as error > generation and error handling paradigm has since then been thoroughly > proven. > > http://legacy.python.org/dev/peps/pep-3136/ > http://entrian.com/goto/download.html > > > Regards, > Sturla Molden > > > > > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce at leapyear.org Thu Mar 6 06:16:49 2014 From: bruce at leapyear.org (Bruce Leban) Date: Wed, 5 Mar 2014 21:16:49 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Wed, Mar 5, 2014 at 8:13 PM, Tim Peters wrote: > [Tim] > >> That's there because `utcoffset()` is defined to return minutes. > > [Bruce Leban] > > It returns either minutes or a timedelta: > > I wrote the code and I wrote the docs. I know what it does ;-) Going > into tedious detail (as the docs do) is simply irrelevant to the point > here: utcoffset() returns minutes. Whether that's _spelled_ as an > integer or as a timedelta, minutes is minutes is minutes. > Just because you wrote the docs doesn't mean you know what they mean to other readers. The point of documentation is to explain it to someone who doesn't know what it does after all. > > > Start with the second paragraph of the datetime docs: > > There are two kinds of date and time objects: "naive" and "aware". > Thanks. Before this thread, I had never heard anyone express it as "midnight > local time" before. Now that I have heard it, eh - I don't find it a > helpful way to view it. Well, it's not surprising that you don't find it's helpful. In fact, it's wrong, which to me indicates how confusing this. Which of the following are falsey? 00:00:00+01:00 01:00:00+01:00 01:00:00-01:00 07:00:00+07:00 23:00:00-01:00 I find it particularly surprising that the bug that the OP described finding would occur in the Russia and China, but not in the US. Obviously, not an accident. :-) --- Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Thu Mar 6 06:18:47 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 18:18:47 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317A4BB.1090303@egenix.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <5317A4BB.1090303@egenix.com> Message-ID: <53180537.1050708@canterbury.ac.nz> M.-A. Lemburg wrote: > The reasoning becomes clear if you regard a time value as > number of seconds since midnight (the time of day is a relative > measure). But there's no clear reason to regard that particular way of representing a time of day as superior to any other. -- Greg From greg.ewing at canterbury.ac.nz Thu Mar 6 06:22:07 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 18:22:07 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317A696.8040605@egenix.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> Message-ID: <531805FF.8070409@canterbury.ac.nz> M.-A. Lemburg wrote: > This is true in a date/time continuum, but not true if you regard > time as "time of day". In the latter interpretation, the day starts > at midnight, That's not always the most convenient way of looking at it. For example, for booking a stay in a hotel, it may be better to think of "nights" as stretching from midday to midday. -- Greg From greg.ewing at canterbury.ac.nz Thu Mar 6 06:30:21 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 18:30:21 +1300 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <29275C71-F3DC-4D4A-A251-B56AED14E6C1@masklinn.net> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> <05894993-3C4D-42E7-9328-C3365DF92CBE@masklinn.net> <53179C51.4020001@canterbury.ac.nz> <29275C71-F3DC-4D4A-A251-B56AED14E6C1@masklinn.net> Message-ID: <531807ED.3020003@canterbury.ac.nz> Masklinn wrote: > On 2014-03-05, at 22:51 , Greg Ewing wrote: >>Also, Haskell has the advantage of knowing that the value >>won't change > > I do not see why that would be relevant to thunks. The result of the > thunk may be mutable, so what? That's not what I mean. The value of the thunk can depend on other things that change. In general you can't get away with evaluating it once and caching the result. -- Greg From sturla.molden at gmail.com Thu Mar 6 06:30:01 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 6 Mar 2014 05:30:01 +0000 (UTC) Subject: [Python-ideas] Add "goto fail" to Python? References: Message-ID: <444107387415775972.062814sturla.molden-gmail.com@news.gmane.org> David Mertz wrote: > This is *exactly* what Python does right now! I know, it would by syntaxic sugar for try-except. I am worried that Python's significant indentation might interfere with some of the strengths of "goto fail", for example placement of code that could be vital for national security. We might therefore need an exception to the indentation syntax so that if (error): raise to fail raise to fail is interpreted as if (error): raise to fail raise to fail if 1: Sturla From greg.ewing at canterbury.ac.nz Thu Mar 6 06:34:49 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 18:34:49 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317B1BE.4090804@egenix.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <5317AE64.90007@egenix.com> <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> <5317B1BE.4090804@egenix.com> Message-ID: <531808F9.1020605@canterbury.ac.nz> M.-A. Lemburg wrote: > Well, the duration between the start of day and midnight is zero > and returning to the interpretation of time of day being a measurement > relative to midnight, The point of having time objects as an abstraction is so that you *don't* have to think of them as an offset from anything. You simply think of them as times. -- Greg From greg.ewing at canterbury.ac.nz Thu Mar 6 06:38:40 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 18:38:40 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <5317AE64.90007@egenix.com> <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> Message-ID: <531809E0.6000905@canterbury.ac.nz> Alexander Belopolsky wrote: > For me, it is the fraction of the day that passed or distance from > midnight and in any case fundamentally some kind of number expressed in > a Babylonian base-60 notation. Yes, and that number is conventionally written as "12:00", which is *obviously* equal to zero... er, what? -- Greg From guido at python.org Thu Mar 6 06:42:22 2014 From: guido at python.org (Guido van Rossum) Date: Wed, 5 Mar 2014 21:42:22 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <531809E0.6000905@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <5317AE64.90007@egenix.com> <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> <531809E0.6000905@canterbury.ac.nz> Message-ID: The 12:00 notation is US-centric. Or, perhaps, common in Anglophone countries. The rest of the world does not use the AM/PM conventions and calls midnight 00:00. On Wed, Mar 5, 2014 at 9:38 PM, Greg Ewing wrote: > Alexander Belopolsky wrote: > >> For me, it is the fraction of the day that passed or distance from >> midnight and in any case fundamentally some kind of number expressed in a >> Babylonian base-60 notation. >> > > Yes, and that number is conventionally written as > "12:00", which is *obviously* equal to zero... er, > what? > > -- > Greg > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Thu Mar 6 05:05:37 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Wed, 5 Mar 2014 20:05:37 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> Message-ID: <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> On Wednesday, March 5, 2014 9:47:24 PM UTC-6, Guido van Rossum wrote: > > I wonder if we need yet another list, python-speculative-ideas? Or > python-waxing-philosophically? > hi Guido, no probably not. I just got to thinking again about *number *again as I was thinking about decimal floating point as default. Its the mathematician in me; go for the general case, and that would be a type-less unified *number *system. For the near case design issues the following realist ideas might be considered in order: 1) decimal literal like 1.23d 2) default decimal floating point with a binary type 1.23b 3) type-less unified *number *yes, probably way out there into the future kind regards, marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Thu Mar 6 06:50:10 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 18:50:10 +1300 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <5317CF11.20100@mrabarnett.plus.com> References: <5317B1D7.4090305@canterbury.ac.nz> <5317CF11.20100@mrabarnett.plus.com> Message-ID: <53180C92.7070904@canterbury.ac.nz> MRAB wrote: > In the UK we talk about "Bills" being put before Parliament. In NZ too, but once it's passed, it's the law -- it's not up to individual interpretation! -- Greg From tim.peters at gmail.com Thu Mar 6 06:53:19 2014 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 5 Mar 2014 23:53:19 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: [Bruce Leban ] > ... > Just because you wrote the docs doesn't mean you know what they mean to > other readers. The point of documentation is to explain it to someone who > doesn't know what it does after all. Of course. What's your point here? >> ... >> Before this thread, I had never heard anyone express it as "midnight >> local time" before. Now that I have heard it, eh - I don't find it a >> helpful way to view it. > Well, it's not surprising that you don't find it's helpful. In fact, it's > wrong, which to me indicates how confusing this. Bruce, you're the one who made up the "midnight local time" business, which has just confused you. Try again to read what the docs actually say, without assuming it must mean something else? > Which of the following are falsey? It would help a lot if you explained which ones surprised _you_, and how you read the docs in such a way that what they actually say caused your confusion. > 00:00:00+01:00 Convert the naive time to minutes: 0. Get the UTC offset in minutes (these offsets are always returned directly as minutes in the code, but there's an "extra" calculation step needed here because you're starting from a string representation that also uses units of hours): 1*60 + 0 = 60. Subtract: 0-60 = -60 Is that zero? No, so this one is true. > 01:00:00+01:00 60 - 60 = 0. False. > 01:00:00-01:00 60 - -60 = 120. True. > 07:00:00+07:00 420 - 420 = 0. False. > 23:00:00-01:00 23*60 - -60 = 24*60. True. > I find it particularly surprising that the bug that the OP described finding > would occur in the Russia and China, but not in the US. Obviously, not an > accident. :-) Indeed, it is the key to liberating both Ukraine and Tibet ;-) From guido at python.org Thu Mar 6 06:56:02 2014 From: guido at python.org (Guido van Rossum) Date: Wed, 5 Mar 2014 21:56:02 -0800 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> Message-ID: Do you actually have a degree in math, or do you just remember your high school algebra? The numbers in math usually are quite strictly typed: whole theories only apply to integers or even positive integers, other things to all reals but not to complex numbers. (And what about quaternions? Or various infinities? :-) On Wed, Mar 5, 2014 at 8:05 PM, Mark H. Harris wrote: > > > On Wednesday, March 5, 2014 9:47:24 PM UTC-6, Guido van Rossum wrote: >> >> I wonder if we need yet another list, python-speculative-ideas? Or >> python-waxing-philosophically? >> > > hi Guido, no probably not. I just got to thinking again about *number *again > as > I was thinking about decimal floating point as default. Its the > mathematician in me; go > for the general case, and that would be a type-less unified *number * > system. > > For the near case design issues the following realist ideas might be > considered in order: > > 1) decimal literal like 1.23d > > 2) default decimal floating point with a binary type 1.23b > > 3) type-less unified *number *yes, probably way out there into the future > > > kind regards, > marcus > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Thu Mar 6 07:47:12 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 6 Mar 2014 01:47:12 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Thu, Mar 6, 2014 at 12:16 AM, Bruce Leban wrote: > Well, it's not surprising that you don't find it's helpful. In fact, it's > wrong, which to me indicates how confusing this. Which of the following are > falsey? > > 00:00:00+01:00 > 01:00:00+01:00 > 01:00:00-01:00 > 07:00:00+07:00 > 23:00:00-01:00 > > > I find it particularly surprising that the bug that the OP described > finding would occur in the Russia and China, but not in the US. Obviously, > not an accident. :-) > "Aware" time objects are problematic even before you consider their bool behavior. Fortunately, you don't encounter them too often because dt.time() returns naive time even if dt is an aware datetime instance. Again, the use case that I find compelling is to test dt.time() for falsehood to detect datetime objects that fall on midnight. I don't understand why people are denying that midnights are special points. All real numbers are equal, but integers are more equal than others. When you plot say hourly timeseries it is not uncommon to mark midnight ticks on the time axis with dt.date() and other ticks with dt.hour. Whenever you need to do something special when you start a new date in a simulation of a physical process it is convenient to have a simple test for midnight. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Thu Mar 6 07:51:06 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 19:51:06 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> Message-ID: <53181ADA.2030401@canterbury.ac.nz> Tim Peters wrote: > For example, modular arithmetic on time > objects was a possibility. In that case, time(0, 0, 0) would become > "a zero value" That only follows if you interpret "modular arithmetic on time objects" as meaning that you can directly add one time object to another. But that would be confusing times with timedeltas. The concept of a zero *timedelta* makes sense, but not a "zero time". > People can say that "midnight" isn't a compelling "sentinel value", > and I agree about the "compelling" part, but in all implementation > respects it does _act_ as "a sentinel value". If someone is using midnight to represent an unspecified time, I'd say they have a bug. An appointment scheduled at midnight is not the same as an appointment that's not scheduled at all. -- Greg From bruce at leapyear.org Thu Mar 6 08:02:34 2014 From: bruce at leapyear.org (Bruce Leban) Date: Wed, 5 Mar 2014 23:02:34 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Wed, Mar 5, 2014 at 10:47 PM, Alexander Belopolsky < alexander.belopolsky at gmail.com> wrote: > it is convenient to have a simple test for midnight. > Except this isn't it. That's only works for naive times. For aware times: 00:00:00+00:00 = midnight England = midnight UTC => False 00:00:00+01:00 = midnight France = 2300 UTC => True 01:00:00+01:00 = 1 am France = midnight UTC => False 19:00:00-05:00 = 1 am Boston = midnight UTC => True Code that relies that bool(time) is False for midnight is broken IMHO. --- Bruce Learn how hackers think: http://j.mp/gruyere-security https://www.linkedin.com/in/bruceleban -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Thu Mar 6 08:20:30 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 6 Mar 2014 02:20:30 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Thu, Mar 6, 2014 at 2:02 AM, Bruce Leban wrote: > > On Wed, Mar 5, 2014 at 10:47 PM, Alexander Belopolsky < > alexander.belopolsky at gmail.com> wrote: > >> it is convenient to have a simple test for midnight. >> > > Except this isn't it. That's only works for naive times. For aware times: > > 00:00:00+00:00 = midnight England = midnight UTC => False > 00:00:00+01:00 = midnight France = 2300 UTC => True > 01:00:00+01:00 = 1 am France = midnight UTC => False > 19:00:00-05:00 = 1 am Boston = midnight UTC => True > > Code that relies that bool(time) is False for midnight is broken IMHO. > > You keep fighting your own straw-man. My use case is not using an arbitrary time object that someone decided to imbue with a timezone info. What I want is given a *datetime* instance dt to check whether it falls on midnight in whatever timezone dt.tzinfo represent or naively if dt.tzinfo is None. I claim that "if dt.time()" is a perfectly good shorthand for "if dt.time() != datetime.time(0)". I am not trying to argue that "if not dt.timetz()" test is equally useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at xemacs.org Thu Mar 6 08:29:20 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 06 Mar 2014 16:29:20 +0900 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <29275C71-F3DC-4D4A-A251-B56AED14E6C1@masklinn.net> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> <05894993-3C4D-42E7-9328-C3365DF92CBE@masklinn.net> <53179C51.4020001@canterbury.ac.nz> <29275C71-F3DC-4D4A-A251-B56AED14E6C1@masklinn.net> Message-ID: <87y50npyy7.fsf@uwakimon.sk.tsukuba.ac.jp> Masklinn writes: > On 2014-03-05, at 22:51 , Greg Ewing wrote: > > Masklinn wrote: > >> On 2014-03-04, at 23:31 , Greg Ewing wrote: > > That comes at the expense of making *everything* a thunk > > until its value is needed [in Haskell]. > > Of course not, Haskell allows explicitly forcing a thunk and the > compiler/runtime pair can use strictness analysis and not create thunks > in the first place. That doesn't seem fair to me. "Explicitly forcing" by definition means the programmer has decided the value is needed, and "strictness analysis" is an optimization, not part of the language definition. Am I missing something? > Consider that a thunk is a deferral of an expression's evaluation, > why would said expression's evaluation happen more than once? The > only thing which changes is *when* the actual evaluation happens. Are thunks guaranteed not to leak out of the scope of the containing expression, so assignment is impossible? If they can leak, the thunk would be an object, and in Python "assigning" it to a "variable" actually just creates a reference. Evaluation could memoize the thunk's value ("evaluation only happens once") or reevaluate the thunk each time its value is requested. Either seems potentially surprising to me. Memoization makes sense if you think of the thunk as the closure of a computation that conceptually takes place at definition time. I'm not sure if in the use cases for thunks it really makes sense to "close" the thunk at evaluation time, but it seems like a plausible interpretation to me. From donald at stufft.io Thu Mar 6 08:30:39 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 02:30:39 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: <11438CE8-253F-463B-B9B4-6C2EE9958A89@stufft.io> On Mar 6, 2014, at 2:20 AM, Alexander Belopolsky wrote: > > > > On Thu, Mar 6, 2014 at 2:02 AM, Bruce Leban wrote: > > On Wed, Mar 5, 2014 at 10:47 PM, Alexander Belopolsky wrote: > it is convenient to have a simple test for midnight. > > Except this isn't it. That's only works for naive times. For aware times: > > 00:00:00+00:00 = midnight England = midnight UTC => False > 00:00:00+01:00 = midnight France = 2300 UTC => True > 01:00:00+01:00 = 1 am France = midnight UTC => False > 19:00:00-05:00 = 1 am Boston = midnight UTC => True > > Code that relies that bool(time) is False for midnight is broken IMHO. > > > You keep fighting your own straw-man. My use case is not using an arbitrary time > object that someone decided to imbue with a timezone info. What I want is given > a *datetime* instance dt to check whether it falls on midnight in whatever timezone > dt.tzinfo represent or naively if dt.tzinfo is None. So check for it falling on midnight. It?s not reasonable to expect that midnight will evaluate to false, especially when it doesn?t if you happen to have a tzinfo on the time (sometimes!). That makes the behavior even more surprising and more footgun-ey. > > I claim that "if dt.time()" is a perfectly good shorthand for "if dt.time() != datetime.time(0)?. And I claim that you?re reaching to justify stupid behavior. > > I am not trying to argue that "if not dt.timetz()" test is equally useful And yet you can?t control what people do with it. Consistency is a virtue and how objects act with a tzinfo and how they act without a tzinfo should be as close as possible. > . > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From shai at platonix.com Thu Mar 6 08:25:26 2014 From: shai at platonix.com (Shai Berger) Date: Thu, 06 Mar 2014 09:25:26 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306030002.GH28804@ando> References: <201403051216.12392.shai@platonix.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <20140306030002.GH28804@ando> Message-ID: <1978788.hqjmn1vSZ0@deblack> On Thursday 06 March 2014 14:00:02 Steven D'Aprano wrote: > tracking down bugs can be difficult, but if somebody is spending "hours" > trying to debug why "if time_value" sometimes does the wrong thing, > *without* bothering to read the documentation for time objects to find > out how they're supposed to behave, then I don't have a lot of sympathy. > This argument keeps repeating. It is a gross misunderstanding of the problem. The hours are not spent trying to debug why an if went the wrong way. The hours are spent trying to understand why some feature of a program doesn't work as expected -- *sometimes*. It can easily take hours to try and reproduce the wrong behavior, in vain, because it only shows up on unique data; and the wrong behavior will often not show itself as "an if went the wrong way", but, for example, "sometimes a number here is wrong" -- which happens when the calculation of the number goes over a collection of objects and does complex things including decisions based on time. Of course, once you get to the "if" it's relatively easy (surprising behavior is still surprising, but less mystifying). It's getting to it that's the issue. Thanks, Shai. From greg.ewing at canterbury.ac.nz Thu Mar 6 08:33:43 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Mar 2014 20:33:43 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: <531824D7.8020302@canterbury.ac.nz> Bruce Leban wrote: > Except this isn't it. That's only works for naive times. For aware times: > > 00:00:00+00:00 = midnight England = midnight UTC => False > 00:00:00+01:00 = midnight France = 2300 UTC => True > 01:00:00+01:00 = 1 am France = midnight UTC => False > 19:00:00-05:00 = 1 am Boston = midnight UTC => True That's... I don't know what it is. Is there a rationale for this? I'm totally failing to see it. -- Greg From alexander.belopolsky at gmail.com Thu Mar 6 08:40:24 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 6 Mar 2014 02:40:24 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <11438CE8-253F-463B-B9B4-6C2EE9958A89@stufft.io> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <11438CE8-253F-463B-B9B4-6C2EE9958A89@stufft.io> Message-ID: On Thu, Mar 6, 2014 at 2:30 AM, Donald Stufft wrote: > It?s not reasonable to expect that midnight will evaluate > to false, .. > Only in the world where it is not reasonable to expect programmers to read library documentation. In my world it is reasonable to expect that the behavior that was documented in 10 major versions and for 10 years can be relied on. > especially when it doesn?t if you happen to have a tzinfo on the time > (sometimes!). > As long as tzinfo specifies a fixed offset, there is no problem with the current definition. If you are unfortunate enough to live in a place with semi-annual DST adjustment, aware time objects are problematic for reasons that have nothing to do with the discussion at hand. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Mar 6 08:43:18 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 02:43:18 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <11438CE8-253F-463B-B9B4-6C2EE9958A89@stufft.io> Message-ID: On Mar 6, 2014, at 2:40 AM, Alexander Belopolsky wrote: > > On Thu, Mar 6, 2014 at 2:30 AM, Donald Stufft wrote: > It?s not reasonable to expect that midnight will evaluate > to false, .. > > Only in the world where it is not reasonable to expect programmers to read library documentation. In my world it is reasonable to expect that the behavior that was documented in 10 major versions and for 10 years can be relied on. > > > especially when it doesn?t if you happen to have a tzinfo on the time (sometimes!). > > As long as tzinfo specifies a fixed offset, there is no problem with the current definition. If you are unfortunate enough to live in a place with semi-annual DST adjustment, aware time objects are problematic for reasons that have nothing to do with the discussion at hand. > Nope! It essentially in an aware time would be ?false if whatever time is at the same time as UTC midnight, but only if your UTC offset is positive?. If your UTC offset is negative then you end up with 1440 instead of 0. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From markus at unterwaditzer.net Thu Mar 6 08:38:41 2014 From: markus at unterwaditzer.net (Markus Unterwaditzer) Date: Thu, 06 Mar 2014 08:38:41 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306021457.GF28804@ando> References: <201403051216.12392.shai@platonix.com> <20140306021457.GF28804@ando> Message-ID: <556cc654-167b-4d06-8c30-77c414e54069@email.android.com> On 6 March 2014 03:14:57 CET, Steven D'Aprano wrote: >On Wed, Mar 05, 2014 at 04:31:36PM -0500, Donald Stufft wrote: > >> I find the argument that it would only be fixed in 3.something and >thus not be really >> fixed for X years disingenuous at best. That fact is true for *ALL* >bug fixes in Python >> so by that logic we should simply give up on fixing anything in >Python ever? > >Not at all. But it does mean that the benefit of fixing it needs to be >worth the wait. Suppose we said "Sure, we'll fix it, but you have >to pay for the fix." How much would you be willing to pay to have it >fixed? > >("Pay" doesn't have to mean money. It can also mean, how much pain or >inconvenience are you willing to experience, or how much time and >effort >are you willing to out into this.) > >If I said, "Oh by the way, although you have to pay right now, you >won't >see any benefit until 2024", now how much are you willing to pay? > >Design flaws are more costly to fix than outright bugs, not because >they >take more time and effort to change, but because you're changing >behaviour that *somebody out there is relying on*. Just because "somebody" is relying on a wart in the language it doesn't mean that this person is knowing what they are doing, is representative of the rest of Python users or that the wart shouldn't be removed. In my opinion it even means that the person is a bad programmer in a way, because even though he is relying documented behavior, that behavior is relatively unknown and using it intentionally certainly doesn't help readability. Actually i think that this programmer put extra effort into making their own code less readable. Partially, this point has already been made many times in this thread, but apparently this doesn't suffice to make the opposing side realize or respond to it. What you consider a >terrible misfeature is *somebody's* critical feature, and you're >proposing that we take that away. That's okay, we can do that after a >suitable deprecation period. (You wouldn't want us to break your code, >so you ought to extend the same courtesy to other people.) > >But even if there isn't anyone relying on this, and we fix it as soon >as >possible (which will be 3.5), your library *still* can't rely on it >until it drops all support for versions below 3.5. Arguably many libraries already do rely on this currently nonexistent feature. >Since you can't rely > >on that feature being present, you have to write your library code as >if >it wasn't present. So there is *absolutely no difference* between your >library with this (alleged) bug being fixed, or it not being fixed. > >The situation for application developers is a bit different. An >application developer can simply say, I'm going to immediately migrate >to 3.5 to take advantage of this new feature/bug fix. That's okay too. > >The job of the core developers is to balance all these competing >interests: the library developers, the application developers, the >users >who don't care one way or another but do care about some other bug >that's not being fixed because people are arguing about this one, the >people (actual or hypothetical) who actually like this (mis)feature the > >way it is, people who don't like it but have written code that relies >on >it, and, yes, even the core developers themselves, who are perfectly >entitled to say that the effort in fixing this is greater than the >benefit so they're not going to do it. > >If you haven't already read Nick's blog posts on these issues, you >should: > >http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html >http://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html > > >For what it's worth, I think the current behaviour is a misfeature, and > >in a perfect world it would be fixed. But the cost of this is so >miniscule, and the work-around so trivial, that although the fix is >cheap, the benefit is even lower. I've only spent a few minutes reading > >and responding to this thread. Those few minutes are already worth far >more than any benefit to me in fixing this. That's *my* personal >opinion >on this, others may differ, so I'm a +0 on deprecating the behaviour in > >3.5 and changing it in 3.6 or 3.7, and -0.5 on changing it immediately >in 3.5. From donald at stufft.io Thu Mar 6 08:49:11 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 02:49:11 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <11438CE8-253F-463B-B9B4-6C2EE9958A89@stufft.io> Message-ID: On Mar 6, 2014, at 2:43 AM, Donald Stufft wrote: > > On Mar 6, 2014, at 2:40 AM, Alexander Belopolsky wrote: > >> >> On Thu, Mar 6, 2014 at 2:30 AM, Donald Stufft wrote: >> It?s not reasonable to expect that midnight will evaluate >> to false, .. >> >> Only in the world where it is not reasonable to expect programmers to read library documentation. In my world it is reasonable to expect that the behavior that was documented in 10 major versions and for 10 years can be relied on. >> >> >> especially when it doesn?t if you happen to have a tzinfo on the time (sometimes!). >> >> As long as tzinfo specifies a fixed offset, there is no problem with the current definition. If you are unfortunate enough to live in a place with semi-annual DST adjustment, aware time objects are problematic for reasons that have nothing to do with the discussion at hand. >> > > Nope! It essentially in an aware time would be ?false if whatever time is at the same time as UTC midnight, but only if your UTC offset is positive?. If your UTC offset is negative then you end up with 1440 instead of 0. > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ Actually now that I think about it more, in aware times it?s impossible for it to time objects to ever be false if the tzinfo is negative, because that would require the time to negative. Take -5 for instance: x - (-5 * 60) = 0 x - (-300) = 0 x + 300 = 0 x = -300 So in order for a time with UTC offset of -5 to ever be False, it would have to be -05:00:00 there. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From markus at unterwaditzer.net Thu Mar 6 08:53:46 2014 From: markus at unterwaditzer.net (Markus Unterwaditzer) Date: Thu, 06 Mar 2014 08:53:46 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <11438CE8-253F-463B-B9B4-6C2EE9958A89@stufft.io> Message-ID: <5392dc1c-26e8-4963-a47e-d5d624fea853@email.android.com> On 6 March 2014 08:40:24 CET, Alexander Belopolsky wrote: >On Thu, Mar 6, 2014 at 2:30 AM, Donald Stufft wrote: > >> It?s not reasonable to expect that midnight will evaluate >> to false, .. >> > >Only in the world where it is not reasonable to expect programmers to >read >library documentation. I disagree. Consider this code: class MyType: def __bool__(self): return bool(random.random()) Even though the behavior in boolean context is documented, it doesn't have to make any sense or be reasonable. >In my world it is reasonable to expect that the >behavior that was documented in 10 major versions and for 10 years can >be >relied on. > It *is* reasonable to expect to be able to rely on such features, yet IMO it is not reasonable to actually rely on that feature, for reasons of readability already mentioned by me in a reply to Steven D'Aprano. Considering that (from my subjective view) many people new to Python expect the kind of behavior proposed by the OP, i think it might be time for a change. Maybe an actual survey is the only way to find out. > > >> especially when it doesn?t if you happen to have a tzinfo on the time >> (sometimes!). >> > >As long as tzinfo specifies a fixed offset, there is no problem with >the >current definition. If you are unfortunate enough to live in a place >with >semi-annual DST adjustment, aware time objects are problematic for >reasons >that have nothing to do with the discussion at hand. > > >------------------------------------------------------------------------ > >_______________________________________________ >Python-ideas mailing list >Python-ideas at python.org >https://mail.python.org/mailman/listinfo/python-ideas >Code of Conduct: http://python.org/psf/codeofconduct/ From harrismh777 at gmail.com Thu Mar 6 09:14:11 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 00:14:11 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> Message-ID: On Wednesday, March 5, 2014 11:56:02 PM UTC-6, Guido van Rossum wrote: > > Do you actually have a degree in math, or do you just remember your high > school algebra? > hi Guido, ouch. Its a story, glad you asked. My first trip to college 1974-1977 (UMKC) was to study EE; minor in mathematics. I completed my math course work (Calc 1-5, Diff Eq, Linear Algebra, Theory of Stats and Prob, &c) ... all (A). Not that it matters, because in 1977 IBM made me an offer in their CE department at Kansas City... so I joined IBM for the next 25 years and did not complete my EE degree... but, I did complete my mathematics training. Of course, prior to UMKC I attended a high school that offered calculus, math analysis, trig... and intro to linear algebra. So by the time I joined IBM I got the math twice. So, yeah, I know what I'm doing. I am an amateur mathematician today, computer scientist, and computer hobbyist. While at IBM I was a staff software engineer, Tampa, Chicago, Atlanta, and at the lab at Rochester MN (where I left IBM in 2002; yet I still dwell there). Education is a life long commitment and I continue to study math, comp sci, music and philosophy. I just completed my course work for the MDiv degree at Bethel Seminary. Back in the day, I added the scientific and transcendental math functions to the Rexx library for the internal VM370 systems, because Rexx (like python) also had no decimal floating point math package. So, yeah, its one of the things I know how to do, and its one of those things that most people never think about; but I've noticed that they appreciate having it once the work is done. My pdeclib package on PyPI is in infancy stage, probably has bugs (yet nobody has complained yet) and pdeclib will have to mature there for some time. But that has really nothing to do with whether we continue to use IEEE 754 1985 floats & doubles nor whether we discuss default decimal floating point arithmetic nor whether we discuss a unified *python number *sytem (sometime in the distant future) that would make | allow common average ordinary people to leverage mathematics in computer science without having to understand the underlying mechanics of implementation including but not limited to types. We might agree to stick with the discussion, if you're are willing, and stay away from *ad hominem* attacks, nor credential bashing. A person either knows what they are doing, or they don't. And if they are willing to contribute, why knock it, or them? > The numbers in math usually are quite strictly typed: whole theories only > apply to integers or even positive integers, other things to all reals but > not to complex numbers. > Everyone keeps making the points noted above! Yes, I know... concur~ Guido, all data types in most computer high level languages are all very strictly statically bound also. So what? You know this better than anyone, because you have taken so much abuse from trolls about it over the years. We all know that the best way to handle name binding is dynamically. And that was a paradigm shift, was it not? Go take a look at Rexx. It has NO types. None. Not at the surface, anyway. Everything to the user of the language is a string. This is even true for most of "object" Rexx too. *Numbers *are just strings of characters that are parsed and interpreted by Rexx as valid *Rexx Numbers*. It works. There is no real point in arguing that its a bad idea, because it served the Rexx community for many years... even now, Rexx is not dead. Yes, under the covers (not magic) a complex number is going to be handled differently than a real number. Yeah, what is your point? They are handled differently in my TI 89 too... so what, I change the context on the 89 and now I'm doing complex number math (not often, I might add). If I set the context for reals, then now I'm doing real math... it really is not that difficult. Think about this for just a minute. I have used complex math exactly three times in my life. I used it in high school to study the concept in math analysis. I used it in my EE classes... electrical engineers get a lot out of complex numbers. And I used it when I was interested in the Mendlebrot set many years ago when it was cool to plot the famous fractal on early cga screens. When was the last time you used complex numbers? When was the last time a bank, or a hospital, or Montgomery Wards used complex numbers? If someone needs complex numbers, Python could change the context "dynamically" and move through the problem set. Why should the user need to "manually" change the context if (AI) could change it for them on-the-fly? Just try to get a feel for the question, and stop with trying to beat me up on my credentials. > (And what about quaternions? Or various infinities? :-) > What about quaternions? If you extend the complex number system you change the context. That's not hard... You would not expect the context for "reals" processing to be the same for the context of processing three dimensional space with pairs of complex numbers, would you? Python does complex number processing now. But that is a very specialized category of use case that requires special context and (under the covers) typing relevant to complex number pairs. The context can change "dynamically" to suit the problem set, that's all I'm saying. I am not saying in all of my dreaming here that typing is not important (down under). Python is called an object based language, yes? Not object oriented, right? But we all know that down under the covers (not magic) python uses Classes and instances of classes--objects. We don't pretend that what makes object based languages work is magic? do we? Unifying the number system on a computer does not have to be grounded in paradigms that serviced the industry (and academy) for the past 40 years; mostly because memory was expensive and processing was slow. I suggest that if memory had been cheap, back in the day, and processing had been very fast (as it is today) IEEE 754 1985 floats and doubles would never have been used. We would have used Decimal floating points right from the get-go. Initially, that really is all I'm asking for on the outset--- lets move to default decimal floating point arithmetic for real numbers processing. In the future I am thinking about systems of languages that interact with human speech; understanding *spoken number* just like they will understand *symbol number.* There is really no reason (other than paradigm) that this would not be possible either. Otherwise, Guido, we might all of us just continue to use C and code up our statically bound types by hand using nothing but int, long, float, and double. Its time to innovate. Kind regards, BDfL, marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at xemacs.org Thu Mar 6 09:34:06 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 06 Mar 2014 17:34:06 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: <87wqg7pvy9.fsf@uwakimon.sk.tsukuba.ac.jp> Yann Kaiser writes: > if event.date: > schedule_event() > > I cannot fathom one example where it could read as "does the party > start at midnight?". Can you? No, because it obviously reads as "... WTF??!?"[1] Of course, that's because I've imbibed of the "Python is not C or C++" Kool-Aid, but I just don't see why we should encourage C idioms in Python when there are plenty of other cases where use of a bare expression rather "... is None" can bite. I find Skip Montanaro's implied issue Please reconsider the Boolean evaluation of None far more plausible. Footnotes: [1] if event.date: print("Happy New Year/Century/Millennium!") From mal at egenix.com Thu Mar 6 09:35:59 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 09:35:59 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> Message-ID: <5318336F.7030009@egenix.com> On 06.03.2014 03:23, Donald Stufft wrote: > > On Mar 5, 2014, at 9:15 PM, Tim Peters wrote: > >> [Donald Stufft] >>> When the documented behavior is both nonsensical and the cause of hard to debug bugs that >>> is a pretty compelling use case to me, unless you actively enjoy being user hostile. >> >> Breaking code that currently works is as hostile as hostile gets. Where is the evidence that >> no code relies on the current behavior? For that matter, where is the evidence that the >> current behavior is a significant cause of bugs? I know I've used "if some_time_object:", >> but it did exactly what I expected it to do. > > Forgive me if I?m wrong, but aren?t you the author of the date time module? If that?s the case > what you expect it to do isn?t particularly relevant as you?re intimately aware of it?s > implementation. Just in case you're looking for a relevant use case: Having bool(time(0,0,0)) allows you to quickly check whether you are dealing with a datetime value with (non-trivial) time part or not. You run into situations where you have to test for this in date/time conversions, arithmetics, etc. e.g. if you need to convert a datetime value to a date and want to prevent truncation of information, or if you want to format a datetime value in a user friendly way by omitting the zero time part, or if you're doing datetime arithmetic that has to follow special requirements w/r to days (think interest or insurance math) and you want to quickly check whether you can use the fast path simple calculation, or you need to do the full blown complicated part. Now, those use cases may still not appear relevant to you, but then the argument that "if x:" should not trigger for time(0,0,0) because x might actually be None, is also not relevant to me, since it masks a bug in the example code and those should never go undetected :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, >>> mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From donald at stufft.io Thu Mar 6 09:46:17 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 03:46:17 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5318336F.7030009@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: On Mar 6, 2014, at 3:35 AM, M.-A. Lemburg wrote: > On 06.03.2014 03:23, Donald Stufft wrote: >> >> On Mar 5, 2014, at 9:15 PM, Tim Peters wrote: >> >>> [Donald Stufft] >>>> When the documented behavior is both nonsensical and the cause of hard to debug bugs that >>>> is a pretty compelling use case to me, unless you actively enjoy being user hostile. >>> >>> Breaking code that currently works is as hostile as hostile gets. Where is the evidence that >>> no code relies on the current behavior? For that matter, where is the evidence that the >>> current behavior is a significant cause of bugs? I know I've used "if some_time_object:", >>> but it did exactly what I expected it to do. >> >> Forgive me if I?m wrong, but aren?t you the author of the date time module? If that?s the case >> what you expect it to do isn?t particularly relevant as you?re intimately aware of it?s >> implementation. > > Just in case you're looking for a relevant use case: > > Having bool(time(0,0,0)) allows you to quickly check whether you are > dealing with a datetime value with (non-trivial) time part or not. I don?t see how midnight is any more or less trivial than 12:01. > > You run into situations where you have to test for this in > date/time conversions, arithmetics, etc. e.g. if you need to convert > a datetime value to a date and want to prevent truncation of > information, or if you want to format a datetime value in a user > friendly way by omitting the zero time part, or if you're doing > datetime arithmetic that has to follow special requirements w/r to > days (think interest or insurance math) and you want to > quickly check whether you can use the fast path simple > calculation, or you need to do the full blown complicated part. I think these would be better served by actually checking for what you mean. For the record I also think that checking for a date time to not be None is also better served by actually checking for what you mean. The difference is in intent and likelihood of confusion. For all of those you?re going to be explicitly testing and working with midnight objects, so you?re going to test them, you?re going to exercise that code. In the ``is None`` case, Midnight is just another value so that bug will lay dormant and undetected until someone just happens to hit an unlucky time. And once you get that it?s likely to be difficult to reproduce. Further more this only ever works reliably on naive times and doesn?t realistically work ?sanely? (if you consider this behavior sane) on aware times at all. So to be specific, I think using ``if time_or_something_that_may_be_none:`` is always wrong, but I think the like hood for user confusion and hard to reproduce bugs are far greater when a more or less arbitrary time (especially in the sense of aware times) evaluates as false when a user omits the ``is None`` than when someone expects ``if time:`` to be false at midnight. > > Now, those use cases may still not appear relevant to you, but then > the argument that "if x:" should not trigger for time(0,0,0) > because x might actually be None, is also not relevant to me, > since it masks a bug in the example code and those should never > go undetected :-) > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Mar 06 2014) >>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, >>>> mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From donald at stufft.io Thu Mar 6 09:50:46 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 03:50:46 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: <22932C54-DCDF-4CF3-B91B-DB69B4FDA13A@stufft.io> On Mar 6, 2014, at 3:46 AM, Donald Stufft wrote: > So to be specific, I think using ``if time_or_something_that_may_be_none:`` > is always wrong, but I think the like hood for user confusion and hard to > reproduce bugs are far greater when a more or less arbitrary time (especially > in the sense of aware times) evaluates as false when a user omits the > ``is None`` than when someone expects ``if time:`` to be false at midnight. I realized this was ambiguous, I always consider directly checking the boolean value of a time object as wrong, as I don?t believe time has any True/False implications in it. This includes both using ``if thing:`` to detect None and using ``if thing:`` to detect midnight. I just think the ``if thing:`` to detect None case is more common and also more difficult to detect when you have a bug because of it and more surprising behavior than the other case. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From flying-sheep at web.de Thu Mar 6 10:22:08 2014 From: flying-sheep at web.de (Philipp A.) Date: Thu, 6 Mar 2014 10:22:08 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <22932C54-DCDF-4CF3-B91B-DB69B4FDA13A@stufft.io> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <22932C54-DCDF-4CF3-B91B-DB69B4FDA13A@stufft.io> Message-ID: 2014-03-06 6:34 GMT+01:00 Greg Ewing : > The point of having time objects as an abstraction is > so that you *don't* have to think of them as an offset > from anything. You simply think of them as times. but times *are* offsets from midnight (24h clock) or midnight and noon (12h clock) 1 o?clock = 1 hour after midnight 12 o?clock pm = 12 hours after noon they are essentially radial coordinates ? and radial coordinates do have a 0 point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Thu Mar 6 10:32:06 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 10:32:06 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: <53184096.3050409@egenix.com> On 06.03.2014 09:46, Donald Stufft wrote: > > On Mar 6, 2014, at 3:35 AM, M.-A. Lemburg wrote: > >> On 06.03.2014 03:23, Donald Stufft wrote: >>> >>> On Mar 5, 2014, at 9:15 PM, Tim Peters wrote: >>> >>>> [Donald Stufft] >>>>> When the documented behavior is both nonsensical and the cause of hard to debug bugs that >>>>> is a pretty compelling use case to me, unless you actively enjoy being user hostile. >>>> >>>> Breaking code that currently works is as hostile as hostile gets. Where is the evidence that >>>> no code relies on the current behavior? For that matter, where is the evidence that the >>>> current behavior is a significant cause of bugs? I know I've used "if some_time_object:", >>>> but it did exactly what I expected it to do. >>> >>> Forgive me if I?m wrong, but aren?t you the author of the date time module? If that?s the case >>> what you expect it to do isn?t particularly relevant as you?re intimately aware of it?s >>> implementation. >> >> Just in case you're looking for a relevant use case: >> >> Having bool(time(0,0,0)) allows you to quickly check whether you are >> dealing with a datetime value with (non-trivial) time part or not. > > I don?t see how midnight is any more or less trivial than 12:01. > >> >> You run into situations where you have to test for this in >> date/time conversions, arithmetics, etc. e.g. if you need to convert >> a datetime value to a date and want to prevent truncation of >> information, or if you want to format a datetime value in a user >> friendly way by omitting the zero time part, or if you're doing >> datetime arithmetic that has to follow special requirements w/r to >> days (think interest or insurance math) and you want to >> quickly check whether you can use the fast path simple >> calculation, or you need to do the full blown complicated part. > > I think these would be better served by actually checking for what you mean. > For the record I also think that checking for a date time to not be None > is also better served by actually checking for what you mean. The > difference is in intent and likelihood of confusion. FWIW, I expect bool(time(0,0,0)) == False, just like I expect bool(0.0) == False. I would find it confusing to have bool(zero_element) == True. > For all of those you?re going to be explicitly testing and working with > midnight objects, so you?re going to test them, you?re going to exercise > that code. In the ``is None`` case, Midnight is just another value so that > bug will lay dormant and undetected until someone just happens to > hit an unlucky time. And once you get that it?s likely to be difficult to > reproduce. datetime values with zero time are *very* common in practice (you run into them whenever you convert a date value into a datetime value), so the "is None" case is easy to reproduce and will hit you more often than you like. BTW: Not using "is None" will bite you in many other ways as well. None it typically used as value for "not initialized" or "no value provided". This meaning is completely different from "empty selection" or "empty string", so in order to address all those cases as well, you'd have to change: bool(()) == True bool('') == True etc. The "if x is None:" test is also faster than "if x:", so actually win something by coding correctly ;-) Please provide a stronger argument for needing to change bool(time(0,0,0)) than one which is built on buggy code :-) (I'm running out of smileys...) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From fuzzyman at gmail.com Thu Mar 6 10:34:32 2014 From: fuzzyman at gmail.com (Michael Foord) Date: Thu, 6 Mar 2014 09:34:32 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53184096.3050409@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184096.3050409@egenix.com> Message-ID: On 6 March 2014 09:32, M.-A. Lemburg wrote: > On 06.03.2014 09:46, Donald Stufft wrote: > > > > On Mar 6, 2014, at 3:35 AM, M.-A. Lemburg wrote: > > > >> On 06.03.2014 03:23, Donald Stufft wrote: > >>> > >>> On Mar 5, 2014, at 9:15 PM, Tim Peters wrote: > >>> > >>>> [Donald Stufft] > >>>>> When the documented behavior is both nonsensical and the cause of > hard to debug bugs that > >>>>> is a pretty compelling use case to me, unless you actively enjoy > being user hostile. > >>>> > >>>> Breaking code that currently works is as hostile as hostile gets. > Where is the evidence that > >>>> no code relies on the current behavior? For that matter, where is the > evidence that the > >>>> current behavior is a significant cause of bugs? I know I've used > "if some_time_object:", > >>>> but it did exactly what I expected it to do. > >>> > >>> Forgive me if I'm wrong, but aren't you the author of the date time > module? If that's the case > >>> what you expect it to do isn't particularly relevant as you're > intimately aware of it's > >>> implementation. > >> > >> Just in case you're looking for a relevant use case: > >> > >> Having bool(time(0,0,0)) allows you to quickly check whether you are > >> dealing with a datetime value with (non-trivial) time part or not. > > > > I don't see how midnight is any more or less trivial than 12:01. > > > >> > >> You run into situations where you have to test for this in > >> date/time conversions, arithmetics, etc. e.g. if you need to convert > >> a datetime value to a date and want to prevent truncation of > >> information, or if you want to format a datetime value in a user > >> friendly way by omitting the zero time part, or if you're doing > >> datetime arithmetic that has to follow special requirements w/r to > >> days (think interest or insurance math) and you want to > >> quickly check whether you can use the fast path simple > >> calculation, or you need to do the full blown complicated part. > > > > I think these would be better served by actually checking for what you > mean. > > For the record I also think that checking for a date time to not be None > > is also better served by actually checking for what you mean. The > > difference is in intent and likelihood of confusion. > > FWIW, I expect bool(time(0,0,0)) == False, just like I expect > bool(0.0) == False. I would find it confusing to have > bool(zero_element) == True. > > > For all of those you're going to be explicitly testing and working with > > midnight objects, so you're going to test them, you're going to exercise > > that code. In the ``is None`` case, Midnight is just another value so > that > > bug will lay dormant and undetected until someone just happens to > > hit an unlucky time. And once you get that it's likely to be difficult to > > reproduce. > > datetime values with zero time are *very* common in practice > (you run into them whenever you convert a date value into a datetime > value), so the "is None" case is easy to reproduce and will hit > you more often than you like. > > BTW: Not using "is None" will bite you in many other ways as > well. None it typically used as value for "not initialized" or > "no value provided". This meaning is completely different from > "empty selection" or "empty string", so in order to address all > those cases as well, you'd have to change: > > bool(()) == True > bool('') == True > etc. > > The "if x is None:" test is also faster than "if x:", so actually > win something by coding correctly ;-) > > Please provide a stronger argument for needing to change > bool(time(0,0,0)) than one which is built on buggy code :-) > (I'm running out of smileys...) > > I'm very surprised that "midnight evaluates to False is insane" is not in and of itself a strong enough argument to change it. :-/ Michael > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Mar 06 2014) > >>> Python Projects, Consulting and Support ... http://www.egenix.com/ > >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Thu Mar 6 10:34:55 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 10:34:55 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> Message-ID: Le 06/03/2014 03:15, Tim Peters a ?crit : > [Donald Stufft] >> When the documented behavior is both nonsensical and the cause of hard >> to debug bugs that is a pretty compelling use case to me, unless you actively >> enjoy being user hostile. > > Breaking code that currently works is as hostile as hostile gets. > Where is the evidence that no code relies on the current behavior? > For that matter, where is the evidence that the current behavior is a > significant cause of bugs? I know I've used "if some_time_object:", > but it did exactly what I expected it to do. The current behaviour being highly unintuitive is a likely source of bugs, IMO. Regards Antoine. From solipsis at pitrou.net Thu Mar 6 10:52:12 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 10:52:12 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5318336F.7030009@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: Le 06/03/2014 09:35, M.-A. Lemburg a ?crit : > Just in case you're looking for a relevant use case: > > Having bool(time(0,0,0)) allows you to quickly check whether you are > dealing with a datetime value with (non-trivial) time part or not. This sounds like the kind of shortcut that only an expert would know to take, not something that's actually a good design decision. It's as though pathlib.Path('') evaluated to false for some obscure use case that I cared about. It is not a coincidence, IMO, that the three persons arguing that the current behaviour is reasonable are implementors of datetime modules: you, Tim and Alexander. All other people find the behaviour baffling. Regards Antoine. From ncoghlan at gmail.com Thu Mar 6 11:11:21 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 6 Mar 2014 20:11:21 +1000 Subject: [Python-ideas] Add "goto fail" to Python? In-Reply-To: References: Message-ID: On 6 Mar 2014 13:55, "Sturla Molden" wrote: > > "goto fail" is a well-known error handling mechanism in open source software, widely reputed for its robusteness: > > http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c > > https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150ccbdf0aec1878a41c17c41d358a3b:lib/x509/verify.c > > I believe Python needs to add support for this superior paradigm. Unfortunately, we can't throw stones about those, since we currently have hostname matching off by default and expect developers to turn it on. That needs to change, but there are a few thorny practical issues to sort out in order to get there (Christian Heimes has been working through several of them). Cheers, Nick. > > It would involve a new keyword "fail" and some means of goto'ing to it. I suggest "raise to fail": > > if (some_error): > raise to fail > > fail: > > > Unless there are many objections, this fantastic idea might be submitted in a (short) PEP somewhere around the beginning of next month. > > There is some obvious overlap with the rejected "goto PEP" (PEP 3163) and the Python 2.3 goto module. However, the superiority of goto fail as error generation and error handling paradigm has since then been thoroughly proven. > > http://legacy.python.org/dev/peps/pep-3136/ > http://entrian.com/goto/download.html > > > Regards, > Sturla Molden > > > > > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Thu Mar 6 11:13:08 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 11:13:08 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: Le 06/03/2014 07:47, Alexander Belopolsky a ?crit : > I don't understand why people are denying that midnights are special > points. Because they are not? Really, this is getting ridiculous. In any intuitive and common notion of time, midnight is not a special point at all. There is a reason most people on this thread disagree with you. (and, no, it's not because they are being dense or ignorant) Regards Antoine. From solipsis at pitrou.net Thu Mar 6 11:19:46 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 11:19:46 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> Message-ID: Le 05/03/2014 22:10, Alex Gaynor a ?crit : > First, I'd like to dispense with the notion that ``if foo`` is somehow a bad > practice. This is an EXTREMELY common practice as a shorthand for checking for > None, a great many people consider it more idiomatic, this really isn't a place > to bikeshed that particlar idiom. Agreed. If we didn't want people to rely on that idiom then __bool__ would have to raise TypeError on most types except a select ones. Regards Antoine. From solipsis at pitrou.net Thu Mar 6 11:27:22 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 11:27:22 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306021457.GF28804@ando> References: <201403051216.12392.shai@platonix.com> <20140306021457.GF28804@ando> Message-ID: Le 06/03/2014 03:14, Steven D'Aprano a ?crit : > > For what it's worth, I think the current behaviour is a misfeature, and > in a perfect world it would be fixed. But the cost of this is so > miniscule, and the work-around so trivial, that although the fix is > cheap, the benefit is even lower. Again, the problem is not the cost of the workaround, but the cost of sporadic unexpected failures when you don't *know* your code is vulnerable to this issue. Regards Antoine. From mal at egenix.com Thu Mar 6 11:33:08 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 11:33:08 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: <53184EE4.80105@egenix.com> On 06.03.2014 10:52, Antoine Pitrou wrote: > Le 06/03/2014 09:35, M.-A. Lemburg a ?crit : >> Just in case you're looking for a relevant use case: >> >> Having bool(time(0,0,0)) allows you to quickly check whether you are >> dealing with a datetime value with (non-trivial) time part or not. > > This sounds like the kind of shortcut that only an expert would know to take, not something that's > actually a good design decision. > It's as though pathlib.Path('') evaluated to false for some obscure use case that I cared about. It doesn't ? :-) > It is not a coincidence, IMO, that the three persons arguing that the current behaviour is > reasonable are implementors of datetime modules: you, Tim and Alexander. All other people find the > behaviour baffling. I'm not so sure. Of course, people who have been doing date/time stuff will jump into discussions that deal with them, but the same argument triggering this thread could have applied to other Python types and you would then have a different group of people argue for plausibility of the choice. I find it strange that the only argument against having time(0,0,0) evaluate to False in a boolean context is a wrongly used None test. This argument can be applied to lots of other types as well, where the buggy None test masks errors. Perhaps someone could present at least one compelling argument that is not based on wrong usage of None in if statements. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From solipsis at pitrou.net Thu Mar 6 11:39:20 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 11:39:20 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <5317AE64.90007@egenix.com> <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> Message-ID: Le 06/03/2014 00:22, Alexander Belopolsky a ?crit : > > No. It is False because it equals False: > > >>> 0 == False > True I think this is a misunderstanding on your part. Python considered 0 as false-y before the bool type was introduced in the language. Actually, 0 was *the* spelling of "false" before "False" was introduced. > I think proponents of bool(time(0)) == True view it as a container of > hours, minutes and seconds. No, they view it as an abstraction around the common concept of time. Regards Antoine. From solipsis at pitrou.net Thu Mar 6 11:43:12 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 11:43:12 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306021948.GG28804@ando> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <20140306021948.GG28804@ando> Message-ID: Le 06/03/2014 03:19, Steven D'Aprano a ?crit : > > It may only be a convention that an instant before midnight is the end > of the day and midnight the beginning of the next, but it is a > convention: midnight is the origin (i.e. zero point) of the day. That > makes it arguably as falsey as 0, 0.0 and 0j. A zero in algebra has a special meaning with respect to an operator (e.g. addition). Midnight doesn't have such a special meaning. Regards Antoine. From solipsis at pitrou.net Thu Mar 6 11:46:13 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 11:46:13 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53184EE4.80105@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> Message-ID: Le 06/03/2014 11:33, M.-A. Lemburg a ?crit : > > I find it strange that the only argument against having time(0,0,0) > evaluate to False in a boolean context is a wrongly used > None test. It's only "wrongly used" because of that particular wart. In other words, the "wrongly used" None test *exposes* the wart, it is not its *cause*. There are other contexts with implicit boolean conversion, such as any() and all(). Regards Antoine. From steve at pearwood.info Thu Mar 6 11:52:53 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 21:52:53 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5317FC67.7060600@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <5317FC67.7060600@canterbury.ac.nz> Message-ID: <20140306105253.GI28804@ando> On Thu, Mar 06, 2014 at 05:41:11PM +1300, Greg Ewing wrote: > Steven D'Aprano wrote: > >There's also the argument from consistency: midnight is the zero point > >of the day, and zero is falsey. > > Regarding midnight as a "zero point" is an arbitrary > convention. True, as I mentioned in another post. Nevertheless, we have many arbitrary conventions enshrined in Python. Using base 10 for the representation of numbers, instead of, say, balanced ternary notation, is an arbitrary convention. Numbering sequences from 0 is another. If you would prefer another convention for the zero point of the day (say, midday, dusk, dawn, or 2:15pm) then feel free to subclass datetime.time :-) Or even no zero point at all. Tossing out a wild idea, why not leave datetime.time alone and add a new class which is exactly the same but is always truthy? That doesn't break backward compatibility, and so it could happen immediately (too late for 3.4, but certainly for 3.5). All we need is an appropriate name, and a decision as to which ought to inherit from which. The bike-shedding should be over by 3.5 alpha 1 *wink* Despite my quip about the bike-shedding, I am actually serious. -- Steven From masklinn at masklinn.net Thu Mar 6 11:53:59 2014 From: masklinn at masklinn.net (Masklinn) Date: Thu, 6 Mar 2014 11:53:59 +0100 Subject: [Python-ideas] One more time... lambda function <--- from *** signature def. In-Reply-To: <87y50npyy7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140301034611.GD28804@ando> <84C450A1-D2C8-4103-9933-F98747CDEFA0@yahoo.com> <20140304110921.GP28804@ando> <5316544D.7050302@canterbury.ac.nz> <05894993-3C4D-42E7-9328-C3365DF92CBE@masklinn.net> <53179C51.4020001@canterbury.ac.nz> <29275C71-F3DC-4D4A-A251-B56AED14E6C1@masklinn.net> <87y50npyy7.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4E54B6BB-2AA6-4D57-96BC-3C7D4C807030@masklinn.net> On 2014-03-06, at 08:29 , Stephen J. Turnbull wrote: > Masklinn writes: >> On 2014-03-05, at 22:51 , Greg Ewing wrote: >>> Masklinn wrote: >>>> On 2014-03-04, at 23:31 , Greg Ewing wrote: > >>> That comes at the expense of making *everything* a thunk >>> until its value is needed [in Haskell]. >> >> Of course not, Haskell allows explicitly forcing a thunk and the >> compiler/runtime pair can use strictness analysis and not create thunks >> in the first place. > > That doesn't seem fair to me. "Explicitly forcing" by definition > means the programmer has decided the value is needed No, it means the programmer wants the value to be strictly evaluated (this is generally a space optimisation). It has no impact on program behavior (assuming infinite resources, one issue of accumulating thunks is the risk of OOM if they remain live but unevaluated). > and "strictness > analysis" is an optimization, not part of the language definition. Am > I missing something? No? It just demonstrates that not everything is a thunk in haskell, there are both thunks and strict values living around in the runtime, and that's not visible in the type system. >> Consider that a thunk is a deferral of an expression's evaluation, >> why would said expression's evaluation happen more than once? The >> only thing which changes is *when* the actual evaluation happens. > > Are thunks guaranteed not to leak out of the scope of the > containing expression, so assignment is impossible? I'm not sure I understand the question. > If they can leak, the thunk would be an object I think that's just one possible implementation, a thunk could also be some sort of reference indirection, a tagged pointer, or a deeply integrated proxy-ish object. > and in Python > "assigning" it to a "variable" actually just creates a reference. > Evaluation could memoize the thunk's value ("evaluation only happens > once") or reevaluate the thunk each time its value is requested. > Either seems potentially surprising to me. Absolutely. > Memoization makes sense if you think of the thunk as the closure of a > computation that conceptually takes place at definition time. I'm not > sure if in the use cases for thunks it really makes sense to "close" > the thunk at evaluation time, but it seems like a plausible > interpretation to me. I find it the most *useful* definition: for the other one we already have functions and I'm not sure thunks would have much use as shorter arguments-less functions. It also has the property that "client" code (code receiving thunks without necessarily being aware of it) remains valid and unsurprising in that a = foo b = foo assert a is b remains true regardless of `foo` being a thunk (the only difference being that if `foo` is a thunk it may remain unforced throughout). From p.f.moore at gmail.com Thu Mar 6 11:57:22 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 6 Mar 2014 10:57:22 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53184EE4.80105@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> Message-ID: On 6 March 2014 10:33, M.-A. Lemburg wrote: >> It is not a coincidence, IMO, that the three persons arguing that the current behaviour is >> reasonable are implementors of datetime modules: you, Tim and Alexander. All other people find the >> behaviour baffling. > > I'm not so sure. Of course, people who have been doing date/time > stuff will jump into discussions that deal with them, but the same > argument triggering this thread could have applied to other Python > types and you would then have a different group of people argue > for plausibility of the choice. I had promised to stay out of this discussion as I no longer thing it adds much value (note that the bug has been reopened long since) and I was getting tired of having people decide that I'd said something I didn't mean. But just to add a perspective from someone who *doesn't* develop a datetime module, I encounter "special" midnight values very often. Databases (at least Oracle, and I believe others) typically store date values ("Thursday 6th March 2014") as a timestamp value with midnight as a time part. So checking the time part of a datetime value for midnight as a "special, means omitted" value is not uncommon in that domain. Paul From stephen at xemacs.org Thu Mar 6 11:57:27 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 06 Mar 2014 19:57:27 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403052118.38295.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403052033.44162.shai@platonix.com> <201403052118.38295.shai@platonix.com> Message-ID: <87vbvrppbc.fsf@uwakimon.sk.tsukuba.ac.jp> Shai Berger writes: > Unless you're aware of the issue, you are not going to unit-test > specifically for midnight. If you are aware, you don't need to > detect it, you write "is not None". The issue, as Skip has argued at length, is that by using the implicit cast to Boolean you've changed the nature of the test from "membership in valid values" to "a true-ish value".[1] This can be detected generically with grep, something like: grep -E '^ *if [^<>=]*:' | grep -v '^ *if.* is .*:' with a (possibly large) number of false positives. (I suspect it's not worth worrying about no false negatives; if the 'is' operator is present, the test is boolean except if it's part of an arithmetic expression such as "3 + (2 is not None)".) You might want to include modulo (%) in the list of operators. Or it might be more accurate to check for bare variables only and assume any expression should OK. The false positives can be drastically reduced by checking for a Boolean or container initializer in the case of "if var:". None of pep8, pylint, or pychecker does this now AFAICT, but they could, I think. Footnotes: [1] Implementing a membership test as a test for a sentinel is a bit fishy in this context of arguing about the "nature of the test", but given the much less obvious nature of the conversion to bool in complex types like dates and times, I'll go with Skip any time. From mal at egenix.com Thu Mar 6 12:04:56 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 12:04:56 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> Message-ID: <53185658.5080507@egenix.com> On 06.03.2014 11:46, Antoine Pitrou wrote: > Le 06/03/2014 11:33, M.-A. Lemburg a ?crit : >> >> I find it strange that the only argument against having time(0,0,0) >> evaluate to False in a boolean context is a wrongly used >> None test. > > It's only "wrongly used" because of that particular wart. > In other words, the "wrongly used" None test *exposes* the wart, it is not its *cause*. Wait. Let's be clear on this: Writing if x: print ('x is None') or if x == None: print ('x is None') is wrong code. None is a singleton, so you have to use the "is" operator, i.e. if x is None: print ('x is None') is the only correct way of testing for None. Adding a test to pylint for this would probably be more helpful and address the real problem in a more productive way, than the current discussion to making the above problematic code work in the single use case of x being a datetime.time object. > There are other contexts with implicit boolean conversion, such as any() and all(). If you expect those to work correctly for None testing, then you're writing wrong code as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From solipsis at pitrou.net Thu Mar 6 12:09:12 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 12:09:12 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53185658.5080507@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> Message-ID: Le 06/03/2014 12:04, M.-A. Lemburg a ?crit : > > Writing > > if x: print ('x is None') > > or > > if x == None: print ('x is None') > > is wrong code. No it isn't. > None is a singleton, so you have to use the "is" operator, i.e. > > if x is None: print ('x is None') > > is the only correct way of testing for None. No it isn't. x == None is a perfectly well-defined way of doing it, even if it isn't the stylistically preferred one. Regards Antoine. From stefan at bytereef.org Thu Mar 6 12:13:36 2014 From: stefan at bytereef.org (Stefan Krah) Date: Thu, 6 Mar 2014 11:13:36 +0000 (UTC) Subject: [Python-ideas] =?utf-8?q?Please_reconsider_the_Boolean_evaluation?= =?utf-8?q?_of=09midnight?= References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: Antoine Pitrou writes: > Le 06/03/2014 09:35, M.-A. Lemburg a ?crit : > > Just in case you're looking for a relevant use case: > > > > Having bool(time(0,0,0)) allows you to quickly check whether you are > > dealing with a datetime value with (non-trivial) time part or not. > > This sounds like the kind of shortcut that only an expert would know to > take, not something that's actually a good design decision. > It's as though pathlib.Path('') evaluated to false for some obscure use > case that I cared about. On the other hand I would not dare to assume it's True without checking. > It is not a coincidence, IMO, that the three persons arguing that the > current behaviour is reasonable are implementors of datetime modules: > you, Tim and Alexander. All other people find the behaviour baffling. Not all. :) I think viewing midnight as (unix_time % 86400) is quite reasonable. Stefan Krah From mal at egenix.com Thu Mar 6 12:15:47 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 12:15:47 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53185658.5080507@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> Message-ID: <531858E3.3030805@egenix.com> On 06.03.2014 12:04, M.-A. Lemburg wrote: > On 06.03.2014 11:46, Antoine Pitrou wrote: >> Le 06/03/2014 11:33, M.-A. Lemburg a ?crit : >>> >>> I find it strange that the only argument against having time(0,0,0) >>> evaluate to False in a boolean context is a wrongly used >>> None test. >> >> It's only "wrongly used" because of that particular wart. >> In other words, the "wrongly used" None test *exposes* the wart, it is not its *cause*. > > Wait. Let's be clear on this: > > Writing > > if x: print ('x is None') The above is obviously wrong :-). Let's try again: if not x: print ('x is None') > or > > if x == None: print ('x is None') > > is wrong code. > > None is a singleton, so you have to use the "is" operator, i.e. > > if x is None: print ('x is None') > > is the only correct way of testing for None. > > Adding a test to pylint for this would probably be more helpful > and address the real problem in a more productive way, than the > current discussion to making the above problematic code work in > the single use case of x being a datetime.time object. > >> There are other contexts with implicit boolean conversion, such as any() and all(). > > If you expect those to work correctly for None testing, then > you're writing wrong code as well. > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Thu Mar 6 12:22:47 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 12:22:47 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> Message-ID: <53185A87.5010109@egenix.com> On 06.03.2014 12:09, Antoine Pitrou wrote: > Le 06/03/2014 12:04, M.-A. Lemburg a ?crit : >> >> Writing >> >> if x: print ('x is None') >> >> or >> >> if x == None: print ('x is None') >> >> is wrong code. > > No it isn't. > >> None is a singleton, so you have to use the "is" operator, i.e. >> >> if x is None: print ('x is None') >> >> is the only correct way of testing for None. > > No it isn't. x == None is a perfectly well-defined way of doing it, even if it isn't the > stylistically preferred one. Depends on what kind of type x is and how that type implements the comparison slots. It is perfectly well possible to define a type that returns True for (x == None), even though x is not None :-) >>> class C: ... def __eq__(self, other): ... return (other is None) ... >>> o = C() >>> o == None True -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From rob.cliffe at btinternet.com Thu Mar 6 12:36:40 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Thu, 06 Mar 2014 11:36:40 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> Message-ID: <53185DC8.3000707@btinternet.com> On 06/03/2014 10:57, Paul Moore wrote: > > I had promised to stay out of this discussion as I no longer thing it > adds much value (note that the bug has been reopened long since) and I > was getting tired of having people decide that I'd said something I > didn't mean. > > But just to add a perspective from someone who *doesn't* develop a > datetime module, I encounter "special" midnight values very often. > Databases (at least Oracle, and I believe others) typically store date > values ("Thursday 6th March 2014") as a timestamp value with midnight > as a time part. So checking the time part of a datetime value for > midnight as a "special, means omitted" value is not uncommon in that > domain. > > Paul You're joking, right? How do you distinguish "omitted" from "provided, equals midnight" ? Rob Cliffe > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2247 / Virus Database: 3705/6655 - Release Date: 03/05/14 > > From rob.cliffe at btinternet.com Thu Mar 6 12:40:21 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Thu, 06 Mar 2014 11:40:21 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306105253.GI28804@ando> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <5317FC67.7060600@canterbury.ac.nz> <20140306105253.GI28804@ando> Message-ID: <53185EA5.3060802@btinternet.com> On 06/03/2014 10:52, Steven D'Aprano wrote: > > True, as I mentioned in another post. > > Nevertheless, we have many arbitrary conventions enshrined in Python. > Using base 10 for the representation of numbers, instead of, say, > balanced ternary notation, is an arbitrary convention. Numbering > sequences from 0 is another. > > If you would prefer another convention for the zero point of the day > (say, midday, dusk, dawn, or 2:15pm) then feel free to subclass > datetime.time :-) > > Or even no zero point at all. Tossing out a wild idea, why not leave > datetime.time alone and add a new class which is exactly the same but is > always truthy? That doesn't break backward compatibility, and so it > could happen immediately (too late for 3.4, but certainly for 3.5). > > All we need is an appropriate name, and a decision as to which ought to > inherit from which. The bike-shedding should be over by 3.5 alpha 1 > *wink* > > Despite my quip about the bike-shedding, I am actually serious. You're joking, right? Suppose you were considering taking up a new language and you found something in the docs which said: "Here's a class that does so-and-so. And here's another slightly different one that you can use instead, because we didn't get the first one quite right." Would that be a turn-on? Rob Cliffe > > From stephen at xemacs.org Thu Mar 6 12:51:29 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 06 Mar 2014 20:51:29 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <201403051924.05252.shai@platonix.com> References: <201403051216.12392.shai@platonix.com> <201403051715.29773.shai@platonix.com> <201403051924.05252.shai@platonix.com> Message-ID: <87txbbpmta.fsf@uwakimon.sk.tsukuba.ac.jp> Shai Berger writes: > At issue here is the fact that the idiom doesn't fit where one > would expect that it should. This is the real problem. People are programming in un-Pythonic style by analogy to either other languages or to other cases in Python where the __len__ method provides a natural cast to Boolean, and deciding since they like the idiom, the behavior of time.time is "unexpected." But your claim is *not* a "fact". Quite the reverse, I was mildly surprised even the last time around that anybody would argue that it's a good idea to use a sentinel to indicate "uninitialized" and then fail to test explicitly for the sentinel. For example, I wouldn't be surprised to see something like this in an MTA or other program that should not let data out of its sight without a timestamp: my_time = None if not my_time and x: my_time = x.supposed_to_be_time_but_in_fact_sometimes_0 if not my_time: my_time = time.now() What are the odds that you'll detect the bug in initializing 'x' in a timely fashion? OTOH, if you test for "is None" you'll probably get a quick TypeError the first time the bug manifests. (No guarantees, of course, but why trade a potentially easy bug for a probably hard one?) If you asked me to implement a Time class, would I have any false instances? Quite possibly, yes. Of course I might implement it as a namedtuple (h, m, s), in which case it would always be true. OTOH, I might implement it as seconds-since-midnight, and probably not bother to give it a __bool__ method to ensure bool(midnight) == True. So I don't really care *why* Uncle Timmy chose to make midnight be false, I only offer kudos for documenting it. :-) From p.f.moore at gmail.com Thu Mar 6 12:54:34 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 6 Mar 2014 11:54:34 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53185DC8.3000707@btinternet.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185DC8.3000707@btinternet.com> Message-ID: On 6 March 2014 11:36, Rob Cliffe wrote: > You're joking, right? No. You just sent 2 "you're joking" messages. You're joking, right? Any time anyone presents a use case or proposal that contradicts what you want it must be a joke? I really am sick of being misinterprested and misrepresented on this thread. > How do you distinguish "omitted" from "provided, equals midnight" ? I will not explain all the details of how database applications process dates here. All I offered was a perspective that some application domains, in certain cases, see "midnight" as having a special meaning distinct from the specific point in time. I did so because other people's views were being characterised as irrelevant because they developed datetime modules (as if that made them somehow *less* qualified to have an opinion) and I sympathised with them over the hostile reception they were getting. I didn't comment on whether that meant the Python behaviour was good or bad, or whether the practice of truth-testing time values was good or not. Feel free to investigate the details if you care, or ignore my post if you don't. But I'm not trolling, nor do I appreciate the implication that I am. Paul. From rob.cliffe at btinternet.com Thu Mar 6 12:56:31 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Thu, 06 Mar 2014 11:56:31 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> Message-ID: <5318626F.5080203@btinternet.com> On 06/03/2014 02:15, Tim Peters wrote: > [Donald Stufft] >> When the documented behavior is both nonsensical and the cause of hard >> to debug bugs that is a pretty compelling use case to me, unless you actively >> enjoy being user hostile. > Breaking code that currently works is as hostile as hostile gets. > Where is the evidence that no code relies on the current behavior? > For that matter, where is the evidence that the current behavior is a > significant cause of bugs? I know I've used "if some_time_object:", > but it did exactly what I expected it to do. Well, let's start a survey. So far we have: Instances of existing code that would be broken by the change: 0 Instances of code where the unexpected behaviour caused a bug: 1 (the OP's code). I invite everyone to add instances that they know about.:-) Rob Cliffe > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2247 / Virus Database: 3705/6655 - Release Date: 03/05/14 > > From ncoghlan at gmail.com Thu Mar 6 13:08:54 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 6 Mar 2014 22:08:54 +1000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53185658.5080507@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> Message-ID: On 6 March 2014 21:04, M.-A. Lemburg wrote: > Wait. Let's be clear on this: > > Writing > > if x: print ('x is None') > > or > > if x == None: print ('x is None') The case in question is essentially this one: if x: assert x is not None # Always valid! .... else: assert x is None # Valid for most user defined types There is a learned intuition that people naturally acquire when learning Python: - numbers may be false (it means zero) - containers may be false (it means empty) - everything else is always true (as that's the default for user defined classes) Where datetime().time() is confusing is the fact the expected behaviour changes based on *which* category you put the number in. The vast majority of Python's users will place structured date and time objects in the "arbitrary object" category, and expect them to always be true. When using None as a sentinel for such types, writing "if x:" when you really mean "if x is not None:" is a harmless style error, with no practical ill-effects. When dealing with time objects, such users are unlikely to be crafting test cases to ensure that "midnight UTC" is handled correctly, so their "harmless style error" is in fact a subtle data driven bug waiting to bite them. It is *really* hard for a static analyser to pick this up, because at point of use "if x:" gives no information about the type of "x", and hence any such alert would have an unacceptably high false positive rate. Now, let's consider the time with the *best* possible claim to being false: timestamp zero. How does that behave? Python 3.3: >>> bool(dt.datetime.fromtimestamp(0)) True >>> bool(dt.datetime.fromtimestamp(0).date()) True >>> bool(dt.datetime.fromtimestamp(0).time()) True Huh, if times are supposed to be valid as truth values, that looks rather weird. What's going on? >>> dt.datetime.fromtimestamp(0).time() datetime.time(10, 0) Oh, I'm in Brisbane - *of course* the truthiness of timestamps should depend on my timezone! Clearly, what I really meant was timestamp -36000, or perhaps 50400: >>> bool(dt.datetime.fromtimestamp(-36000).time()) False >>> bool(dt.datetime.fromtimestamp(50400).time()) False So, unless I happen to live in UTC, it's highly unlikely that I'm going to infer from Python's *behaviour* that datetime.time() (unlike datetime.date() and datetime.datetime()) belong in the "number" category, rather than the "arbitrary object" category. Perhaps it behaves like a number in other ways: >>> utcmidnight = dt.datetime.fromtimestamp(50400).time() >>> utcmidnight + 1 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'datetime.time' and 'int' >>> utcmidnight * 1 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for *: 'datetime.time' and 'int' >>> int(utcmidnight) Traceback (most recent call last): File "", line 1, in TypeError: int() argument must be a string or a number, not 'datetime.time' Hmm, nope. And that last one *explicitly* tells me it's not a number! There's a great saying in the usability world: "You can't document your way out of a usability problem". What it means is that if all the affordances of your application (or programming language!) push users towards a particular logical conclusion (in this case, "datetime.time values are not numbers"), having a caveat in your documentation isn't going to help, because people aren't even going to think to ask the question. It doesn't matter if you originally had a good reason for the behaviour, you've ended up in a place where your behaviour is confusing and inconsistent, because there is one piece of behaviour that is out of line with an otherwise consistent mental model. But perhaps I've been told "midnight is false in boolean context". But which midnight? There are three that apply to me: >>> naivemidnight datetime.time(0, 0) >>> utcmidnight datetime.time(0, 0, tzinfo=datetime.timezone.utc) >>> localmidnight datetime.time(0, 0, tzinfo=datetime.timezone(datetime.timedelta(0, 36000))) Are they all False? No, no they're not (unless your local timezone is UTC): >>> bool(utcmidnight) False >>> bool(naivemidnight) False >>> bool(localmidnight) True There's a phrase for APIs like this one: "expert friendly". Experts like a particular behaviour because it lets them do advanced things (like leave the door open for modular arithmetic on timestamp.time() values). However, that's not normally something we see as a virtue when designing APIs for Python - instead, we generally aim for layered complexity, where simple things are simple, and we provide power tools for advanced users that want them. Now, suppose this boolean behaviour went away. How would I detect if a value was midnight or not? Well, first, I would need to clarify my question. Do I mean midnight UTC? Or do I mean midnight local time? It makes a difference for aware objects, after all. Or perhaps I'm not interested in aware objects at all, and only care about naive midnight. Using appropriately named values like those I defined above, those questions are all very easy to express explicitly in ways that don't rely on readers understanding that "bool(x)" on a datetime.time object means the same thing as "x is naive midnight or UTC midnight": if x not in (naivemidnight, utcmidnight): # This is the current bool(x) .... if x != naivemidnight: # This has no current shorthand .... if x != utcmidnight: # This has no current shorthand .... if x != localmidnight: # This has no current shorthand .... And just to demonstrate that equivalence is accurate: >>> local_10am = localmidnight.replace(hour=10) >>> local_10am datetime.time(10, 0, tzinfo=datetime.timezone(datetime.timedelta(0, 36000))) >>> bool(local_10am) False >>> local_10am != utcmidnight False >>> local_10am not in (naivemidnight, utcmidnight) False While it was originally the desire to reduce the impact of a very common bug that prompted me to reopen the issue, it is the improved consistency in the behaviour presented to users of Python 3.6+ that makes me belief this is actually worth fixing. We embarked on the whole Python 3 exercise in the name of making the language easier to learn by removing legacy features and fixing some problematic defaults and design warts - this is a tiny tweak by comparison, and will still go through the full normal deprecation cycle (warning in 3.5, behavioural change in 3.6) Regards, Nick. From stephen at xemacs.org Thu Mar 6 13:18:26 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 06 Mar 2014 21:18:26 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051553.19311.shai@platonix.com> <201403051719.09276.shai@platonix.com> Message-ID: <87siqvplkd.fsf@uwakimon.sk.tsukuba.ac.jp> Ryan Hiebert writes: > he'd just like to see Python be better. We all agree that we'd like Python to be better. But many of us feel that the proposed change does not make Python better. It merely makes it more comfortable for what we (many of us, anyway) consider to be badly written code, and encourages people to write more code in poor style as we see it. > it seems that we are disagreeing on whether this strange behavior > should ever change. Well, yes, for Python 2 (obviously) and Python 3. I don't think anybody would object to changing it in Python 4. (Honestly, I would, on the principle above -- it really is only useful if you want to write code in bad style -- but it doesn't take a French soldier on the parapet to let you know in which general direction the wind blows.) > I think that, at some point, it should. If we ever agree on that, > then we can start thinking about when. I really don't think you'll achieve consensus before we start discussing Python 4 seriously. That's when the hunting season on backward incompatible changes (that don't correct showstoppers) opens. From steve at pearwood.info Thu Mar 6 13:35:20 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 6 Mar 2014 23:35:20 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53185EA5.3060802@btinternet.com> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <5317FC67.7060600@canterbury.ac.nz> <20140306105253.GI28804@ando> <53185EA5.3060802@btinternet.com> Message-ID: <20140306123520.GL28804@ando> On Thu, Mar 06, 2014 at 11:40:21AM +0000, Rob Cliffe wrote: > > On 06/03/2014 10:52, Steven D'Aprano wrote: > >Or even no zero point at all. Tossing out a wild idea, why not leave > >datetime.time alone and add a new class which is exactly the same but is > >always truthy? That doesn't break backward compatibility, and so it > >could happen immediately (too late for 3.4, but certainly for 3.5). > > > >All we need is an appropriate name, and a decision as to which ought to > >inherit from which. The bike-shedding should be over by 3.5 alpha 1 > >*wink* > > > >Despite my quip about the bike-shedding, I am actually serious. > You're joking, right? What part of "I am actually serious" suggests to you that I am joking? No, I am not joking. When you have a misdesigned API that cannot be fixed without breaking backwards compatibility, or at least cannot be fixed *quickly*, it may be sensible to leave the old API in place and place a new one side-by-side. If the old one is actively harmful, it can even be deprecated for eventual removal, otherwise it can remain indefinitely. Does the term "legacy API" sound familiar? This is *extremely common* in the software industry, at least in that part that isn't run by cowboy coders who have no concern about breaking their users' code. It's quite common in Python too: consider the legacy API of os.system, the deprecated API of the popen2 module, and the modern subprocess API. > Suppose you were considering taking up a new language and you found > something in the docs which said: > "Here's a class that does so-and-so. And here's another slightly > different one that you can use instead, because we didn't get the first > one quite right." > Would that be a turn-on? Yes. This would tell me that the developers of this language took backward compatibility seriously, and that they weren't afraid to admit to mistakes. -- Steven From stefan at bytereef.org Thu Mar 6 13:36:46 2014 From: stefan at bytereef.org (Stefan Krah) Date: Thu, 6 Mar 2014 12:36:46 +0000 (UTC) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: Mark H. Harris writes: > At this point in the discussion please try not to think "implementation," > rather think conceptually in an open framework where anything is possible. As I understand, you are suggesting some kind of number system with symbolic representations that can be converted to decimal if needed. The topic is so vast that the only chance of it happening is for someone to provide an implementation on PyPI and see if people like it. There are packages for symbolic mathematics like sympy, perhaps that is a start. Even if people like it, it would be nearly impossible to integrate it into the core language without breaking third-party packages on a very large scale. So it is unlikely that such a thing will make it into the (hypothetical) 4.0. Regarding decimal literals: Possible in 3.x, but it would require some investigation if people really want arbitrary precision arithmetic by default rather than e.g. IEEE Decimal64. Regarding decimal floats by default: Perhaps in 4.0, but IMO only with *full* backing by the large SciPy and NumPy communities. My guess is that it's not going to happen, not in the least because the literature for floating point algorithms (with proofs!) has an overwhelming focus on binary floating point. From donald at stufft.io Thu Mar 6 13:46:26 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 07:46:26 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306123520.GL28804@ando> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <5317FC67.7060600@canterbury.ac.nz> <20140306105253.GI28804@ando> <53185EA5.3060802@btinternet.com> <20140306123520.GL28804@ando> Message-ID: <3C649111-A44E-46D8-BCCB-76A5BFACFA41@stufft.io> On Mar 6, 2014, at 7:35 AM, Steven D'Aprano wrote: > On Thu, Mar 06, 2014 at 11:40:21AM +0000, Rob Cliffe wrote: >> >> On 06/03/2014 10:52, Steven D'Aprano wrote: > >>> Or even no zero point at all. Tossing out a wild idea, why not leave >>> datetime.time alone and add a new class which is exactly the same but is >>> always truthy? That doesn't break backward compatibility, and so it >>> could happen immediately (too late for 3.4, but certainly for 3.5). >>> >>> All we need is an appropriate name, and a decision as to which ought to >>> inherit from which. The bike-shedding should be over by 3.5 alpha 1 >>> *wink* >>> >>> Despite my quip about the bike-shedding, I am actually serious. > >> You're joking, right? > > What part of "I am actually serious" suggests to you that I am joking? > No, I am not joking. > > When you have a misdesigned API that cannot be fixed without breaking > backwards compatibility, or at least cannot be fixed *quickly*, it may > be sensible to leave the old API in place and place a new one > side-by-side. If the old one is actively harmful, it can even be > deprecated for eventual removal, otherwise it can remain indefinitely. > Does the term "legacy API" sound familiar? > > This is *extremely common* in the software industry, at least in that > part that isn't run by cowboy coders who have no concern about breaking > their users' code. It's quite common in Python too: consider the legacy > API of os.system, the deprecated API of the popen2 module, and the > modern subprocess API. > > >> Suppose you were considering taking up a new language and you found >> something in the docs which said: >> "Here's a class that does so-and-so. And here's another slightly >> different one that you can use instead, because we didn't get the first >> one quite right." >> Would that be a turn-on? > > Yes. This would tell me that the developers of this language took > backward compatibility seriously, and that they weren't afraid to admit > to mistakes. > > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ I think the decision to deprecate and change in place or create a new API depends greatly on how much code is going to break as a result of the deprecation, how hard it will be to restore the previous behavior, and how different the new API is. Language designers have to both consider backwards compatibility and the cognitive burden of having two (or more!) ways of doing the same thing. If you don't strike this balance and you never break backwards compatibility you very quickly end up with a massive number of new APIs. Remember that every bug fix is a potential backwards compatibility break for someone (https://xkcd.com/1172/ is relevant). In the case of datetime.time()?s boolean evaluation, I don?t believe a new API is warranted. I don?t believe (but I do not have proof) that there is going to be a lot of code out that that is depending on datetime.time evaluating to False in the cases it does (midnight in naive times, midnight utc when the utc offset is 0 or positive in aware times). I believe it is quite simple to replace the checks with a more explicit check when the user has been warned through the deprecation process. Finally I believe that the difference between the two APIs would be so slight as to increase the cognitive overhead for very little benefit. If we were talking about a major shift in how datetime.time() functions then maybe that would be warranted, however this is a small usability fix in an obscure corner of the API. It's not hardly, in my opinion, worth an entire new API revision. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From stephen at xemacs.org Thu Mar 6 13:46:55 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 06 Mar 2014 21:46:55 +0900 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140305135646.GB28804@ando> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: <87r46fpk8w.fsf@uwakimon.sk.tsukuba.ac.jp> Steven D'Aprano writes: > The problem is that fractions can be unbounded in memory, Seminumerical Algorithms has a few problems on "floating slash", ie a representation of numbers where the total memory allocated to a fraction is fixed, but the amounts allocated to numerator and denominator are variable. I don't know if it has ever been tried in practice, though. And of course any reasonable fixed size would have very limited ability to express very large or very small magnitudes. From oscar.j.benjamin at gmail.com Thu Mar 6 13:51:01 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Thu, 6 Mar 2014 12:51:01 +0000 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: On 6 March 2014 12:36, Stefan Krah wrote: > > Regarding decimal literals: > > Possible in 3.x, but it would require some investigation if > people really want arbitrary precision arithmetic by default > rather than e.g. IEEE Decimal64. Interesting. I wasn't aware of Decimal64. I don't understand your question/point though. The Decimal module doesn't provide "arbitrary" precision arithmetic by default. It provides 28 digit precision arithmetic by default. It does however allow the creation of Decimal instances with effectively arbitrary precision from strings, integers etc. So I would assume that the idea was that nothing would change about decimal arithmetic (by default or when importing the module). The difference would just be that you could write 1.12345e-23d which would be equivalent to Decimal('1.12345e-23'). In this way it would be possible with a literal to express any decimal value exactly (even if it exceeds the arithmetic precision). It would be possible to do e.g. "if x <= 0.00001d:" and know that the test was exact. > Regarding decimal floats by default: > > Perhaps in 4.0, but IMO only with *full* backing by the large SciPy > and NumPy communities. My guess is that it's not going to happen, not > in the least because the literature for floating point algorithms > (with proofs!) has an overwhelming focus on binary floating point. Yes, it's very hard to gauge the effect of something like this. Understanding where in a numeric code base 64-bit binary floating point is assumed would be harder than disentangling unicode, from bytes, from 8-bit encodings I expect. Oscar From stephen at xemacs.org Thu Mar 6 14:02:21 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 06 Mar 2014 22:02:21 +0900 Subject: [Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality In-Reply-To: <53180C92.7070904@canterbury.ac.nz> References: <5317B1D7.4090305@canterbury.ac.nz> <5317CF11.20100@mrabarnett.plus.com> <53180C92.7070904@canterbury.ac.nz> Message-ID: <87pplzpjj6.fsf@uwakimon.sk.tsukuba.ac.jp> Greg Ewing writes: > MRAB wrote: > > > In the UK we talk about "Bills" being put before Parliament. > > In NZ too, but once it's passed, it's the law -- > it's not up to individual interpretation! NZ is a common law country, is it not? From mal at egenix.com Thu Mar 6 14:21:52 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 06 Mar 2014 14:21:52 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> Message-ID: <53187670.6070302@egenix.com> On 06.03.2014 13:08, Nick Coghlan wrote: > But perhaps I've been told "midnight is false in boolean context". But > which midnight? There are three that apply to me: > >>>> naivemidnight > datetime.time(0, 0) >>>> utcmidnight > datetime.time(0, 0, tzinfo=datetime.timezone.utc) >>>> localmidnight > datetime.time(0, 0, tzinfo=datetime.timezone(datetime.timedelta(0, 36000))) > > Are they all False? No, no they're not (unless your local timezone is UTC): > >>>> bool(utcmidnight) > False >>>> bool(naivemidnight) > False >>>> bool(localmidnight) > True Now this is a what I consider a valid argument for making a change. Thanks, Nick. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 06 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From rob.cliffe at btinternet.com Thu Mar 6 14:47:05 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Thu, 06 Mar 2014 13:47:05 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306123520.GL28804@ando> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <5317FC67.7060600@canterbury.ac.nz> <20140306105253.GI28804@ando> <53185EA5.3060802@btinternet.com> <20140306123520.GL28804@ando> Message-ID: <53187C59.4080903@btinternet.com> On 06/03/2014 12:35, Steven D'Aprano wrote: > On Thu, Mar 06, 2014 at 11:40:21AM +0000, Rob Cliffe wrote: >> On 06/03/2014 10:52, Steven D'Aprano wrote: >>> Or even no zero point at all. Tossing out a wild idea, why not leave >>> datetime.time alone and add a new class which is exactly the same but is >>> always truthy? That doesn't break backward compatibility, and so it >>> could happen immediately (too late for 3.4, but certainly for 3.5). >>> >>> All we need is an appropriate name, and a decision as to which ought to >>> inherit from which. The bike-shedding should be over by 3.5 alpha 1 >>> *wink* >>> >>> Despite my quip about the bike-shedding, I am actually serious. >> You're joking, right? > What part of "I am actually serious" suggests to you that I am joking? > No, I am not joking. > > When you have a misdesigned API that cannot be fixed without breaking > backwards compatibility, or at least cannot be fixed *quickly*, it may > be sensible to leave the old API in place and place a new one > side-by-side. If the old one is actively harmful, it can even be > deprecated for eventual removal, otherwise it can remain indefinitely. > Does the term "legacy API" sound familiar? > > This is *extremely common* in the software industry, at least in that > part that isn't run by cowboy coders who have no concern about breaking > their users' code. It's quite common in Python too: consider the legacy > API of os.system, the deprecated API of the popen2 module, and the > modern subprocess API. > > >> Suppose you were considering taking up a new language and you found >> something in the docs which said: >> "Here's a class that does so-and-so. And here's another slightly >> different one that you can use instead, because we didn't get the first >> one quite right." >> Would that be a turn-on? > Yes. This would tell me that the developers of this language took > backward compatibility seriously, and that they weren't afraid to admit > to mistakes. > > Fair point. (It just feels untidy to me!) At least having two classes would highlight the difference in behaviour. Which makes me think, maybe the right thing to do now is to draw more attention to the behaviour in the docs. Section 8.1.5 time Objects currently states "in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that's None), the result is non-zero." This could be expanded, using the sort of examples Nick Coghlan produced, and a warning added that using bool on time objects is discouraged. And section 3.1 Truth Value Testing which claims to explicitly list all the falsey objects includes "instances of user-defined classes, if the class defines a __nonzero__() or __len__() method, when that method returns the integer zero or bool value |False|" I think this could be reworded. "user-defined classes" does not suggest to me that it includes classes in the stdlib. Would it be going too far to include in this section a short warning that using bool (explicitly or implicitly) on time objects is discouraged, or at least may not behave as expected? Rob Cliffe -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Thu Mar 6 14:49:29 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 08:49:29 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53187670.6070302@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> <53187670.6070302@egenix.com> Message-ID: <1B2F38D1-F5D0-4CD7-AC2B-CD51C2E3DA6A@stufft.io> On Mar 6, 2014, at 8:21 AM, M.-A. Lemburg wrote: > On 06.03.2014 13:08, Nick Coghlan wrote: >> But perhaps I've been told "midnight is false in boolean context". But >> which midnight? There are three that apply to me: >> >>>>> naivemidnight >> datetime.time(0, 0) >>>>> utcmidnight >> datetime.time(0, 0, tzinfo=datetime.timezone.utc) >>>>> localmidnight >> datetime.time(0, 0, tzinfo=datetime.timezone(datetime.timedelta(0, 36000))) >> >> Are they all False? No, no they're not (unless your local timezone is UTC): >> >>>>> bool(utcmidnight) >> False >>>>> bool(naivemidnight) >> False >>>>> bool(localmidnight) >> True > > Now this is a what I consider a valid argument for making a change. > > Thanks, Nick. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Mar 06 2014) >>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ Yea Nick put into words what I?ve been attempting to say better than I ever could have :) ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rosuav at gmail.com Thu Mar 6 15:04:01 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 01:04:01 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53185EA5.3060802@btinternet.com> References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> <5317FC67.7060600@canterbury.ac.nz> <20140306105253.GI28804@ando> <53185EA5.3060802@btinternet.com> Message-ID: On Thu, Mar 6, 2014 at 10:40 PM, Rob Cliffe wrote: > Suppose you were considering taking up a new language and you found > something in the docs which said: > "Here's a class that does so-and-so. And here's another slightly different > one that you can use instead, because we didn't get the first one quite > right." > Would that be a turn-on? If the first one is marked deprecated, then I'd just ignore that one. The only (minor) downside is remembering which one's the deprecated one, so I avoid wasting time going to its docs and then going to the other. Compare: http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Sql/postgres.html http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Sql/pgsql.html In new code, which of those would you use? Is it sufficiently clear? I think it is. With Python's time types, though, there may be links with datetime. Which type does datetime.time() return? Will there be two parallel methods to resolve that? It's slightly more complicated. Still, it's not a killer. I've worked with far messier APIs - look at PHP and MySQL and the "real" functions. Which ones do you need _real_ in and which not? ChrisA From stephen at xemacs.org Thu Mar 6 15:33:10 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 06 Mar 2014 23:33:10 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53187670.6070302@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> <53187670.6070302@egenix.com> Message-ID: <87mwh3pfbt.fsf@uwakimon.sk.tsukuba.ac.jp> M.-A. Lemburg writes: > > Are they all False? No, no they're not (unless your local timezone is UTC): > > > >>>> bool(utcmidnight) > > False > >>>> bool(naivemidnight) > > False > >>>> bool(localmidnight) > > True > > Now this is a what I consider a valid argument for making a change. > > Thanks, Nick. I don't understand this turnabout. After all, time with time zones is the temporal equivalent of ISO 2022. It's just madness encapsulated in a formal data type definition.[1] Nobody should expect to get sane results from manipulating that stuff, only hope to get lucky. The only argument I've seen that corresponds to sane programming practice is Nick's statement that in Python, None, zeros, and empty containers are naturally false-ys, and all other objects are expected to be truth-ys. I find *that* compelling, even though it is backward incompatible with the documented behavior of time.time, and would not affect code using time.time objects that was written in good style. But I still don't like the way actually making the change would validate using "if var:" where "if var is not None:" is appropriate. I don't care if the change is made, but I hope it will be made absolutely clear that it's purely to work around *old* bugs that may never get fixed, and that "if var:" which is actually testing for identity with a false-y sentinel is still strongly discouraged. Footnotes: [1] Time counted in seconds from an epoch is hard enough, just Google for "monotonic clock". :-( From solipsis at pitrou.net Thu Mar 6 15:39:38 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 06 Mar 2014 15:39:38 +0100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <87mwh3pfbt.fsf@uwakimon.sk.tsukuba.ac.jp> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> <53187670.6070302@egenix.com> <87mwh3pfbt.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Le 06/03/2014 15:33, Stephen J. Turnbull a ?crit : > I don't care if the change is made, but I hope it will be made > absolutely clear that it's purely to work around *old* bugs that may > never get fixed, and that "if var:" which is actually testing for > identity with a false-y sentinel is still strongly discouraged. Why "strongly discouraged"? This is more of a style issue than anything else? Regards Antoine. From alexander.belopolsky at gmail.com Thu Mar 6 16:16:44 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 6 Mar 2014 10:16:44 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <5317AE64.90007@egenix.com> <45321B3B-B896-4A73-91AA-7F0188FCFD2C@stufft.io> Message-ID: On Thu, Mar 6, 2014 at 5:39 AM, Antoine Pitrou wrote: > > I think proponents of bool(time(0)) == True view it as a container of > > hours, minutes and seconds. > > No, they view it as an abstraction around the common concept of time. > OK, it looks like we are getting closer to the root of the disagreement. We are talking about the datetime.time type here. It is not "an abstraction around the common concept of time." That role belongs to the datetime.datetime type. The datetime.time type is an implementation of the concept of the *time of day*. In other words, for a datetime instance dt, dt.time() is the fractional part of dt and dt.date() is the integral part. A test for dt.time() is just as natural for datetime as a test for t % (24*60*60) for posix time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at bytereef.org Thu Mar 6 16:49:04 2014 From: stefan at bytereef.org (Stefan Krah) Date: Thu, 6 Mar 2014 15:49:04 +0000 (UTC) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: Oscar Benjamin writes: > On 6 March 2014 12:36, Stefan Krah wrote: > > Regarding decimal literals: > > > > Possible in 3.x, but it would require some investigation if > > people really want arbitrary precision arithmetic by default > > rather than e.g. IEEE Decimal64. > > Interesting. I wasn't aware of Decimal64. > > I don't understand your question/point though. The Decimal module > doesn't provide "arbitrary" precision arithmetic by default. It > provides 28 digit precision arithmetic by default. It does however > allow the creation of Decimal instances with effectively arbitrary > precision from strings, integers etc. Well, yes. You can also emulate Decimal64 with the appropriate context parameters. I meant "arbitrary precision facilities by setting context parameters", but probably many people want to keep those. Due to the compact representation (bid64 or bid128), Decimal64 or Decimal128 would be interesting for doing arithmetic on huge matrices. Stefan Krah From alexander.belopolsky at gmail.com Thu Mar 6 17:13:57 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 6 Mar 2014 11:13:57 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53187670.6070302@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> <53187670.6070302@egenix.com> Message-ID: On Thu, Mar 6, 2014 at 8:21 AM, M.-A. Lemburg wrote: > > Are they all False? No, no they're not (unless your local timezone is > UTC): > > > >>>> bool(utcmidnight) > > False > >>>> bool(naivemidnight) > > False > >>>> bool(localmidnight) > > True > > Now this is a what I consider a valid argument for making a change. FWIW, I would be +0 for making a change so that t.tzinfo is not None implies bool(t.timetz()) is True. My intuition goes like this. Given >>> from datetime import * >>> t1 = datetime(2014, 1, 1) >>> t2 = datetime(2014, 1, 1, 12) >>> t3 = datetime(2014, 1, 1, tzinfo=timezone.utc) Instance t1 has no time information, so t1.time() is false-y. Instance t2 has time information, so t2.time() is true-y. Instance t3 is such that t3.time() == t1.time(), but t3.timetz() has an additional information >>> t3.timetz() datetime.time(0, 0, tzinfo=datetime.timezone.utc) >>> t3.time() datetime.time(0, 0) So t3.timetz() is not the same object as returned by the constructor with no arguments - time(). This is reason enough to make it true-y. This also does not affect my use-case because t3.time() is still false-y in this logic: >>> [bool(t) for t in [t1.time(), t2.time(), t3.time(), time()]] [False, True, False, False] Which is consistent with >>> t3.time() == t1.time() == time() True -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Thu Mar 6 17:36:11 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 6 Mar 2014 11:36:11 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Thu, Mar 6, 2014 at 12:53 AM, Tim Peters wrote: > [Bruce Leban ] > > ... > > Just because you wrote the docs doesn't mean you know what they mean to > > other readers. The point of documentation is to explain it to someone who > > doesn't know what it does after all. > > Of course. What's your point here? > I am with Bruce here. I tried to digest your notes on timezone algebra [1] for years and I still don't understand it. [1] http://hg.python.org/cpython/file/b07400659dba/Lib/datetime.py#l1922 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscar.j.benjamin at gmail.com Thu Mar 6 17:41:34 2014 From: oscar.j.benjamin at gmail.com (Oscar Benjamin) Date: Thu, 6 Mar 2014 16:41:34 +0000 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: On 6 March 2014 15:49, Stefan Krah wrote: > Oscar Benjamin writes: >> On 6 March 2014 12:36, Stefan Krah wrote: >> > Regarding decimal literals: >> > >> > Possible in 3.x, but it would require some investigation if >> > people really want arbitrary precision arithmetic by default >> > rather than e.g. IEEE Decimal64. >> >> Interesting. I wasn't aware of Decimal64. >> >> I don't understand your question/point though. The Decimal module >> doesn't provide "arbitrary" precision arithmetic by default. It >> provides 28 digit precision arithmetic by default. It does however >> allow the creation of Decimal instances with effectively arbitrary >> precision from strings, integers etc. > > Well, yes. You can also emulate Decimal64 with the appropriate > context parameters. > > I meant "arbitrary precision facilities by setting context parameters", > but probably many people want to keep those. > > Due to the compact representation (bid64 or bid128), Decimal64 or > Decimal128 would be interesting for doing arithmetic on huge matrices. I'm still not totally clear here. Do you mean that decimals created with a decimal literal e.g. 1.123d would be some other kind of decimal object that always used a special arithmetic context so that they behaved like a fixed width Decimal64 type? And then someone who wants to do decimal arithmetic with other contexts would still need to import decimal and do the context stuff themselves? Oscar From tim.peters at gmail.com Thu Mar 6 17:50:53 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 10:50:53 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: [Bruce Leban ] >>> ... >>> Just because you wrote the docs doesn't mean you know what they mean to >>> other readers. The point of documentation is to explain it to someone >>> who doesn't know what it does after all. [Tim] >> Of course. What's your point here? [Alexander Belopolsky ] > I am with Bruce here. I tried to digest your notes on timezone algebra [1] > for years and I still don't understand it. > > [1] http://hg.python.org/cpython/file/b07400659dba/Lib/datetime.py#l1922 But those aren't user docs - they're notes for developers who are deeply steeped in internal details. And they're hard! Mucking with "all possible" time zones raises mountains of excruciatingly subtle details and corner cases. The masses of tedious "algebra" were needed to justify how the internals get away with doing "so little" - and to explain why the code still wouldn't work right in all cases if the "standard offset" of a single time zone changed (or changes) over time. Do you claim you still don't understand when bool(time) returns True and False? Those are user docs. I don't claim that reading them will make anyone feel good ;-), but I do believe the computation is described clearly enough to enable a reasonable user to predict the result in all cases. From donald at stufft.io Thu Mar 6 17:53:31 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 11:53:31 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Mar 6, 2014, at 11:50 AM, Tim Peters wrote: > [Bruce Leban ] >>>> ... >>>> Just because you wrote the docs doesn't mean you know what they mean to >>>> other readers. The point of documentation is to explain it to someone >>>> who doesn't know what it does after all. > > [Tim] >>> Of course. What's your point here? > > [Alexander Belopolsky ] >> I am with Bruce here. I tried to digest your notes on timezone algebra [1] >> for years and I still don't understand it. >> >> [1] http://hg.python.org/cpython/file/b07400659dba/Lib/datetime.py#l1922 > > But those aren't user docs - they're notes for developers who are > deeply steeped in internal details. And they're hard! Mucking with > "all possible" time zones raises mountains of excruciatingly subtle > details and corner cases. The masses of tedious "algebra" were needed > to justify how the internals get away with doing "so little" - and to > explain why the code still wouldn't work right in all cases if the > "standard offset" of a single time zone changed (or changes) over > time. > > Do you claim you still don't understand when bool(time) returns True > and False? Those are user docs. I don't claim that reading them will > make anyone feel good ;-), but I do believe the computation is > described clearly enough to enable a reasonable user to predict the > result in all cases. I don?t think a reasonable user would predict that midnight UTC in a timezone with a UTC offset of +5 would be false, while midnight UTC in a timezone with a UTC offset of -5 would not be false. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tim.peters at gmail.com Thu Mar 6 18:01:56 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 11:01:56 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: [TIm] >> ... >> Do you claim you still don't understand when bool(time) returns True >> and False? Those are user docs. I don't claim that reading them will >> make anyone feel good ;-), but I do believe the computation is >> described clearly enough to enable a reasonable user to predict the >> result in all cases. [Donald Stufft ] > I don't think a reasonable user would predict that midnight UTC in a timezone > with a UTC offset of +5 would be false, while midnight UTC in a timezone with > a UTC offset of -5 would not be false. As I said, I didn't claim a reasonable user would feel good about it, and all you're saying here is that they wouldn't feel good about it. I'm not arguing that they should feel good about it. I said that the docs explained the computation clearly enough that a reasonable user - who read the docs and earnestly tried to apply them - _could_ predict the results. And you just showed that you, for example, can predict them. Since you're the very definition of "reasonable", I close my case for that ;-) From alexander.belopolsky at gmail.com Thu Mar 6 18:02:36 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 6 Mar 2014 12:02:36 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Thu, Mar 6, 2014 at 11:50 AM, Tim Peters wrote: > Do you claim you still don't understand when bool(time) returns True > and False? Those are user docs. I don't claim that reading them will > make anyone feel good ;-), but I do believe the computation is > described clearly enough to enable a reasonable user to predict the > result in all cases. > I have to admit that before this discussion, I did not know about the following consequence of the documented behavior: >>> from datetime import * >>> t = datetime(2014, 1, 1, tzinfo=timezone.utc) >>> tz1 = timezone(timedelta(hours=5)) >>> tz2 = timezone(timedelta(hours=-5)) >>> bool(t.timetz()) False >>> bool(t.astimezone(tz1).timetz()) False >>> bool(t.astimezone(tz2).timetz()) True -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Thu Mar 6 18:05:39 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 11:05:39 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: [Alexander Belopolsky ] > I have to admit that before this discussion, I did not know about the > following consequence of the documented behavior: > >>>> from datetime import * >>>> t = datetime(2014, 1, 1, tzinfo=timezone.utc) >>>> tz1 = timezone(timedelta(hours=5)) >>>> tz2 = timezone(timedelta(hours=-5)) >>>> bool(t.timetz()) > False >>>> bool(t.astimezone(tz1).timetz()) > False >>>> bool(t.astimezone(tz2).timetz()) > True I'm not sure I did either! An "aware" time object is a bizarre beast, and I've never used one outside of writing datetime test cases. I'm not even sure why aware time objects exist - we'd have to dig into Guido's subconscious for that one ;-) From donald at stufft.io Thu Mar 6 18:10:23 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 12:10:23 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Mar 6, 2014, at 12:01 PM, Tim Peters wrote: > [TIm] >>> ... >>> Do you claim you still don't understand when bool(time) returns True >>> and False? Those are user docs. I don't claim that reading them will >>> make anyone feel good ;-), but I do believe the computation is >>> described clearly enough to enable a reasonable user to predict the >>> result in all cases. > > [Donald Stufft ] >> I don't think a reasonable user would predict that midnight UTC in a timezone >> with a UTC offset of +5 would be false, while midnight UTC in a timezone with >> a UTC offset of -5 would not be false. > > As I said, I didn't claim a reasonable user would feel good about it, > and all you're saying here is that they wouldn't feel good about it. > I'm not arguing that they should feel good about it. > > I said that the docs explained the computation clearly enough that a > reasonable user - who read the docs and earnestly tried to apply them > - _could_ predict the results. And you just showed that you, for > example, can predict them. Since you're the very definition of > "reasonable", I close my case for that ;-) Actually I wasn?t able to predict it :) Someone else posted a number of times offsets and their boolean values. I was really confused when it turned out that 01:00:00+01:00 (1AM France/Midnight UTC) was False but 19:00:00-05:00 (7PM Boston/Midnight UTC) wasn?t. I only realized that the cause was the specific formula that was used when I reversed it and tried to figure out what time in Boston would be False and realized it was -05:00. I don?t think it?s reasonable by any definition of the word that in order to predict the results a user would have to turn it into an algebraic formula and solve for X to determine that the only way for Boston to have a False time is if time was negative. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alexander.belopolsky at gmail.com Thu Mar 6 18:11:33 2014 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 6 Mar 2014 12:11:33 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051924.05252.shai@platonix.com> <201403052044.55720.shai@platonix.com> <20140305192419.GD28804@ando> Message-ID: On Thu, Mar 6, 2014 at 12:05 PM, Tim Peters wrote: > I'm not sure I did either! An "aware" time object is a bizarre beast, > and I've never used one outside of writing datetime test cases. I'm > not even sure why aware time objects exist - we'd have to dig into > Guido's subconscious for that one ;-) > They are occasionally useful if you want to split datetimes into date and time parts, process those separately and recombine in the end without loosing tzinfo. I don't think anything involving time.utcoffset() makes much sense and it is unfortunate that time.utcoffset() can be invoked implicitly when aware time is used in boolean context. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.peters at gmail.com Thu Mar 6 18:13:36 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 11:13:36 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: [Antoine Pitrou ] > ... > It is not a coincidence, IMO, that the three persons arguing that the > current behaviour is reasonable are implementors of datetime modules: you, > Tim and Alexander. All other people find the behaviour baffling. The behavior of "aware" time objects is indeed bizarre, but then aware time objects are bizarre beasts from the start (a time zone attached to a mere time-of-day, divorced from date info, doesn't make any real sense to me). The reasons I already explained (possible extensions to naive time's repertoire, in the areas of type conversions and arithmetic) account for why bool(time()) returns False. _As things turned out_ no such extensions were made, so we're left with a foundation sticking out of the ground with nothing built on top of it. Yawn ;-) From songofacandy at gmail.com Thu Mar 6 18:23:31 2014 From: songofacandy at gmail.com (INADA Naoki) Date: Fri, 7 Mar 2014 02:23:31 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53184096.3050409@egenix.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184096.3050409@egenix.com> Message-ID: I feel zero value of non abelian group should not mean False in bool context. () + () == () "" + "" == "" 0 + 0 == 0 timedelta() + timedelta() == timedelta() time() + time() => TypeError On Thu, Mar 6, 2014 at 6:32 PM, M.-A. Lemburg wrote: > On 06.03.2014 09:46, Donald Stufft wrote: >> >> On Mar 6, 2014, at 3:35 AM, M.-A. Lemburg wrote: >> >>> On 06.03.2014 03:23, Donald Stufft wrote: >>>> >>>> On Mar 5, 2014, at 9:15 PM, Tim Peters wrote: >>>> >>>>> [Donald Stufft] >>>>>> When the documented behavior is both nonsensical and the cause of hard to debug bugs that >>>>>> is a pretty compelling use case to me, unless you actively enjoy being user hostile. >>>>> >>>>> Breaking code that currently works is as hostile as hostile gets. Where is the evidence that >>>>> no code relies on the current behavior? For that matter, where is the evidence that the >>>>> current behavior is a significant cause of bugs? I know I've used "if some_time_object:", >>>>> but it did exactly what I expected it to do. >>>> >>>> Forgive me if I'm wrong, but aren't you the author of the date time module? If that's the case >>>> what you expect it to do isn't particularly relevant as you're intimately aware of it's >>>> implementation. >>> >>> Just in case you're looking for a relevant use case: >>> >>> Having bool(time(0,0,0)) allows you to quickly check whether you are >>> dealing with a datetime value with (non-trivial) time part or not. >> >> I don't see how midnight is any more or less trivial than 12:01. >> >>> >>> You run into situations where you have to test for this in >>> date/time conversions, arithmetics, etc. e.g. if you need to convert >>> a datetime value to a date and want to prevent truncation of >>> information, or if you want to format a datetime value in a user >>> friendly way by omitting the zero time part, or if you're doing >>> datetime arithmetic that has to follow special requirements w/r to >>> days (think interest or insurance math) and you want to >>> quickly check whether you can use the fast path simple >>> calculation, or you need to do the full blown complicated part. >> >> I think these would be better served by actually checking for what you mean. >> For the record I also think that checking for a date time to not be None >> is also better served by actually checking for what you mean. The >> difference is in intent and likelihood of confusion. > > FWIW, I expect bool(time(0,0,0)) == False, just like I expect > bool(0.0) == False. I would find it confusing to have > bool(zero_element) == True. > >> For all of those you're going to be explicitly testing and working with >> midnight objects, so you're going to test them, you're going to exercise >> that code. In the ``is None`` case, Midnight is just another value so that >> bug will lay dormant and undetected until someone just happens to >> hit an unlucky time. And once you get that it's likely to be difficult to >> reproduce. > > datetime values with zero time are *very* common in practice > (you run into them whenever you convert a date value into a datetime > value), so the "is None" case is easy to reproduce and will hit > you more often than you like. > > BTW: Not using "is None" will bite you in many other ways as > well. None it typically used as value for "not initialized" or > "no value provided". This meaning is completely different from > "empty selection" or "empty string", so in order to address all > those cases as well, you'd have to change: > > bool(()) == True > bool('') == True > etc. > > The "if x is None:" test is also faster than "if x:", so actually > win something by coding correctly ;-) > > Please provide a stronger argument for needing to change > bool(time(0,0,0)) than one which is built on buggy code :-) > (I'm running out of smileys...) > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Mar 06 2014) >>>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-04-09: PyCon 2014, Montreal, Canada ... 34 days to go > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -- INADA Naoki From tim.peters at gmail.com Thu Mar 6 18:29:37 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 11:29:37 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53181ADA.2030401@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> Message-ID: [Tim Peters] >> For example, modular arithmetic on time >> objects was a possibility. In that case, time(0, 0, 0) would become >> "a zero value" [Greg Ewing ] > That only follows if you interpret "modular arithmetic on > time objects" as meaning that you can directly add one time > object to another. Of course. > But that would be confusing times with timedeltas. The concept of > a zero *timedelta* makes sense, but not a "zero time". The only difference between time and timedelta is in implementation details. In effect, time values are (or _can_ be viewed as) a subset of timedelta values, restricted to non-negative durations strictly less than 24 hours. From that point of view, it's obvious how to do modular (mod 24 hours) arithmetic on time values. And some people said they wanted that. It wasn't obviously useful enough to implement at first, but neither did we want to preclude it in the future. I don't personally want it. >> People can say that "midnight" isn't a compelling "sentinel value", >> and I agree about the "compelling" part, but in all implementation >> respects it does _act_ as "a sentinel value". > If someone is using midnight to represent an unspecified > time, I'd say they have a bug. An appointment scheduled at > midnight is not the same as an appointment that's not > scheduled at all. Again obviously so. In much the same way, there's nothing forbidden about -1 as an integer, but it's ubiquitously used as an error return in CPython's implementation. That doesn't mean CPython is buggy, it implies that CPython has other ways to distinguish whether a -1 return does or does not mean "error!". For example, in some applications (not all), "exactly midnight" simply can't happen as a legitimate starting or ending time. From stephen at xemacs.org Thu Mar 6 18:40:42 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 07 Mar 2014 02:40:42 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> <53187670.6070302@egenix.com> <87mwh3pfbt.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87lhwnp6n9.fsf@uwakimon.sk.tsukuba.ac.jp> Antoine Pitrou writes: > Le 06/03/2014 15:33, Stephen J. Turnbull a ?crit : > > never get fixed, and that "if var:" which is actually testing for > > identity with a false-y sentinel is still strongly discouraged. > > Why "strongly discouraged"? This is more of a style issue than anything > else? No, it's not just a style issue. As Skip points out, it's a *semantic* issue as well. You're really testing for not for the boolean value of values of one type, but for a difference of type ("initialized whatever" vs "uninitialized variable"). Pragmatically, this would be half a dozen of one, six of the other, except that there are two more possibilities: a false-y of a different type, and a truth-y of a different type. I don't think the spurious truth-y matters very much ... you'd expect a TypeError to be raised pretty quickly, and if not, it's a bad bug (by the time you notice the bad value, it's really hard to work back to where and why it's been injected). The spurious false-y, on the other hand, seems quite likely to lead to spurious values *of the expected type*. To restate my earlier example: my_time = None if not my_time and x: my_time = x.expected_to_be_parsed_time_but_parse_bug_returns_0 if not my_time: my_time = time.now() You may never catch *that* parser bug, because the value of 'my_time' always looks right (ie, like a datetime.time value). But in my_time = None if my_time is None and x: my_time = x.expected_to_be_parsed_time_but_parse_bug_returns_0 if my_time is None: my_time = time.now() you're on the same footing as with the truth-y -- just a bit lucky and you get a quick TypeError. This is an objective benefit (although you can say "the probability that there will be a bug to catch is too low to care about" if you like, it's obviously bigger than zero). I also value the psychological benefit of being precise here. I'm not even sure it's possible to fool 'is' into thinking some other object is None, but people do a great job of convincing themselves of things like "datetime.time objects can't be false" all the time. Use the "is None" idiom and you know exactly what you're doing. This latter is close to "just style", of course. Steve From guido at python.org Thu Mar 6 18:48:53 2014 From: guido at python.org (Guido van Rossum) Date: Thu, 6 Mar 2014 09:48:53 -0800 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> Message-ID: On Thu, Mar 6, 2014 at 12:14 AM, Mark H. Harris wrote: > On Wednesday, March 5, 2014 11:56:02 PM UTC-6, Guido van Rossum wrote: >> >> Do you actually have a degree in math, or do you just remember your high >> school algebra? >> > > hi Guido, ouch. Its a story, glad you asked. My first trip to > college 1974-1977 [...] > I must have hit a nerve -- I wasn't requesting a transcript! :-) A simple "I dropped out of math in college to pursue a career in programming" would have been sufficient (my own story is pretty similar :-). > We might agree to stick with the discussion, if you're are willing, and > stay away from *ad hominem* > attacks, nor credential bashing. A person either knows what they are > doing, or they don't. And if > they are willing to contribute, why knock it, or them? > I was asking because I am having a hard time getting your point, and it feels like you keep repeating it without clarifying it. > The numbers in math usually are quite strictly typed: whole theories only >> apply to integers or even positive integers, other things to all reals but >> not to complex numbers. >> > > Everyone keeps making the points noted above! Yes, I know... concur~ > Guido, all data types in most computer high level languages > are all very strictly statically bound also. > I'm not sure that that description applies to Python; it sure doesn't match how I *think* about numbers in Python. > So what? You know this better > than anyone, because you have taken so much abuse from trolls about it > over the > years. > Actually, I haven't -- I can smell a troll a mile away and just mute the conversation. > We all know that the best way to handle name binding is dynamically. > That's your opinion. There are pros and cons and both static and dynamic binding have their place. > And that was a paradigm shift, was it not? > I've never claimed such a hyperbole. > Go take a look at Rexx. It has NO types. None. > Not at the surface, anyway. Everything to the user of the language is a > string. This is > even true for most of "object" Rexx too. *Numbers *are just strings of > characters that > are parsed and interpreted by Rexx as valid *Rexx Numbers*. > Why do you italicize this? > It works. There is no > real point in arguing that its a bad idea, because it served the Rexx > community for > many years... even now, Rexx is not dead. Yes, under the covers (not > magic) a complex > number is going to be handled differently than a real number. Yeah, what > is your point? > They are handled differently in my TI 89 too... so what, I change the > context on the 89 > and now I'm doing complex number math (not often, I might add). > By "context", here, do you mean some specific state in the computer, or are you referring to a different way of thinking about it (i.e. in your head)? > If I set the context for > reals, then now I'm doing real math... it really is not that difficult. > So I suppose depending on how you set the context, the square root of -1 either returns a complex number, or raises an error? And comparisons are right out once your context is set for complex numbers? Or are they still allowed when the imaginary part is exactly zero? (What if it is nearly zero?) > Think about this for just > a minute. I have used complex math exactly three times in my life. I used > it in high school > to study the concept in math analysis. I used it in my EE classes... > electrical engineers > get a lot out of complex numbers. And I used it when I was interested in > the Mendlebrot > set many years ago when it was cool to plot the famous fractal on early > cga screens. > When was the last time you used complex numbers? When was the last time a > bank, or > a hospital, or Montgomery Wards used complex numbers? If someone needs > complex > numbers, Python could change the context "dynamically" and move through > the problem set. > Why should the user need to "manually" change the context if (AI) could > change it for them > on-the-fly? Just try to get a feel for the question, and stop with trying > to beat me up on > my credentials. > I still don't understand the question. Can you be more precise instead of using more rhetoric? Is your point just that you don't want to have to deal with complex numbers? That's fine, and it's already (mostly) how Python works -- you must use a complex literal or the cmath module before any complex numbers appear (the exception is that x**y returns a complex number when x is negative and y is not a whole number -- but arguably that's the best answer). > (And what about quaternions? Or various infinities? :-) >> > > What about quaternions? If you extend the complex number system you > change the context. That's not hard... > So, by context you really seem to be referring to some specific state of the program. Perhaps you are even talking about extending the existing notion of numeric context used by Python's Decimal type. But it's not very clear because "you change the context" is also a common term for changing the topic of a discussion. You would not expect the context for "reals" processing to be the same for > the context of > processing three dimensional space with pairs of complex numbers, would > you? > Actually I'm not sure I *need* a context for this. In Python things like this are usually just solved through a combination of operator overloading and dynamic binding, so that e.g. x*y can be a number when x and y are numbers, but it can mean a vector product of some sort if x and/or y are vectors. > Python > does complex number processing now. But that is a very specialized > category of use > case that requires special context and (under the covers) typing relevant > to complex number > pairs. The context can change "dynamically" to suit the problem set, > that's all I'm saying. > I'm sorry, but I am *still* unsure about what you mean by "context". Python does not need a context object to switch between complex and real number processing -- it's all done through operator overloading. > I am not saying in all of my dreaming here that typing is not important > (down under). Python is > called an object based language, yes? Not object oriented, right? > Actually, modern Python is considered object-oriented. I called it object-based in a *very* early stage, when there was no class statement in the language. But IIRC it was added before the first public release (or soon after), although another round of improvements in this area happened in the early 2000s (eradicating most of the differences between classes defined by C and Python code). > But we all know that down > under the covers (not magic) python uses Classes and instances of > classes--objects. We > don't pretend that what makes object based languages work is magic? do we? > "We"? > Unifying the > number system on a computer does not have to be grounded in paradigms that > serviced the > industry (and academy) for the past 40 years; mostly because memory was > expensive and > processing was slow. I suggest that if memory had been cheap, back in the > day, and processing > had been very fast (as it is today) IEEE 754 1985 floats and doubles would > never have been > used. We would have used Decimal floating points right from the get-go. > Initially, that really is > all I'm asking for on the outset--- lets move to default decimal floating > point arithmetic for real > numbers processing. > Now you've got a specific proposal and we can discuss pros and cons. This is a topic that comes up occasionally and it is indeed a pretty interesting trade-off. I suspect the large (and fast-growing) SciPy community would prefer to keep binary floating point, because that's what their libraries written in Fortran or C++ want, and extra binary/decimal conversions at the boundaries would just slow things down. But I'm really speculating here -- maybe they don't need high-performance conversion between binary and decimal, since (perhaps) they may do their bulk I/O in C++ anyway. Or maybe it varies per application. > In the future I am thinking about systems of languages that interact with > human speech; understanding > *spoken number* just like they will understand *symbol number.* There is > really no reason (other > than paradigm) that this would not be possible either. > This is the kind of talk that I wish we could keep out of the python-ideas list. (Except for the symbolic algebra, for which various third-party Python libraries already exist.) > Otherwise, Guido, we might all of us just continue to use C and code up > our statically bound types by > hand using nothing but int, long, float, and double. > > Its time to innovate. > Rhetoric again. > Kind regards, BDfL, > > marcus > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at bytereef.org Thu Mar 6 19:13:28 2014 From: stefan at bytereef.org (Stefan Krah) Date: Thu, 6 Mar 2014 19:13:28 +0100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: <20140306181328.GC31090@sleipnir.bytereef.org> Oscar Benjamin wrote: > > Well, yes. You can also emulate Decimal64 with the appropriate > > context parameters. > > > > I meant "arbitrary precision facilities by setting context parameters", > > but probably many people want to keep those. > > > > Due to the compact representation (bid64 or bid128), Decimal64 or > > Decimal128 would be interesting for doing arithmetic on huge matrices. > > I'm still not totally clear here. > > Do you mean that decimals created with a decimal literal e.g. 1.123d > would be some other kind of decimal object that always used a special > arithmetic context so that they behaved like a fixed width Decimal64 > type? And then someone who wants to do decimal arithmetic with other > contexts would still need to import decimal and do the context stuff > themselves? That would be one option. I'm not sure if it is a *good* option. Another option is to use the regular Decimal objects with the IEEE context and perhaps add functions to convert to bid64 etc. Yet another issue is whether a Decimal core type should use the function names from IEEE 754-2008. The names are different, though the behavior is largely the same. My main point here is that even for the Decimal literal (which seems innocent enough) there is a lot to discuss, since we can specify the semantics only once. Stefan Krah From abarnert at yahoo.com Thu Mar 6 19:47:41 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 10:47:41 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: <6ED9830A-678A-445C-9C29-FC6A74B3F569@yahoo.com> On Mar 6, 2014, at 3:13, Stefan Krah wrote: > Antoine Pitrou writes: >> It is not a coincidence, IMO, that the three persons arguing that the >> current behaviour is reasonable are implementors of datetime modules: >> you, Tim and Alexander. All other people find the behaviour baffling. > > Not all. :) I think viewing midnight as (unix_time % 86400) is > quite reasonable. I agree with Stefan here. Treating midnight as zero is not at all baffling. There's a reason modular arithmetic is taught to kids as "clock arithmetic", after all. And it's not unheard of for other languages/libraries/apps to treat midnight as a 0, or even to use it as a null time. Someone else already mentioned that many RDBMS's don't have a separate date type and store dates as datetimes with midnight time. IEEE datetimes also do this--leaving off any trailing component is equivalent to having 0's there. And this isn't some experts-only thing. Novices regularly ask why we need the date class when a datetime with 0 time does the same thing--often because that's what their first language did, but sometimes just as an a priori expectation. On the other hand, the alternative isn't baffling either. Unlike, say, Oracle, Python has separate types for date, time, and datetime, so we don't need to use 0 for "n/a", and it has tz-aware values for all three types, making midnight much less special, and it doesn't have modular arithmetic on times (and timedeltas), etc. So honestly, if handed the Python time class, I wouldn't know whether to expect midnight to be treated as 0 (and therefore falsey) or not, and would have to read the docs rather than guessing. When a choice really is arbitrary like this, "it does what it's documented to do" is the only notion of correct that makes sense. (As a disclaimer, I have implemented datetime libraries for C and C++, but not for Python.) From abarnert at yahoo.com Thu Mar 6 20:01:16 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 11:01:16 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> Message-ID: <5175E062-E30B-4442-828E-4BDA8A01AD9E@yahoo.com> On Mar 6, 2014, at 4:08, Nick Coghlan wrote: > if x not in (naivemidnight, utcmidnight): > # This is the current bool(x) > .... > if x != naivemidnight: > # This has no current shorthand > .... > if x != utcmidnight: > # This has no current shorthand > .... > if x != localmidnight: > # This has no current shorthand > .... This is a great argument. The problem here isn't that we use midnight as 0, but that naive and aware times are the same type and we use UTC midnight as 0 for aware types. The other languages/libraries/apps that treat midnight as 0 are generally either naive-only, or much more explicit about awareness. Since that isn't going to change in Python, maybe it would be better to provide these values (or functions that return them) as names in the module, and explicitly encourage testing against them in place of bool testing, and define bool testing exactly like this, whether or not it's deprecated? From tjreedy at udel.edu Thu Mar 6 20:32:43 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 06 Mar 2014 14:32:43 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: On 3/6/2014 4:52 AM, Antoine Pitrou wrote: > It is not a coincidence, IMO, that the three persons arguing that the > current behaviour is reasonable are implementors of datetime modules: > you, Tim and Alexander. All other people find the behaviour baffling. Wrong. I don't. What I find baffling and annoying is the endlessly repeated false claim that there is nothing special about midnight, as if a thousands repetitions will change the fact. Ditto for the claim that there is nothing problematical about using 'a' as a substitute for 'a is not None'. Surely you know that the subset of people who pay attention to an endless drumbeat thread like this is severely biased. -- Terry Jan Reedy From barry at python.org Thu Mar 6 21:21:36 2014 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Mar 2014 15:21:36 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> <53187670.6070302@egenix.com> <87mwh3pfbt.fsf@uwakimon.sk.tsukuba.ac.jp> <87lhwnp6n9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20140306152136.537d79e6@anarchist.wooz.org> On Mar 07, 2014, at 02:40 AM, Stephen J. Turnbull wrote: >I also value the psychological benefit of being precise here. I'm not >even sure it's possible to fool 'is' into thinking some other object >is None, but people do a great job of convincing themselves of things >like "datetime.time objects can't be false" all the time. Use the >"is None" idiom and you know exactly what you're doing. This latter >is close to "just style", of course. Not just "you" (i.e. the author of the code), but everyone who comes after you and reads it. Being more explicit with identity tests against None assists future minions in understanding the intent of the code. When using the Socratic Method Of Code Reviews, I always ask about whether the author really expects the 'var' in "if var:" to be any truth-y value. The answer is usually "no", in which case I encourage tightening up the conditional. There are valid cases where a test is really trying to catch any truth-y or false-y value. I usually encourage a comment to clarify the author's intent in those cases. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From barry at python.org Thu Mar 6 21:29:36 2014 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Mar 2014 15:29:36 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <5318626F.5080203@btinternet.com> Message-ID: <20140306152936.3c990c46@anarchist.wooz.org> On Mar 06, 2014, at 11:56 AM, Rob Cliffe wrote: >Instances of existing code that would be broken by the change: 0 You can't know this because you can't audit all the Python code in the world. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From g.brandl at gmx.net Thu Mar 6 22:36:23 2014 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 06 Mar 2014 22:36:23 +0100 Subject: [Python-ideas] Add "goto fail" to Python? In-Reply-To: References: Message-ID: Am 06.03.2014 11:11, schrieb Nick Coghlan: > > On 6 Mar 2014 13:55, "Sturla Molden" > > wrote: >> >> "goto fail" is a well-known error handling mechanism in open source software, > widely reputed for its robusteness: >> >> > http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c >> >> > https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150ccbdf0aec1878a41c17c41d358a3b:lib/x509/verify.c >> >> I believe Python needs to add support for this superior paradigm. > > Unfortunately, we can't throw stones about those, since we currently have > hostname matching off by default and expect developers to turn it on. And on another level, we use the same error handling method in C code (which is not bad per se of course). The literal code "goto fail;" actually occurs about 200 times in the CPython sources :) Aaand... we also don't have a policy to always use braces... Georg From kaiser.yann at gmail.com Thu Mar 6 22:41:56 2014 From: kaiser.yann at gmail.com (Yann Kaiser) Date: Thu, 6 Mar 2014 22:41:56 +0100 Subject: [Python-ideas] Add "goto fail" to Python? In-Reply-To: References: Message-ID: What does this add that we can't do with control flow tools such as try..finally or context managers? On 6 March 2014 22:36, Georg Brandl wrote: > Am 06.03.2014 11:11, schrieb Nick Coghlan: >> >> On 6 Mar 2014 13:55, "Sturla Molden" >> > > wrote: >>> >>> "goto fail" is a well-known error handling mechanism in open source software, >> widely reputed for its robusteness: >>> >>> >> http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c >>> >>> >> https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150ccbdf0aec1878a41c17c41d358a3b:lib/x509/verify.c >>> >>> I believe Python needs to add support for this superior paradigm. >> >> Unfortunately, we can't throw stones about those, since we currently have >> hostname matching off by default and expect developers to turn it on. > > And on another level, we use the same error handling method in C code > (which is not bad per se of course). The literal code "goto fail;" actually > occurs about 200 times in the CPython sources :) > > Aaand... we also don't have a policy to always use braces... > > Georg > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From ethan at stoneleaf.us Thu Mar 6 22:35:36 2014 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 06 Mar 2014 13:35:36 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> Message-ID: <5318EA28.3040305@stoneleaf.us> On 03/05/2014 07:42 AM, Paul Moore wrote: > On 5 March 2014 15:08, Yann Kaiser wrote: >> Let me show you an actual zero: >> >> if event.num_attendants: >> prepare_cake() >> else: >> cancel_event() >> >> When no one is coming to your party, is is clearly a different >> condition than if any number of people are coming to your event. When >> you read "if num_attendants", you can clearly tell this is going to do >> something depending on if people are coming or not. > > I'm sorry, are you really trying to say that the above code is better than > > if event.num_attendants != 0: > prepare_cake() > else: > cancel_event() > > ? Yes. This is Python. blah blah blah != 0 is unnecessary boiler-plate [1]. -- ~Ethan~ [1] In most cases. I have used `== 0` or `!= 0` when it makes the code clearer, but that's pretty rare. -- ~Ethan~ From harrismh777 at gmail.com Thu Mar 6 23:23:44 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 14:23:44 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> Message-ID: <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> On Thursday, March 6, 2014 11:48:53 AM UTC-6, Guido van Rossum wrote: {snip} hi Guido, thanks for your responses, your candor, and your kindness; I think dialogue will work, and I promise to keep the rhetoric to a bare minimum, if at all. :) There really are only two questions I am going to try to answer here, and some of the answer goes back to Stefan's (and others) questions as well, so I hope its helpful. > So, by context you really seem to be referring to some specific state of > the program. Perhaps you are even talking about extending the existing > notion of numeric context used by Python's Decimal type. But it's not very > clear because "you change the context" is also a common term for changing > the topic of a discussion. > This is what I mean by "context," for this entire discussion, mostly having to do with Decimal and the "context manager" and these two lines: getcontext() with localcontext(ctx=None) as context_manager Allow me to back up a bit... the pdeclib module was not difficult for me because of the mathematics (no brag) I can code transcendental functions in my sleep. The hard part of that project last week was coming to grips with the context manger, and the parameterization of context attributes in the Decimal class. Back in the day when I did this work for Rexx at IBM I used NUMERIC DIGITS and NUMERIC FUZZ to emulate (in a crude way) what Decimal is doing correctly with its context, with the context manager. I credit Oscar Benjamin for helping me get up to speed with this concept (and I am so glad he did too, because its key for this entire discussion. Before we go on, allow me to explain my italics of *Number *and *PythonNumber.* These are each an abstract base class. They are a class that is never instantiated, but from which all other "numbers" are derived as objects. (more below) > I'm sorry, but I am *still* unsure about what you mean by "context". > Python does not need a context object to switch between complex and real > number processing -- it's all done through operator overloading. > (more on this below, but I am thinking beyond overloading/ actually, virtual functions and templates) > Actually, modern Python is considered object-oriented. > Thank you. This has everything to do with this discussion, but allow me to take a humorous break and relate an anecdote... I have had numerous discussions with T.R. and C.A and S.D. and others where in the end python was object based. Ha! Nope, you have seen it right here, the BDfL says its "object oriented," and that's the end of the argument! (ok, tiny rhetoric) > > Unifying the >> number system on a computer does not have to be grounded in paradigms >> that serviced the >> industry (and academy) for the past 40 years; >> > {snip} > > Now you've got a specific proposal and we can discuss pros and cons. This > is a topic that comes up occasionally and it is indeed a pretty interesting > trade-off. I suspect the large (and fast-growing) SciPy community would > prefer to keep binary floating point, because that's what their libraries > written in Fortran or C++ want, and extra binary/decimal conversions at the > boundaries would just slow things down. But I'm really speculating here -- > maybe they don't need high-performance conversion between binary and > decimal, since (perhaps) they may do their bulk I/O in C++ anyway. Or maybe > it varies per application. > Here is the main response for this discussion, and I will endeavor to keep the rhetoric down, I promise. This may even be easier to accomplish in 3.x without breaking anyone, or any third party software either; depends In my view numbers are objects (like circles, squares and triangles; in polymorphism discussions). Numbers are nothing more than objects which have "contexts" just like circles and squares and triangles are nothing more than objects that have "contexts". In the following discussion think in terms of object oriented (as in Grady Booch) rather than any specific language--- and certainly not python syntax. um, think C++ for now, if you must think of any. A *Number *is an abstract base class with "context" attributes and pure virtual functions--- it will never be instantiated---and *PythonNumber *will derive from that; also an abstract base class. Here is the Class hierarchy I am proposing: *Number* *PythonNumber* Decimal Real <======= this is the default BinaryIEEE85 Real_b &c (...) omitted for clarity Complex Quaternion Rational Fraction &c-------------------------------------------------- Well, there it is. The idea is that any function or method that takes a *Number* reference or a *PythonNumber *reference does not have to interrogate what type of *Number* it is... it just works (why?) glad you asked, because of polymorphism and a three pointer hop down a virtual function table! If a function or method gets a *Number *parm in as in method(num) then to get the pretty print representation of the number is simply num.pretty_print(), or to get an evaluation of the number is num.eval(), or to get the string rep of the number is num.str()... and on and on. The point is that other parts of the system no longer need to know what "type" of number object it is, the right code gets called because of virtual functions, operator overloading, and the beautiful virtual function table (all under the covers, not MAGIC, but polymorphism). Python at present is disjointed when it comes to number as a concept. In my view numbers need to be objects, and the Class hierarchy (see my simplified version above) needs to unify numbers across the python boards (so to speak) so that "types" are only important to the implementors, and so that adding new "types" is easy, concise, and coherent. I realize that this suggestion is over the top in terms of size and weight (Stefan's concern above). But not really, when you think of conceptualizing the unification of numbers under *Number *and *PythonNumber *. There may be other kinds of numbers too, besides these... like maybe *GmpyNumber* of *BC_Number*, or others. The bottom line is that we have an object oriented language in front of us that has the software engineering advantages which would allow this kind of hierarchy and conceptualization of a unified number system. Let's leverage our technology for mutual advantage across python communities? Thanks for your consideration, Sincerely, Kind regards, marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Thu Mar 6 23:38:42 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 07 Mar 2014 11:38:42 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> Message-ID: <5318F8F2.5010209@canterbury.ac.nz> Tim Peters wrote: > The only difference between time and timedelta is in implementation > details. Only if you define it that way. To my way of thinking, a time-of-day is like a mod-24-hour datetime, not a mod-24-hour timedelta. It seems you're thinking of it as a mod-24-hour timedelta. Given that, I can see why you think that it's bizarre to attach a timezone to one. In fact, I'd say if that's really how a time object is meant to be interpreted, they shouldn't even be *allowed* to have a timezone, any more than a timedelta can. In any case, I don't see how this interpretation justifies the truthiness behaviour with timezones. From my reading of the docs, the *intention* seems to be for midnight UTC to be false and all other times to be true. I would never have suspected the actual behaviour with negative offsets, which looks like an outright bug to me. Or is there some reason for it that I'm not seeing? -- Greg From rosuav at gmail.com Thu Mar 6 23:41:08 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 09:41:08 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> Message-ID: On Fri, Mar 7, 2014 at 9:23 AM, Mark H. Harris wrote: > Well, there it is. The idea is that any function or method that > takes a Number reference > or a PythonNumber reference does not have to interrogate what type of > Number it is... it just > works (why?) glad you asked, because of polymorphism and a three pointer hop > down a virtual > function table! That's way too concrete for Pythonic style :) All you need to do is have each numeric type implement the same operations, and there you are, as the Lord Chancellor said, out of your difficulty at once! And that's what we already have. You can add two numbers and they'll simply add. In fact, a C++ style "hop down a virtual function table" couldn't handle that. I could make a class hierarchy like you describe, and have each one have an add() method or operator+(), but somewhere along the line, something still has to cope with the fact that it could be given any sort of number - there has to be code someplace that handles the adding of a (Decimal) Real and a Real_b, because some day, someone's going to do it. (The correct response might be to raise TypeError, on the basis that that action merges two separate inaccuracies. But more likely, the correct response is to convert one of them to the other type.) What does your proposed hierarchy offer that numbers.Number doesn't? ChrisA From rosuav at gmail.com Thu Mar 6 23:52:28 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 09:52:28 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5318F8F2.5010209@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: On Fri, Mar 7, 2014 at 9:38 AM, Greg Ewing wrote: > It seems you're thinking of it as a mod-24-hour timedelta. > Given that, I can see why you think that it's bizarre > to attach a timezone to one. In fact, I'd say if that's > really how a time object is meant to be interpreted, > they shouldn't even be *allowed* to have a timezone, > any more than a timedelta can. Which is the earlier time: 18:00:00 Australia/Melbourne, or 03:00:00 America/New_York? If you add a date to it, you could get an aware datetime that represents an exact instant, and compare them. Can you compare them, as they are? Is it reliable? This is nothing to do with timedelta versus datetime. It's to do with attaching timezone information to a dateless time. ChrisA From barry at python.org Thu Mar 6 23:45:47 2014 From: barry at python.org (Barry Warsaw) Date: Thu, 6 Mar 2014 17:45:47 -0500 Subject: [Python-ideas] Add "goto fail" to Python? References: Message-ID: <20140306174547.00eca988@anarchist.wooz.org> On Mar 06, 2014, at 10:36 PM, Georg Brandl wrote: >Aaand... we also don't have a policy to always use braces... Yeah, I've been having an interesting conversation on FB about this very thing (spurred by a code sample of the now-infamous Apple goto fail fail :). I personally wouldn't be opposed to changing PEP 7 to require it. But I remember us at least *discussing* it at the time and explicitly deciding against requiring those braces. -Barry (OTOH, I had to physically torture Emacs to write the Apple goto fail example, so I guess the answer is to just use a decent text editor. M-x wink RET). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From shai at platonix.com Thu Mar 6 23:55:29 2014 From: shai at platonix.com (Shai Berger) Date: Fri, 07 Mar 2014 00:55:29 +0200 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306152136.537d79e6@anarchist.wooz.org> References: <201403051216.12392.shai@platonix.com> <87lhwnp6n9.fsf@uwakimon.sk.tsukuba.ac.jp> <20140306152136.537d79e6@anarchist.wooz.org> Message-ID: <2750802.jzuIGEshV5@deblack> On Thursday 06 March 2014 15:21:36 Barry Warsaw wrote: > On Mar 07, 2014, at 02:40 AM, Stephen J. Turnbull wrote: > >I also value the psychological benefit of being precise here. I'm not > >even sure it's possible to fool 'is' into thinking some other object > >is None, but people do a great job of convincing themselves of things > >like "datetime.time objects can't be false" all the time. Use the > >"is None" idiom and you know exactly what you're doing. This latter > >is close to "just style", of course. > > Not just "you" (i.e. the author of the code), but everyone who comes after > you and reads it. Being more explicit with identity tests against None > assists future minions in understanding the intent of the code. When using > the Socratic Method Of Code Reviews, I always ask about whether the author > really expects the 'var' in "if var:" to be any truth-y value. The answer > is usually "no", in which case I encourage tightening up the conditional. > Wait -- you just argued for replacing if time_obj: not by if time_obj is not None: -- which is a more relaxed conditional -- but rather by if isinstance(time_obj, datetime.time): That seems quite un-pythonic, and *that* - from you - is quite unlikely, so I probably misunderstood. Do you mind clarifying? [A guess: The argument you intended to make was about an "if not var:" test changed to "if var is None:". It does not survive inversion of sense well.] Thanks, Shai. From dholth at gmail.com Thu Mar 6 23:56:14 2014 From: dholth at gmail.com (Daniel Holth) Date: Thu, 6 Mar 2014 17:56:14 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5318EA28.3040305@stoneleaf.us> References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> <5318EA28.3040305@stoneleaf.us> Message-ID: The obvious solution is just to fix the Python if statement to remove implicit bool coercion. So they would all evaluate to if isinstance (x, bool) and x. Problem solved. On Mar 6, 2014 5:27 PM, "Ethan Furman" wrote: > On 03/05/2014 07:42 AM, Paul Moore wrote: > >> On 5 March 2014 15:08, Yann Kaiser wrote: >> >>> Let me show you an actual zero: >>> >>> if event.num_attendants: >>> prepare_cake() >>> else: >>> cancel_event() >>> >>> When no one is coming to your party, is is clearly a different >>> condition than if any number of people are coming to your event. When >>> you read "if num_attendants", you can clearly tell this is going to do >>> something depending on if people are coming or not. >>> >> >> I'm sorry, are you really trying to say that the above code is better than >> >> if event.num_attendants != 0: >> prepare_cake() >> else: >> cancel_event() >> >> ? >> > > Yes. This is Python. blah blah blah != 0 is unnecessary boiler-plate [1]. > > -- > ~Ethan~ > > > [1] In most cases. I have used `== 0` or `!= 0` when it makes the code > clearer, but that's pretty rare. > > -- > ~Ethan~ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Thu Mar 6 22:37:31 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 13:37:31 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> Message-ID: On Thursday, March 6, 2014 6:36:46 AM UTC-6, Stefan Krah wrote: > > > As I understand, you are suggesting some kind of number system with > symbolic representations that can be converted to decimal if needed. > > The topic is so vast that the only chance of it happening is for > someone to provide an implementation on PyPI and see if people > like it. There are packages for symbolic mathematics like sympy, > perhaps that is a start. Yes, that is correct (in a way). I will respond to this better when I respond to Guido, so be sure to read that post. > > Regarding decimal literals: > > Possible in 3.x, but it would require some investigation if > people really want arbitrary precision arithmetic by default > rather than e.g. IEEE Decimal64. > Good. Dialogue is a good thing. Looking forward to it. Regarding decimal floats by default: > > Perhaps in 4.0, but IMO only with *full* backing by the large SciPy > and NumPy communities. My guess is that it's not going to happen, not > in the least because the literature for floating point algorithms > (with proofs!) has an overwhelming focus on binary floating point. > I know. Again, when I respond to Guido I'll address this a bit. Thanks Stefan, I appreciate your inputs, and your work... keep it up! marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Fri Mar 7 00:12:55 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 07 Mar 2014 12:12:55 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <6ED9830A-678A-445C-9C29-FC6A74B3F569@yahoo.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <6ED9830A-678A-445C-9C29-FC6A74B3F569@yahoo.com> Message-ID: <531900F7.1090101@canterbury.ac.nz> Andrew Barnert wrote: > I agree with Stefan here. Treating midnight as zero is not at all baffling. > There's a reason modular arithmetic is taught to kids as "clock arithmetic", I still say this is confusing times with timedeltas. It makes no conceptual sense to add two times of day together. You can only make it work if you abuse one type to mean two different things. We keep datetimes and timedeltas clearly separated. Why shouldn't we do the same for times of day? -- Greg From greg.ewing at canterbury.ac.nz Fri Mar 7 00:48:06 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 07 Mar 2014 12:48:06 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> Message-ID: <53190936.6030608@canterbury.ac.nz> Terry Reedy wrote: > What I find baffling and annoying is the endlessly > repeated false claim that there is nothing special about midnight, I think what people are really saying is that it's not special *enough* to be worth breaking people's intuition about the truthiness of structured data types in Python. Anyhow, it seems that the original motivation for the current truthiness behaviour isn't really "midnight is special", but rather "zero hours is special". In other words, if you turn your head sideways and view a time() object not as a time of day, but as a difference between two times of day, then a time() representing midnight morphs into a timedelta of zero hours, and it kind of sort of makes sense to treat that as false. If that's the intended interpretation of a time() object, the docs do a poor job of conveying it. A time() object is described as representing "a (local) time of day", not "an amount of time since midnight". The "local" even suggests that, if some midnight is to special, it would be *local* midnight -- but this is not the case for time() objects with a timezone. It seems to me that those claiming "midnight is special" are inventing a justification after the fact -- one that is not supported by the actual behaviour. Altogether, the whole thing seems to be a mess. -- Greg From greg.ewing at canterbury.ac.nz Fri Mar 7 00:51:50 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 07 Mar 2014 12:51:50 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306152936.3c990c46@anarchist.wooz.org> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <5318626F.5080203@btinternet.com> <20140306152936.3c990c46@anarchist.wooz.org> Message-ID: <53190A16.4020201@canterbury.ac.nz> Barry Warsaw wrote: > On Mar 06, 2014, at 11:56 AM, Rob Cliffe wrote: > >>Instances of existing code that would be broken by the change: 0 > > You can't know this because you can't audit all the Python code in the world. I think he means instances that have been pointed out so far in this discussion. -- Greg From cs at zip.com.au Fri Mar 7 00:59:21 2014 From: cs at zip.com.au (Cameron Simpson) Date: Fri, 7 Mar 2014 10:59:21 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140305120410.GY28804@ando> References: <20140305120410.GY28804@ando> Message-ID: <20140306235921.GA20568@cskk.homeip.net> Coming to this very late, but I was interested in the first thread... On 05Mar2014 23:04, Steven D'Aprano wrote: > On Wed, Mar 05, 2014 at 11:29:10AM +0000, Oscar Benjamin wrote: > > I don't agree with Mark's proposal in this thread but I would like to > > have decimal literals e.g. 1.23d, > > +1 on that. Although that will depend on how big a slowdown it causes to > Python's startup time. +1 on 123d decimal literals. > > and I would also use Fraction > > literals if available e.g. 1/3F. > > Out of curiosity, why F rather than f? Well, for me, +1 on 123f for "IEEE float" literals. i.e. the floats in play in Python right now. If ever we get ambiguity on how numbers are done, this may be useful in the transition or experiment phase. So of course "F" is reasonable for fractions. But how hard does that make the grammar? Because the parser now has to grab the entire "1/3F" to construct the fraction. You can't just stick it in the lexer at that point. Aside: Unless you do something obtuse, like make "3F" be a regular number with a special internal flag which is treated differently on the right hand side of a division operation: if encoutered, division now returns a Fraction instead of an int or float; this feels like something that could easily have nasty side effects. And, speaking personally, a big -1 on Mark's "abstract all the numbers". Like other posters, I agree that a number's internal implementation/representation affects its semantics. You can't just wave a wand and say "it should all be abstract"; there will be side-effects. You can wave a wand and say "from here on in this code, unadorned numbers make Decimals, not IEEE floats". I'm +0.5 on something like: from __future__ import decimal_floats to imply making Decimals from unadorned literals. "__future__" may be the wrong pseudomodule name. Not least, it makes testing the side-effects much easier because you can tweak a nice big chunk of code without editing it internally. > (By the way, I think it is somewhat amusing that Python not only has a > built-in complex type, but also *syntax* for creating complex numbers, > but no built-in support for exact rationals.) Harder to parse (see above), smaller use case maybe. It is not a bad idea, just not yet done... Cheers, -- Cameron Simpson The concept is interesting and well-formed, but in order to earn better than a 'C,' the idea must be feasible. --A Yale University management professor in response to Fred Smith's paper proposing reliable overnight delivery service. (Smith went on to found Federal Express Corp.) From greg.ewing at canterbury.ac.nz Fri Mar 7 01:04:56 2014 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 07 Mar 2014 13:04:56 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: <53190D28.50205@canterbury.ac.nz> Chris Angelico wrote: > Which is the earlier time: 18:00:00 Australia/Melbourne, or 03:00:00 > America/New_York? If you think of times of day as modular, then it doesn't make sense to ask whether one is earlier than another. But to clarify my position: It's okay to attach a timezone to a *time of day*. It's *not* okay to attach a timezone to a *difference* between times of day. This is one of the reasons it's imortant to keep the two concepts clearly separated, as we do for datetimes and timedeltas. Thinking that time(0, 0, 0) should be false seems to be a result of conflating the two. -- Greg From tim.peters at gmail.com Fri Mar 7 01:08:38 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 18:08:38 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53190936.6030608@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53190936.6030608@canterbury.ac.nz> Message-ID: [Greg Ewing] > ... > Altogether, the whole thing seems to be a mess. Although a mess that fits in a thimble that successfully hid in a dark corner unnoticed for a decade ;-) From rosuav at gmail.com Fri Mar 7 01:13:25 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 11:13:25 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53190D28.50205@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <53190D28.50205@canterbury.ac.nz> Message-ID: On Fri, Mar 7, 2014 at 11:04 AM, Greg Ewing wrote: > Chris Angelico wrote: >> >> Which is the earlier time: 18:00:00 Australia/Melbourne, or 03:00:00 >> America/New_York? > > > If you think of times of day as modular, then it doesn't > make sense to ask whether one is earlier than another. It should be possible to ask if they're equal, at least. Are they? > But to clarify my position: It's okay to attach a > timezone to a *time of day*. It's *not* okay to attach > a timezone to a *difference* between times of day. What operations can you do on a time-of-day-with-timezone? Give me some examples, and I'll show you, with the above two examples, how quirky that can be. ChrisA From rosuav at gmail.com Fri Mar 7 01:17:55 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 11:17:55 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140306235921.GA20568@cskk.homeip.net> References: <20140305120410.GY28804@ando> <20140306235921.GA20568@cskk.homeip.net> Message-ID: On Fri, Mar 7, 2014 at 10:59 AM, Cameron Simpson wrote: > Aside: Unless you do something obtuse, like make "3F" be a regular > number with a special internal flag which is treated differently > on the right hand side of a division operation: if encoutered, > division now returns a Fraction instead of an int or float; this > feels like something that could easily have nasty side effects. Thanks, now I can take the paper bag off my head. I'm not the only one! I thought exactly what you say here, that 3F would have to be a magical type of integer. But actually, all it has to be is Fraction(3) and everything will work perfectly. >>> 1/Fraction(3) Fraction(1, 3) ChrisA From harrismh777 at gmail.com Fri Mar 7 01:17:55 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 16:17:55 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> Message-ID: <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> On Thursday, March 6, 2014 4:41:08 PM UTC-6, Chris Angelico wrote: What does your proposed hierarchy offer that numbers.Number doesn't? > > I just had one more thought along this line; consider this: >>> from pdeclib import * >>> >>> s1=sqrt(2.01) >>> s1 Decimal('1.41774468787578244511883132198668766452744') >>> s2=sqrt(d(2.01)) >>> s2 Decimal('1.41774468787578252029556185427085779261123') >>> >>> s1**2 Decimal('2.00999999999999978683717927196994423866272') >>> s2**2 Decimal('2.01000000000000000000000000000000000000000') >>> >>> Which one is right, s1 or s2 ? Well, clearly s1 is wrong. And yet, s1 was coded by giving the system a normal human number, at a human level, and very innocently s1 is really badly broken but not immediately noticed until we try to square it... s2 on the other hand is correct, but we had to go through some hoops to make sure that the system received the correct type. The system should be able to make this determination without the user having to determine types. marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Fri Mar 7 01:20:48 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 19:20:48 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <53190D28.50205@canterbury.ac.nz> Message-ID: <9F5908A8-8B2B-4320-8CEE-B61F99483222@stufft.io> > On Mar 6, 2014, at 7:13 PM, Chris Angelico wrote: > >> On Fri, Mar 7, 2014 at 11:04 AM, Greg Ewing wrote: >> Chris Angelico wrote: >>> >>> Which is the earlier time: 18:00:00 Australia/Melbourne, or 03:00:00 >>> America/New_York? >> >> >> If you think of times of day as modular, then it doesn't >> make sense to ask whether one is earlier than another. > > It should be possible to ask if they're equal, at least. Are they? > >> But to clarify my position: It's okay to attach a >> timezone to a *time of day*. It's *not* okay to attach >> a timezone to a *difference* between times of day. > > What operations can you do on a time-of-day-with-timezone? Give me > some examples, and I'll show you, with the above two examples, how > quirky that can be. > It's not an operation but a time object with a timezone is perfect for representing an event which occurs everyday at 11:30 EST > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From rosuav at gmail.com Fri Mar 7 01:29:34 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 11:29:34 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <624af90f-50cd-4ac8-9401-f3023b2735f3@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <624af90f-50cd-4ac8-9401-f3023b2735f3@googlegroups.com> Message-ID: On Fri, Mar 7, 2014 at 10:58 AM, Mark H. Harris wrote: > But, it should not do this: > >>>> from pdeclib import * >>>> x=1 >>>> y=Decimal(.1) >>>> x+y > Decimal('1.10000000000000000555111512312578270211816') >>>> > > The policy hidden under the abstraction way down in the guts of the Class > hierarchy should make the decision to do this: > >>>> ====== RESTART ===== >>>> from pdeclib import * >>>> x=1 >>>> y=.1 >>>> >>>> def add_(x, y): > return d(x)+d(y) > >>>> add_(x, y) > Decimal('1.1') >>>> > > Please don't pick at this. The point is not the code or the syntax. The > point > is that the policy in a correctly related Class hierarchy can handle > somebody > asking the system to add a 1.23b with a 1.23d , and if setup correctly, > will > just work. If you had a literal syntax "0.1d" meaning Decimal("0.1"), this would be solved. The only reason your code seems to work is that you're rounding off your binary floats instead of using them with as much accuracy as they have. You're deceiving yourself that str(float('0.1')) seems to round-trip, and therefore that's the right way to get a decimal value from a float. But with floats completely out of the picture, there's no need to do any of this. >>> x=1 >>> y=Decimal(".1") # y=.1d >>> x+y Decimal('1.1') So... I'm +1 for adding a literal syntax for decimals. +1 for adding a stating-the-default for floats (do it straight away, then code that uses it can be backported all the way even when there's a change of default). +0.5 for adding a syntax for fractions; support in principle but the devil's in the details. -1 for trying to unify everything. ChrisA From python at mrabarnett.plus.com Fri Mar 7 01:32:16 2014 From: python at mrabarnett.plus.com (MRAB) Date: Fri, 07 Mar 2014 00:32:16 +0000 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140306235921.GA20568@cskk.homeip.net> References: <20140305120410.GY28804@ando> <20140306235921.GA20568@cskk.homeip.net> Message-ID: <53191390.7050804@mrabarnett.plus.com> On 2014-03-06 23:59, Cameron Simpson wrote: > Coming to this very late, but I was interested in the first thread... > > On 05Mar2014 23:04, Steven D'Aprano wrote: >> On Wed, Mar 05, 2014 at 11:29:10AM +0000, Oscar Benjamin wrote: >> > I don't agree with Mark's proposal in this thread but I would like to >> > have decimal literals e.g. 1.23d, >> >> +1 on that. Although that will depend on how big a slowdown it causes to >> Python's startup time. > > +1 on 123d decimal literals. > >> > and I would also use Fraction >> > literals if available e.g. 1/3F. >> >> Out of curiosity, why F rather than f? > > Well, for me, +1 on 123f for "IEEE float" literals. i.e. the floats > in play in Python right now. > > If ever we get ambiguity on how numbers are done, this may be useful > in the transition or experiment phase. > > So of course "F" is reasonable for fractions. But how hard does > that make the grammar? Because the parser now has to grab the entire > "1/3F" to construct the fraction. You can't just stick it in the lexer > at that point. > I think it would be confusing if there were "f" for "float" and "F" for "fraction". How about "r" for "rationals"? > Aside: Unless you do something obtuse, like make "3F" be a regular > number with a special internal flag which is treated differently > on the right hand side of a division operation: if encoutered, > division now returns a Fraction instead of an int or float; this > feels like something that could easily have nasty side effects. > > And, speaking personally, a big -1 on Mark's "abstract all the > numbers". Like other posters, I agree that a number's internal > implementation/representation affects its semantics. You can't just > wave a wand and say "it should all be abstract"; there will be > side-effects. > > You can wave a wand and say "from here on in this code, unadorned > numbers make Decimals, not IEEE floats". > > I'm +0.5 on something like: > > from __future__ import decimal_floats > > to imply making Decimals from unadorned literals. "__future__" may > be the wrong pseudomodule name. > > Not least, it makes testing the side-effects much easier because you > can tweak a nice big chunk of code without editing it internally. > >> (By the way, I think it is somewhat amusing that Python not only has a >> built-in complex type, but also *syntax* for creating complex numbers, >> but no built-in support for exact rationals.) > Python doesn't have a syntax for creating complex numbers; it has a syntax for creating imaginary numbers. > Harder to parse (see above), smaller use case maybe. It is not a > bad idea, just not yet done... > From rosuav at gmail.com Fri Mar 7 01:38:34 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 11:38:34 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> Message-ID: On Fri, Mar 7, 2014 at 11:17 AM, Mark H. Harris wrote: > Well, clearly s1 is wrong. And yet, s1 was coded by giving the system a > normal > human number, at a human level, and very innocently s1 is really badly > broken > but not immediately noticed until we try to square it... > > s2 on the other hand is correct, but we had to go through some hoops > to make sure that the system received the correct type. The system should > be able to make this determination without the user having to determine > types. Once again, the problem occurs only because you're using a float literal, and 2.01 can't perfectly round-trip. >>> Decimal(2.01) Decimal('2.0099999999999997868371792719699442386627197265625') That's pretty much the value you had (I have a few more digits there, the square rooting and squaring probably cost some accuracy), so I'd say Decimal correctly round-tripped. The problem is the conversion from string (source code) to float to Decimal. You think that str()ing a float gives you a better round-trip, but that works only because you're using relatively small numbers. Hmm. Is the rounding done by float.__str__() an attractive nuisance? Would it be better to show exactly what's stored, if only to remove the temptation to treat str(f) as "more correct" than f? ChrisA From rosuav at gmail.com Fri Mar 7 01:45:33 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 11:45:33 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <53191390.7050804@mrabarnett.plus.com> References: <20140305120410.GY28804@ando> <20140306235921.GA20568@cskk.homeip.net> <53191390.7050804@mrabarnett.plus.com> Message-ID: On Fri, Mar 7, 2014 at 11:32 AM, MRAB wrote: > I think it would be confusing if there were "f" for "float" and "F" for > "fraction". How about "r" for "rationals"? Since the string prefixes are all case insensitive, I'd be very much surprised if f and F did different things. > Python doesn't have a syntax for creating complex numbers; it > has a syntax for creating imaginary numbers. >>> type(1j) ChrisA From rob.cliffe at btinternet.com Fri Mar 7 01:44:00 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Fri, 07 Mar 2014 00:44:00 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53190A16.4020201@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <5318626F.5080203@btinternet.com> <20140306152936.3c990c46@anarchist.wooz.org> <53190A16.4020201@canterbury.ac.nz> Message-ID: <53191650.5020208@btinternet.com> On 06/03/2014 23:51, Greg Ewing wrote: > Barry Warsaw wrote: >> On Mar 06, 2014, at 11:56 AM, Rob Cliffe wrote: >> >>> Instances of existing code that would be broken by the change: 0 >> >> You can't know this because you can't audit all the Python code in >> the world. > > I think he means instances that have been pointed out > so far in this discussion. > Quite. If you read my post, I was initialising totals. I invited the universe to add to them. From harrismh777 at gmail.com Fri Mar 7 00:58:11 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 15:58:11 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> Message-ID: <624af90f-50cd-4ac8-9401-f3023b2735f3@googlegroups.com> On Thursday, March 6, 2014 4:41:08 PM UTC-6, Chris Angelico wrote: > > What does your proposed hierarchy offer that numbers.Number doesn't? > > hi Chris, numbers.Number is the right concept, but not the correct relationship... in sixty's vernacular, its the right hoo hoo but the wrong tah tah... Here is the numbers.Number hierarchy: CLASSES builtins.object Number Complex Real Rational Integral Compare numbers.Number with my proposal. (I am not wanting to go into semantics at this point, but the numbers.Number model is not unified and has problems. If it were ok, we would not be having this discussion. ) The age old question, "How's that working for you?" Well, not too well. Chris, its not just the virtual function table, its also operator overloading, and its policy handled by (AI) that intelligently decides what to do if someone tries to add a real_b with a real_d. But, it should not do this: >>> from pdeclib import * >>> x=1 >>> y=Decimal(.1) >>> x+y Decimal('1.10000000000000000555111512312578270211816') >>> The policy hidden under the abstraction way down in the guts of the Class hierarchy should make the decision to do this: >>> ====== RESTART ===== >>> from pdeclib import * >>> x=1 >>> y=.1 >>> >>> def add_(x, y): return d(x)+d(y) >>> add_(x, y) Decimal('1.1') >>> Please don't pick at this. The point is not the code or the syntax. The point is that the policy in a correctly related Class hierarchy can handle somebody asking the system to add a 1.23b with a 1.23d , and if setup correctly, will just work. The idea is to unify numbers, so that efficient intelligent processing can occur without "types" or "limits". I'll say more later... after we see how folks respond. marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip at pobox.com Fri Mar 7 01:48:30 2014 From: skip at pobox.com (Skip Montanaro) Date: Thu, 6 Mar 2014 18:48:30 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53190936.6030608@canterbury.ac.nz> Message-ID: > Although a mess that fits in a thimble that successfully hid in a dark > corner unnoticed for a decade ;-) +1 QOTW... Skip -------------- next part -------------- An HTML attachment was scrubbed... URL: From anikom15 at gmail.com Fri Mar 7 02:03:58 2014 From: anikom15 at gmail.com (=?iso-8859-1?Q?Westley_Mart=EDnez?=) Date: Thu, 6 Mar 2014 17:03:58 -0800 Subject: [Python-ideas] Add "goto fail" to Python? In-Reply-To: References: Message-ID: <003601cf39a1$21aa23b0$64fe6b10$@gmail.com> Spaghetti? Seriously though, I don't see how this is any different than a regular goto. What's forcing users to use this only for errors? I understand that error- handling is what goto is most useful for in C, but if Python already has a simple and robust method for handling errors, what is goto going to add? > -----Original Message----- > From: Python-ideas [mailto:python-ideas-bounces+anikom15=gmail.com at python.org] > On Behalf Of Yann Kaiser > Sent: Thursday, March 06, 2014 1:42 PM > To: Georg Brandl > Cc: python-ideas > Subject: Re: [Python-ideas] Add "goto fail" to Python? > > What does this add that we can't do with control flow tools such as > try..finally or context managers? > > On 6 March 2014 22:36, Georg Brandl wrote: > > Am 06.03.2014 11:11, schrieb Nick Coghlan: > >> > >> On 6 Mar 2014 13:55, "Sturla Molden" > >> >> > wrote: > >>> > >>> "goto fail" is a well-known error handling mechanism in open source > software, > >> widely reputed for its robusteness: > >>> > >>> > >> http://opensource.apple.com/source/Security/Security- > 55471/libsecurity_ssl/lib/sslKeyExchange.c > >>> > >>> > >> > https://www.gitorious.org/gnutls/gnutls/source/6aa26f78150ccbdf0aec1878a41c17c > 41d358a3b:lib/x509/verify.c > >>> > >>> I believe Python needs to add support for this superior paradigm. > >> > >> Unfortunately, we can't throw stones about those, since we currently have > >> hostname matching off by default and expect developers to turn it on. > > > > And on another level, we use the same error handling method in C code > > (which is not bad per se of course). The literal code "goto fail;" actually > > occurs about 200 times in the CPython sources :) > > > > Aaand... we also don't have a policy to always use braces... > > > > Georg > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas at python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From steve at pearwood.info Fri Mar 7 02:12:29 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 7 Mar 2014 12:12:29 +1100 Subject: [Python-ideas] Add "goto fail" to Python? In-Reply-To: <003601cf39a1$21aa23b0$64fe6b10$@gmail.com> References: <003601cf39a1$21aa23b0$64fe6b10$@gmail.com> Message-ID: <20140307011229.GM28804@ando> Guys, Sturla's original email was quite subtle, but you may have missed that he is proposing this as a joke PEP for April Fools Day, a bit like the introduction of GOTO or the retirement of Guido: https://mail.python.org/pipermail/python-announce-list/2004-April/002982.html http://legacy.python.org/dev/peps/pep-0401/ As a joke, it pokes fun at Apple's recent "goto fail" security breach. Unfortunately the Python C source code apparently uses exactly the same "goto fail" idiom, although hopefully not as poorly as Apple did. -- Steven From tim.peters at gmail.com Fri Mar 7 02:19:28 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 19:19:28 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5318F8F2.5010209@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: [Tim] >> The only difference between time and timedelta is in implementation >> details. [Greg] > Only if you define it that way. Sorry, don't know what you mean there. But then I don't draw much distinction between "defining" something and "implementation details". `time` and `timedelta` objects are both exact values with microsecond resolution; the operations each supports is a matter of definition + implementation. > To my way of thinking, a time-of-day is like a mod-24-hour datetime, > not a mod-24-hour timedelta. Heh. I'll ponder that and see if I can make sense of it tomorrow ;-) > It seems you're thinking of it as a mod-24-hour timedelta. No. I'm saying: (1) it _can_ be thought of that way; and, (2) while that's not how `time` was initially released, there was some effort not to _preclude_ later extensions viewing it that way. As is, the datetime module offers no obvious solution to problems like "the clock reads 6:43 now; what will it read 57 minutes from now?". `time` objects support no arithmetic of any kind. The world wouldn't really collapse if time(6, 43) + time(minute=57), or if time(6, 43) + timedelta(minutes=57), didn't blow up but returned the obvious result as a time object. > Given that, I can see why you think that it's bizarre > to attach a timezone to one. In fact, I'd say if that's > really how a time object is meant to be interpreted, > they shouldn't even be *allowed* to have a timezone, > any more than a timedelta can. No, it's bizarre to attach a timezone to a time object because most tzinfo subclasses don't - and can't - know what to return for the UTC offset in the absence of - at least - month and day info too. Hour, minute, second and microsecond aren't usually enough to determine whether "daylight time" is in effect, and most tzinfo subclasses do attempt to model daylight time. And because daylight time is a political conceit, most tzinfo subclasses also need year info. That has nothing to do with whether times are viewed abstractly, concretely, etc - it has to do with that time zones generally aren't _defined_ in terms of isolated time-of-day info. It's 7:13 PM in US Central. Is that daylight (CDT) or standard (CST) time? It's impossible to answer. What's the corresponding UTC time? Ditto. While time objects don't support arithmetic they do support all comparison operators. And this is another case where the docs explain _how_ comparison of aware time objects works, but a close reading reveals that the result generally makes no sense. In effect, the time objects are converted to UTC before comparison, but correct conversion to UTC is generally impossible without month, day and year info too. A user intimately familiar with how all this works can define tzinfo subclasses that make time object conversions with the kinds of errors they prefer. but that too is ... bizarre. > In any case, I don't see how this interpretation > justifies the truthiness behaviour with timezones. > From my reading of the docs, the *intention* seems > to be for midnight UTC to be false and all other > times to be true. I would never have suspected the > actual behaviour with negative offsets, which looks > like an outright bug to me. Or is there some reason > for it that I'm not seeing? Truthiness would become useful if time() (i.e., the naive time object with all 0 fields) acted as an additive identity in some extension that allowed time object addition. That's all. I put more thought into writing that sentence than into what truthiness of aware time objects returned - and I bet it shows ;-) If more thought had gone into it, and assuming it remained the case that time objects had to support tzinfo members (despite that doing so makes little sense), and assuming it remained the case that we wanted to keep the _possibility_ of later time arithmetic open, I'd amend the truthiness rules to that False was equivalent to that the naive time converted to minutes minus the UTC offset (or 0 if tzinfo=None) is 0 mod 24*60. Which would be a long way of saying "midnight UTC", but a better way because: (1) again, it's not usually possible to do _correct_ conversion of a time object to UTC; and, (2) it's not "midnight" that's important to an additive identity, it's "0". From donald at stufft.io Fri Mar 7 02:25:10 2014 From: donald at stufft.io (Donald Stufft) Date: Thu, 6 Mar 2014 20:25:10 -0500 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: On Mar 6, 2014, at 8:19 PM, Tim Peters wrote: > No, it's bizarre to attach a timezone to a time object because most > tzinfo subclasses don't - and can't - know what to return for the UTC > offset in the absence of - at least - month and day info too. It?s completely reasonable to attach a timezone to a time object. If I schedule an event in a calendar for Mar 7th, at 12pm Eastern, then absolutely that should be represented as a date time. But what if I want to schedule an event that occurs every day at 11:30AM EST? There?s no date associated with it (except an infinite set, or the span of my life I suppose!) it?s just 11:30AM EST. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kaiser.yann at gmail.com Fri Mar 7 02:32:10 2014 From: kaiser.yann at gmail.com (Yann Kaiser) Date: Fri, 7 Mar 2014 02:32:10 +0100 Subject: [Python-ideas] Add "goto fail" to Python? In-Reply-To: <20140307011229.GM28804@ando> References: <003601cf39a1$21aa23b0$64fe6b10$@gmail.com> <20140307011229.GM28804@ando> Message-ID: Ah, my bad, I had received this message an hour before midnight in my timezone so my brain shorted out. Isn't this more of an insignificant-whitespace issue? We need more significant whitespace. On 7 March 2014 02:12, Steven D'Aprano wrote: > Guys, > > Sturla's original email was quite subtle, but you may have missed that > he is proposing this as a joke PEP for April Fools Day, a bit like the > introduction of GOTO or the retirement of Guido: > > https://mail.python.org/pipermail/python-announce-list/2004-April/002982.html > > http://legacy.python.org/dev/peps/pep-0401/ > > As a joke, it pokes fun at Apple's recent "goto fail" security breach. > Unfortunately the Python C source code apparently uses exactly the same > "goto fail" idiom, although hopefully not as poorly as Apple did. > > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From rosuav at gmail.com Fri Mar 7 02:34:37 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 12:34:37 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: On Fri, Mar 7, 2014 at 12:25 PM, Donald Stufft wrote: > If I schedule an event in a calendar for Mar 7th, at 12pm Eastern, then > absolutely that should be represented as a date time. But what if I want > to schedule an event that occurs every day at 11:30AM EST? There?s > no date associated with it (except an infinite set, or the span of my life > I suppose!) it?s just 11:30AM EST. Repeating events need their own handling. Maybe it's safe to use 11:30AM local time, but what if you specify 1:30AM America/New_York? How can you render that onto a calendar? There'll be times when it breaks - one day a year when it's ambiguous, and one day a year when it doesn't exist. How can you work with a time that might not exist? ChrisA From abarnert at yahoo.com Fri Mar 7 02:32:45 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 17:32:45 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> Message-ID: <1394155965.8575.YahooMailNeo@web181003.mail.ne1.yahoo.com> From: Mark H. Harris Sent: Thursday, March 6, 2014 2:23 PM > Here is the Class hierarchy I am proposing: > >Number >? ? ? ?PythonNumber >? ? ? ? ? ? ? Decimal >? ? ? ? ? ? ? ? ? ? ?Real ? ? ? ? <======= this is the ?default >? ? ? ? ? ? ? BinaryIEEE85 >? ? ? ? ? ? ? ? ? ? ?Real_b >? ? ? ? ? ? ? ?&c (...) ? omitted for clarity >? ? ? ? ? ? ? ?Complex >? ? ? ? ? ? ? ? ? ? ? ?Quaternion >? ? ? ? ? ? ? ? Rational >? ? ? ? ? ? ? ? ? ? ? ? Fraction >? ? ? ? ? ? ? ? &c-------------------------------------------------- This kind of hierarchy doesn't work.?Most importantly,?you can have complex decimal floats and complex binary floats. This is why complex is a class template rather than a class in C++.?Also, this is ignoring the numerical tower?rationals are a specialization of reals, just as floats are. >? ? ? ?Well, there it is. ? The idea is that any function or method that takes a ?Number?reference >or a ?PythonNumber ?reference does not have to interrogate what type of Number?it is... it just >works (why?) glad you asked, because of polymorphism and a three pointer hop down a virtual >function table! 99% of the time you don't need these abstract base classes at all, because duck typing and operator overloading. But when you need it, it's already there, and does everything you're asking for. See below. >? ? ? ?If a function or method gets a Number parm in as in ? ?method(num) ? ?then to get the pretty >print representation of the number ?is simply ? ?num.pretty_print(), ? or to get an evaluation? >of the number is ? num.eval(), or to get the string rep of the number is ?num.str()... We already have the first and third as str() and repr(), and I'm not sure what the second is supposed to do. What does evaluating a number return other than the number itself? >? ? ? ?Python at present is disjointed when it comes to number as a concept. In my view numbers? >need to be objects, and the Class hierarchy (see my simplified version above) needs to unify numbers >across the python boards (so to speak) so that "types" are only important to the implementors, and >so that adding new "types" is easy, concise, and coherent.? This is all just plainly false. Numbers are objects. There is a hierarchy of abstract base classes for them?done correctly?in the numbers module. And they handle everything you're asking for, except for one thing:?There are no ABCs to distinguish binary vs. decimal floats. But I doubt that's useful for anything. What kind of code can you imagine that does need to distinguish, say, float vs. decimal.Decimal, but doesn't need to distinguish decimal.Decimal from mylib.MyDecimal? They're both inexact floating-point representations of reals. If the motivation for your whole idea is that you want a class hierarchy like the one in the numbers module but you didn't know that it already existed, then we're done. From tim.peters at gmail.com Fri Mar 7 02:36:29 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 19:36:29 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: [Donald Stufft] > It's completely reasonable to attach a timezone to a time object. > > If I schedule an event in a calendar for Mar 7th, at 12pm Eastern, then > absolutely that should be represented as a date time. But what if I want > to schedule an event that occurs every day at 11:30AM EST? There's > no date associated with it (except an infinite set, or the span of my life > I suppose!) it's just 11:30AM EST. That's a stretch, Donald. Can you present an example of such an event? For someone living on the US East Coast, some days that event would occur when their clock said 11:30AM, and on other days when it occurred at - figure it out! - 10:30AM or 12:30PM? Depending on whether, in the real world, daylight time wasn't or was in effect. In any case, you keep ignoring the context of what's written to present some caricature to shoot down. Here: [Tim] > No, it's bizarre to attach a timezone to a time object because most > tzinfo subclasses don't - and can't - know what to return for the UTC > offset in the absence of - at least - month and day info too. You didn't see the "most"? Or the later repeated elaborations that most tzinfo subclasses (in real life) _do_ attempt to model daylight time? An EST tzinfo subclass is a fixed-offset subclass, making no attempt to model daylight time. Those aren't the problem. But fixed-offset tzinfo subclasses are relatively rare. From tim.peters at gmail.com Fri Mar 7 02:51:48 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 19:51:48 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: [Donald Stufft] >> If I schedule an event in a calendar for Mar 7th, at 12pm Eastern, then >> absolutely that should be represented as a date time. But what if I want >> to schedule an event that occurs every day at 11:30AM EST? There's >> no date associated with it (except an infinite set, or the span of my life >> I suppose!) it's just 11:30AM EST. [Chris Angelico ] > Repeating events need their own handling. Maybe it's safe to use > 11:30AM local time, but what if you specify 1:30AM America/New_York? > How can you render that onto a calendar? There'll be times when it > breaks - one day a year when it's ambiguous, and one day a year when > it doesn't exist. How can you work with a time that might not exist? Filling in the blanks, I presume that Donald's "EST" is what the docs call a "fixed-offset" tzinfo subclass: it represents a fixed offset from UTC. It's what a US East Coast clock would look like if the idiotic ;-) "daylight saving" rules were repealed, and the East Coast stayed on "standard" time forever. Such classes are utterly problem-free. No ambiguities, no clock leaping ahead or leaping back, no "missing" hours, no "duplicate" hours, they just march on forever in perfect lockstep with UTC. Alas, such classes are also rare. From abarnert at yahoo.com Fri Mar 7 02:52:38 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 17:52:38 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <624af90f-50cd-4ac8-9401-f3023b2735f3@googlegroups.com> Message-ID: <1394157158.94258.YahooMailNeo@web181006.mail.ne1.yahoo.com> From: Chris Angelico Sent: Thursday, March 6, 2014 4:29 PM > So... I'm +1 for adding a literal syntax for decimals. +1 for adding a > stating-the-default for floats (do it straight away, then code that > uses it can be backported all the way even when there's a change of > default). This makes sense if you also add an optional suffix for binary floats at the same time. Otherwise, it would be confusing to talk about the "default" when there's no way to make it explicit, and it would delay any potential change of the default by at least one version, if not more. Of course there's a lot of room for bikeshedding the suffix. The "f" suffix from C implies 32-bit float as opposed to 64-bit double, which is obviously wrong. The "d" suffix from C might be confusing as distinguishing "binary, not decimal". Maybe "b"? > +0.5 for adding a syntax for fractions; support in principle > but the devil's in the details. What details, other than bikeshedding the exact suffix? If 3r == fraction.Fraction(3), we're done, right? From breamoreboy at yahoo.co.uk Fri Mar 7 02:51:04 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Fri, 07 Mar 2014 01:51:04 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: On 07/03/2014 01:25, Donald Stufft wrote: > > On Mar 6, 2014, at 8:19 PM, Tim Peters wrote: > >> No, it's bizarre to attach a timezone to a time object because most >> tzinfo subclasses don't - and can't - know what to return for the UTC >> offset in the absence of - at least - month and day info too. > > It?s completely reasonable to attach a timezone to a time object. > > If I schedule an event in a calendar for Mar 7th, at 12pm Eastern, then > absolutely that should be represented as a date time. But what if I want > to schedule an event that occurs every day at 11:30AM EST? There?s > no date associated with it (except an infinite set, or the span of my life > I suppose!) it?s just 11:30AM EST. > > ----------------- > Donald Stufft Hum, thinking out loud as I don't know the answer. Assume that for your sins in a past life at 11:30AM EST every day you have to talk to me. How do I set my calendar up to have an infinite set of dates, I've never known an application let me do this? How do we sync our calendars so that your EST or (I guess) EDT ties in with my GMT or BST? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From guido at python.org Fri Mar 7 03:09:02 2014 From: guido at python.org (Guido van Rossum) Date: Thu, 6 Mar 2014 18:09:02 -0800 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> Message-ID: Mark, it feels like you do not understand Python well enough to be able to make sweeping proposals about its reform. Hopefully the responses you are getting will help you make more informed proposals in the future. On Thu, Mar 6, 2014 at 2:23 PM, Mark H. Harris wrote: > > > On Thursday, March 6, 2014 11:48:53 AM UTC-6, Guido van Rossum wrote: > {snip} > > hi Guido, thanks for your responses, your candor, and your kindness; I > think > dialogue will work, and I promise to keep the rhetoric to a bare minimum, > if at all. :) > > There really are only two questions I am going to try to answer here, and > some of > the answer goes back to Stefan's (and others) questions as well, so I hope > its helpful. > > > >> So, by context you really seem to be referring to some specific state of >> the program. Perhaps you are even talking about extending the existing >> notion of numeric context used by Python's Decimal type. But it's not very >> clear because "you change the context" is also a common term for changing >> the topic of a discussion. >> > > This is what I mean by "context," for this entire discussion, > mostly having to do with > Decimal and the "context manager" and these two lines: > > getcontext() > > with localcontext(ctx=None) as context_manager > > Allow me to back up a bit... the pdeclib module was not difficult > for me because of the > mathematics (no brag) I can code transcendental functions in my sleep. The > hard part of > that project last week was coming to grips with the context manger, and > the parameterization > of context attributes in the Decimal class. Back in the day when I did > this work for Rexx at IBM > I used NUMERIC DIGITS and NUMERIC FUZZ to emulate (in a crude way) what > Decimal is > doing correctly with its context, with the context manager. I credit Oscar > Benjamin for helping > me get up to speed with this concept (and I am so glad he did too, because > its key for this > entire discussion. > > Before we go on, allow me to explain my italics of *Number *and > *PythonNumber.* These are > each an abstract base class. They are a class that is never instantiated, > but from which all > other "numbers" are derived as objects. (more below) > > >> I'm sorry, but I am *still* unsure about what you mean by "context". >> Python does not need a context object to switch between complex and real >> number processing -- it's all done through operator overloading. >> > > (more on this below, but I am thinking beyond overloading/ > actually, virtual functions and templates) > > >> Actually, modern Python is considered object-oriented. >> > > Thank you. This has everything to do with this discussion, but > allow me to take a humorous > break and relate an anecdote... I have had numerous discussions with T.R. > and C.A and S.D. and > others where in the end python was object based. Ha! Nope, you have > seen it right here, the > BDfL says its "object oriented," and that's the end of the argument! > (ok, tiny rhetoric) > >> >> Unifying the >>> number system on a computer does not have to be grounded in paradigms >>> that serviced the >>> industry (and academy) for the past 40 years; >>> >> {snip} > >> >> Now you've got a specific proposal and we can discuss pros and cons. This >> is a topic that comes up occasionally and it is indeed a pretty interesting >> trade-off. I suspect the large (and fast-growing) SciPy community would >> prefer to keep binary floating point, because that's what their libraries >> written in Fortran or C++ want, and extra binary/decimal conversions at the >> boundaries would just slow things down. But I'm really speculating here -- >> maybe they don't need high-performance conversion between binary and >> decimal, since (perhaps) they may do their bulk I/O in C++ anyway. Or maybe >> it varies per application. >> > > Here is the main response for this discussion, and I will endeavor > to keep the > rhetoric down, I promise. > This may even be easier to accomplish in 3.x without breaking > anyone, or any third party software either; depends > > In my view numbers are objects (like circles, squares and > triangles; in polymorphism discussions). > Numbers are nothing more than objects which have "contexts" just like > circles and squares and triangles > are nothing more than objects that have "contexts". In the following > discussion think in terms of object > oriented (as in Grady Booch) rather than any specific language--- and > certainly not python syntax. um, > think C++ for now, if you must think of any. A *Number *is an abstract > base class with "context" attributes > and pure virtual functions--- it will never be instantiated---and *PythonNumber > *will derive from that; also > an abstract base class. Here is the Class hierarchy I am proposing: > > *Number* > > *PythonNumber* > > Decimal > > Real <======= this is the default > > BinaryIEEE85 > > Real_b > > &c (...) omitted for clarity > > Complex > > Quaternion > > Rational > > Fraction > > &c-------------------------------------------------- > > Well, there it is. The idea is that any function or method that > takes a *Number* reference > or a *PythonNumber *reference does not have to interrogate what type of > *Number* it is... it just > works (why?) glad you asked, because of polymorphism and a three pointer > hop down a virtual > function table! > If a function or method gets a *Number *parm in as in > method(num) then to get the pretty > print representation of the number is simply num.pretty_print(), or > to get an evaluation > of the number is num.eval(), or to get the string rep of the number is > num.str()... and on and on. > The point is that other parts of the system no longer need to know what > "type" of number object > it is, the right code gets called because of virtual functions, operator > overloading, and the beautiful > virtual function table (all under the covers, not MAGIC, but polymorphism). > Python at present is disjointed when it comes to number as a > concept. In my view numbers > need to be objects, and the Class hierarchy (see my simplified version > above) needs to unify numbers > across the python boards (so to speak) so that "types" are only important > to the implementors, and > so that adding new "types" is easy, concise, and coherent. > > I realize that this suggestion is over the top in terms of size and > weight (Stefan's concern above). > But not really, when you think of conceptualizing the unification of > numbers under *Number *and > *PythonNumber *. There may be other kinds of numbers too, besides > these... like maybe *GmpyNumber* > of *BC_Number*, or others. > > The bottom line is that we have an object oriented language in > front of us that has the > software engineering advantages which would allow this kind of hierarchy > and conceptualization > of a unified number system. Let's leverage our technology for mutual > advantage across python > communities? > > Thanks for your consideration, > > Sincerely, > > Kind regards, > > marcus > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Fri Mar 7 03:09:23 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 18:09:23 -0800 (PST) Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: <1394158163.96645.YahooMailNeo@web181005.mail.ne1.yahoo.com> From: Tim Peters Sent: Thursday, March 6, 2014 5:19 PM > No, it's bizarre to attach a timezone to a time object because most > tzinfo subclasses don't - and can't - know what to return for the UTC > offset in the absence of - at least - month and day info too.? Hour, > minute, second and microsecond aren't usually enough to determine > whether "daylight time" is in effect, and most tzinfo subclasses do > attempt to model daylight time.? And because daylight time is a > political conceit, most tzinfo subclasses also need year info.? That > has nothing to do with whether times are viewed abstractly, > concretely, etc - it has to do with that time zones generally aren't > _defined_ in terms of isolated time-of-day info.? It's 7:13 PM in US > Central.? Is that daylight (CDT) or standard (CST) time?? It's > impossible to answer.? What's the corresponding UTC time?? Ditto. Well, a time in Central is useless, but a time in CDT or CST is not, and you can design a library that's smart enough to give you a CDT or CST (as appropriate) time from a Central datetime. However, I built something like that in a C++ datetime library, and we never found a use for it anywhere. Instead, we just carried the full datetime or recurring-datetime object around as late as possible, and rendered to naive times for display. From greg.ewing at canterbury.ac.nz Fri Mar 7 03:12:36 2014 From: greg.ewing at canterbury.ac.nz (Greg) Date: Fri, 07 Mar 2014 15:12:36 +1300 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <53190D28.50205@canterbury.ac.nz> Message-ID: <53192B14.4070304@canterbury.ac.nz> On 7/03/2014 1:13 p.m., Chris Angelico wrote: > What operations can you do on a time-of-day-with-timezone? Give me > some examples, and I'll show you, with the above two examples, how > quirky that can be. I'm not particularly attached to the idea of times of day with timezones; I wouldn't mind if they didn't exist. The main point is that they definitely don't make sense for time differences. An hour in New York is the same length as an hour in Melbourne, on any day of the year, as far as I know. (At least in modern times. It seems the Romans divided daytime and nighttime into 12 equal hours each, so that the length of an hour varied with latitude and time of year, and daytime hours were a different length from nighttime hours! I hate to think what a Python datetime module would have looked like back then.) -- Greg From python at mrabarnett.plus.com Fri Mar 7 03:12:59 2014 From: python at mrabarnett.plus.com (MRAB) Date: Fri, 07 Mar 2014 02:12:59 +0000 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <1394157158.94258.YahooMailNeo@web181006.mail.ne1.yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <624af90f-50cd-4ac8-9401-f3023b2735f3@googlegroups.com> <1394157158.94258.YahooMailNeo@web181006.mail.ne1.yahoo.com> Message-ID: <53192B2B.1010205@mrabarnett.plus.com> On 2014-03-07 01:52, Andrew Barnert wrote: > From: Chris Angelico > > Sent: Thursday, March 6, 2014 4:29 PM > > >> So... I'm +1 for adding a literal syntax for decimals. +1 for >> adding a stating-the-default for floats (do it straight away, then >> code that uses it can be backported all the way even when there's a >> change of default). > > This makes sense if you also add an optional suffix for binary floats > at the same time. Otherwise, it would be confusing to talk about the > "default" when there's no way to make it explicit, and it would delay > any potential change of the default by at least one version, if not > more. > > Of course there's a lot of room for bikeshedding the suffix. The "f" > suffix from C implies 32-bit float as opposed to 64-bit double, which > is obviously wrong. The "d" suffix from C might be confusing as > distinguishing "binary, not decimal". Maybe "b"? > Calling the floating-point class "float" implies 32-bit float as opposed to 64-bit double, doesn't it? :-) >> +0.5 for adding a syntax for fractions; support in principle but >> the devil's in the details. > > What details, other than bikeshedding the exact suffix? If 3r == > fraction.Fraction(3), we're done, right? > From greg.ewing at canterbury.ac.nz Fri Mar 7 03:16:13 2014 From: greg.ewing at canterbury.ac.nz (Greg) Date: Fri, 07 Mar 2014 15:16:13 +1300 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <20140305120410.GY28804@ando> <20140306235921.GA20568@cskk.homeip.net> Message-ID: <53192BED.6090909@canterbury.ac.nz> On 7/03/2014 1:17 p.m., Chris Angelico wrote: > On Fri, Mar 7, 2014 at 10:59 AM, Cameron Simpson wrote: >> Aside: Unless you do something obtuse, like make "3F" be a regular >> number with a special internal flag > > I thought exactly what you say here, that 3F would have to be a > magical type of integer. But actually, all it has to be is Fraction(3) > and everything will work perfectly. I think Cameron was talking about using 'F' for both 'binary floating point' *and* 'fraction', which would indeed lead to madness. -- Greg From tim.peters at gmail.com Fri Mar 7 03:16:53 2014 From: tim.peters at gmail.com (Tim Peters) Date: Thu, 6 Mar 2014 20:16:53 -0600 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <1394158163.96645.YahooMailNeo@web181005.mail.ne1.yahoo.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <1394158163.96645.YahooMailNeo@web181005.mail.ne1.yahoo.com> Message-ID: [Tim] >> No, it's bizarre to attach a timezone to a time object because most >> tzinfo subclasses don't - and can't - know what to return for the UTC >> offset in the absence of - at least - month and day info too. Hour, >> minute, second and microsecond aren't usually enough to determine >> whether "daylight time" is in effect, and most tzinfo subclasses do >> attempt to model daylight time. And because daylight time is a >> political conceit, most tzinfo subclasses also need year info. That >> has nothing to do with whether times are viewed abstractly, >> concretely, etc - it has to do with that time zones generally aren't >> _defined_ in terms of isolated time-of-day info. It's 7:13 PM in US >> Central. Is that daylight (CDT) or standard (CST) time? It's >> impossible to answer. What's the corresponding UTC time? Ditto. [Andrew Barnert ] > Well, a time in Central is useless, but a time in CDT or CST is not, and you can > design a library that's smart enough to give you a CDT or CST (as appropriate) time > from a Central datetime. Tell me how. You have, in context, a Python `time` object with a "Central" tzinfo member. That's all you get from the user. You're given absolutely no information about day, month, or year. What's your algorithm for implementing picking CDT or CST "as appropriate"? Note that we're NOT talking about datetime.datetime objects here. These are datetime.time objects. This isn't a problem for datetime.datetime objects. A "Central" tzinfo timeclass has no problem at all picking CDT or CST as appropriate given all the info in a datetime.datetime object. From harrismh777 at gmail.com Fri Mar 7 03:08:28 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 18:08:28 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> Message-ID: <862f6205-6b49-483a-a941-345f30bf60fb@googlegroups.com> On Thursday, March 6, 2014 6:38:34 PM UTC-6, Chris Angelico wrote: Once again, the problem occurs only because you're using a float > literal, and 2.01 can't perfectly round-trip. > > >>> Decimal(2.01) > Decimal('2.0099999999999997868371792719699442386627197265625') > > That's pretty much the value you had (I have a few more digits there, > the square rooting and squaring probably cost some accuracy), > hi Chris, yes, you are completely missing the point. We are talking past each other. I DO NOT need you to explain to me why the is working just like its supposed to... its broken and should not work this way ! If you write a number on paper do you write down '2.01' ? Do you write down d(2.01) ? Do you write down 2.01d ? (or) do you write down 2.01 ? When you punch a number into your TI89 do you punch in {'} {2} {.} {0} {1} {'} ? (or) do you punch in {2} {.} {0} {1} ? When I want a square-root from python I want to enter s1=sqrt(2.01) <====== this is normal (why?) glad you asked, because that is the human normal thing to do. Python numbers don't work correctly, because the underlying design is not correct. Everyone sees it, nobody really likes it, but everyone wants to avoid the problem like the proverbial ostrich (only worse , because this ostrich wants me to believe that everything is fine, " Don't pay any attention to that man behind the current... I... am the great and powerful OZ" marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Fri Mar 7 03:19:56 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 18:19:56 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> Message-ID: <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> On Thursday, March 6, 2014 8:09:02 PM UTC-6, Guido van Rossum wrote: Mark, it feels like you do not understand Python well enough to be able to > make sweeping proposals about its reform. > hi Guido, ouch. You can't be serious. You have not commented yet... are you happy with this: >>> from decimal import Decimal >>> a=Decimal(1) >>> b=Decimal(.1) >>> a+b Decimal('1.100000000000000005551115123') <==== does this not bother you at all ? ... even though we both know why its doing this, doesn't it bother you a little? marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Fri Mar 7 03:21:13 2014 From: rymg19 at gmail.com (Ryan) Date: Thu, 06 Mar 2014 20:21:13 -0600 Subject: [Python-ideas] Add "goto fail" to Python? In-Reply-To: <20140307011229.GM28804@ando> References: <003601cf39a1$21aa23b0$64fe6b10$@gmail.com> <20140307011229.GM28804@ando> Message-ID: Wow, those links are hilarious. Steven D'Aprano wrote: >Guys, > >Sturla's original email was quite subtle, but you may have missed that >he is proposing this as a joke PEP for April Fools Day, a bit like the >introduction of GOTO or the retirement of Guido: > >https://mail.python.org/pipermail/python-announce-list/2004-April/002982.html > >http://legacy.python.org/dev/peps/pep-0401/ > >As a joke, it pokes fun at Apple's recent "goto fail" security breach. >Unfortunately the Python C source code apparently uses exactly the same > >"goto fail" idiom, although hopefully not as poorly as Apple did. > > > >-- >Steven >_______________________________________________ >Python-ideas mailing list >Python-ideas at python.org >https://mail.python.org/mailman/listinfo/python-ideas >Code of Conduct: http://python.org/psf/codeofconduct/ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Fri Mar 7 03:19:40 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 18:19:40 -0800 (PST) Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> Message-ID: <1394158780.26537.YahooMailNeo@web181002.mail.ne1.yahoo.com> From: Tim Peters Sent: Thursday, March 6, 2014 5:51 PM > Filling in the blanks, I presume that Donald's "EST" is what the > docs > call a "fixed-offset" tzinfo subclass:? it represents a fixed offset > from UTC.? It's what a US East Coast clock would look like if the > idiotic ;-) "daylight saving" rules were repealed, and the East Coast > stayed on "standard" time forever. Except that it still wouldn't work for dates before 2014. Or, of course, if DST were reinstated in the future. If I were dictator of the world, I would ban DST. And 12-hour times. And MDY date formats. In fact, I would probably ban timezones. How hard would it be to learn that on the east coast you work from 0400-1200, not 9:00am-5:00pm? From abarnert at yahoo.com Fri Mar 7 03:26:29 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 18:26:29 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <53192B2B.1010205@mrabarnett.plus.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <624af90f-50cd-4ac8-9401-f3023b2735f3@googlegroups.com> <1394157158.94258.YahooMailNeo@web181006.mail.ne1.yahoo.com> <53192B2B.1010205@mrabarnett.plus.com> Message-ID: <1394159189.4605.YahooMailNeo@web181003.mail.ne1.yahoo.com> From: MRAB Sent: Thursday, March 6, 2014 6:12 PM > On 2014-03-07 01:52, Andrew Barnert wrote: >> Of course there's a lot of room for bikeshedding the suffix. The >> "f" >> suffix from C implies 32-bit float as opposed to 64-bit double, which >> is obviously wrong. The "d" suffix from C might be confusing as >> distinguishing "binary, not decimal". Maybe "b"? >> > Calling the floating-point class "float" implies 32-bit float as > opposed to 64-bit double, doesn't it? :-) Sure. It's not as strong an implication as an "f" suffix, because many languages (and applications) have types named float, while "0.3f" is a lot more C-family-specific. Which means "float" wasn't a perfect choice?but it was still probably the best choice. And it's certainly possible that "f" is the best choice for the suffix despite this problem.?If there were an obvious best answer that had no problems, there wouldn't be any room for bikeshedding. From abarnert at yahoo.com Fri Mar 7 03:35:31 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 18:35:31 -0800 (PST) Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <1394158163.96645.YahooMailNeo@web181005.mail.ne1.yahoo.com> Message-ID: <1394159731.26118.YahooMailNeo@web181003.mail.ne1.yahoo.com> From: Tim Peters Sent: Thursday, March 6, 2014 6:16 PM >> Well, a time in Central is useless, but a time in CDT or CST is not, and > you can >> design a library that's smart enough to give you a CDT or CST (as > appropriate) time >> from a Central datetime. > > Tell me how.? You have, in context, a Python `time` object with a > "Central" tzinfo member.? That's all you get from the user.? > You're > given absolutely no information about day, month, or year.? What's > your algorithm for implementing picking CDT or CST "as appropriate"? > Note that we're NOT talking about datetime.datetime objects here. > These are datetime.time objects. Of course that's inherently ambiguous and therefore not solvable. If your app wants unambiguous times, it can't allow users to enter times in Central with no additional information. But that's a separate problem from getting a CDT or CST time from a Central datetime (or from other problems, like handling a Central time that's known to be today). A datetime library could solve _that_ problem. > This isn't a problem for datetime.datetime objects.? A "Central" > tzinfo timeclass has no problem at all picking CDT or CST as > appropriate given all the info in a datetime.datetime object. Right, but if you get its tztime, you get a Central time, and no longer have the information that lets you use it as CDT or CST as appropriate. That is a problem?but, as I said before, it's probably not a problem in practice, and therefore probably not worth solving. (Again, I did solve it in a different timezone library, and never found a use for that feature.) From harrismh777 at gmail.com Fri Mar 7 03:51:18 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 18:51:18 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> Message-ID: <2f5ad6d3-d9e5-4866-a565-9b7a80977a1d@googlegroups.com> On Thursday, March 6, 2014 8:09:02 PM UTC-6, Guido van Rossum wrote: Mark, it feels like you do not understand Python well enough to be able to > make sweeping proposals about its reform. > hi Guido, I'm sorry, but isn't that the whole point? The person who notices that something isn't working quite right (that would be me) comes to court, as it were, before those who are supposed to know intimately how everything works (that would be you) and in good faith asks politely for the "people in the know" to correct the difficulty. You know what, you're right--- I'm a dumb cluck who doesn't know anything about the intricacies of python yadda yadda yadda... but you know what else ? > I hate this: >>> from decimal import Decimal >>> a=Decimal(1) >>> b=Decimal(.1) >>> a+b Decimal('1.100000000000000005551115123') >>> ... and I think the people who DO know intimately how python works, should do something to fix it. I'd like to help, if you'd let me. marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From cs at zip.com.au Fri Mar 7 03:52:24 2014 From: cs at zip.com.au (Cameron Simpson) Date: Fri, 7 Mar 2014 13:52:24 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <53191390.7050804@mrabarnett.plus.com> References: <53191390.7050804@mrabarnett.plus.com> Message-ID: <20140307025224.GA17812@cskk.homeip.net> On 07Mar2014 00:32, MRAB wrote: > On 2014-03-06 23:59, Cameron Simpson wrote: > >Coming to this very late, but I was interested in the first thread... > > > >On 05Mar2014 23:04, Steven D'Aprano wrote: > >>On Wed, Mar 05, 2014 at 11:29:10AM +0000, Oscar Benjamin wrote: > >>> and I would also use Fraction > >>> literals if available e.g. 1/3F. > >> > >>Out of curiosity, why F rather than f? > > > >Well, for me, +1 on 123f for "IEEE float" literals. i.e. the floats > >in play in Python right now. [...] > >So of course "F" is reasonable for fractions. But how hard does > >that make the grammar? Because the parser now has to grab the entire > >"1/3F" to construct the fraction. You can't just stick it in the lexer > >at that point. > > > I think it would be confusing if there were "f" for "float" and "F" for > "fraction". How about "r" for "rationals"? I'm good with 'r'. -- Cameron Simpson If you do not read the paper, you are uninformed. If you do read the paper, you are misinformed. - Mark Twain From abarnert at yahoo.com Fri Mar 7 03:53:35 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 18:53:35 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> Message-ID: <1394160815.26581.YahooMailNeo@web181002.mail.ne1.yahoo.com> From: Mark H. Harris Sent: Thursday, March 6, 2014 6:19 PM [snipping out of order] >?>>> from decimal import Decimal >>>> a=Decimal(1) >>>> b=Decimal(.1) >>>> a+b >Decimal('1.100000000000000005551115123') ? ? ?<==== does this not bother you at all ? > >? ? ... even though we both know why its doing this, doesn't it bother you a little? That's not a problem with Python's number system, it's that Decimal(.1) is not the right way to write what you want. The only solution without changing Python is to train end-users to write something correct, like Decimal('.1'). The obvious solution for changing Python is to make it easier to create Decimal numbers correctly and/or harder to create them incorrectly. For example, a decimal suffix, as already proposed before this thread, would completely solve the problem: ? ? >>> a = 1d ? ? >>> b = .1d ? ? >>> a+b ? ? 1.1d Of course the exact suffix (or other syntax) is up for bikeshedding, as is the possibility of one day changing the default from binary floats to decimal floats, but other than those trivial details, tada.?But there's no need for anything more radical, like some amorphous idea to "unify Python numbers". >On Thursday, March 6, 2014 8:09:02 PM UTC-6, Guido van Rossum wrote: > >>Mark, it feels like you do not understand Python well enough to be able to make sweeping proposals about its reform.? > >hi Guido, ?ouch. You proposed that Python should handle numbers in an OO way, with numbers being real objects, instances of classes, with a hierarchy including abstract base classes; all of this is already there in Python. You went off on a long digression about how you could implement this using the details of C++-style inheritance, when Python has a completely (and more powerful) different solution to inheritance that has already been used to solve this problem. You proposed some complicated AI-based solution to solve the problem of using separate number classes in a single expression, even though Python (almost exactly like C++, in this case) has already solved that problem with operator overloading. (And note that Python is flexible enough that third-party libraries can easily insert new types like quaternions, matrices, symbolic expressions, etc. into the hierarchy in a way that's transparent to end users. I can multiply a NumPy matrix of float64 values by the builtin in 2 just by writing "m * 2", and it works exactly the way you'd want it to.?It's hard to imagine that would be even feasible with an AI-based solution, but with the current design, that's the easiest part of NumPy.) There are some ideas in your posts that are worth responding to, but I think it's perfectly fair for Guido to decide it's not worth digging through the mass of ignorance about Python's basic design to find the nuggets that can be rejected for more specific reasons instead of just dismissed. From ben+python at benfinney.id.au Fri Mar 7 04:12:32 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Fri, 07 Mar 2014 14:12:32 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <2f5ad6d3-d9e5-4866-a565-9b7a80977a1d@googlegroups.com> Message-ID: <85k3c6bt27.fsf@benfinney.id.au> "Mark H. Harris" writes: > On Thursday, March 6, 2014 8:09:02 PM UTC-6, Guido van Rossum wrote: > > > Mark, it feels like you do not understand Python well enough to be > > able to make sweeping proposals about its reform. > > hi Guido, I'm sorry, but isn't that the whole point? The person who > notices that something > isn't working quite right (that would be me) comes to court, as it were, > before those who > are supposed to know intimately how everything works (that would be you) > and in good > faith asks politely for the "people in the know" to correct the difficulty. No, that's not the point of this forum. The point of this forum is to present ideas for improvement to Python and to *defend* those ideas robustly against critique, in order to converge on concrete proposals. To do that, you need to have a pretty good understanding of Python as it currently is, especially in the domain of the change you're proposing, in order to robustly defend an idea for improvement. > I hate this: [?] If you want a forum for general discussion where complaints lacking a good understanding of Python can be bounced around, this isn't it. You can try the general discussion forum for Python . But beware that even there, complaints about how Python behaves aren't going to be well received if you show a wilful ignorance of that behaviour. Mere ignorance is fine, of course: we all start out ignorant of any given topic. But wilful ignorance isn't a good foundation for expecting change. It's better to take the complaint as motivation to *learn* why Python behaves this way, to see if your assumptions may not be flawed. > ... and I think the people who DO know intimately how python works, > should do something to fix it. You'll need to form a much more concrete understanding of why it is the way it is, and exactly what behavioural change you want, and an understanding of the costs and benefits of that change, before such an expectation would in any way imply an obligation on others to do what you want. This forum isn't the place to begin with that. -- \ ?You say ?Carmina?, and I say ?Burana?, You say ?Fortuna?, and | `\ I say ?cantata?, Carmina, Burana, Fortuna, cantata, Let's Carl | _o__) the whole thing Orff.? ?anonymous | Ben Finney From cs at zip.com.au Fri Mar 7 03:58:21 2014 From: cs at zip.com.au (Cameron Simpson) Date: Fri, 7 Mar 2014 13:58:21 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <53192BED.6090909@canterbury.ac.nz> References: <53192BED.6090909@canterbury.ac.nz> Message-ID: <20140307025821.GA19433@cskk.homeip.net> On 07Mar2014 15:16, Greg Ewing wrote: > On 7/03/2014 1:17 p.m., Chris Angelico wrote: > >On Fri, Mar 7, 2014 at 10:59 AM, Cameron Simpson wrote: > >>Aside: Unless you do something obtuse, like make "3F" be a regular > >>number with a special internal flag > > > >I thought exactly what you say here, that 3F would have to be a > >magical type of integer. But actually, all it has to be is Fraction(3) > >and everything will work perfectly. > > I think Cameron was talking about using 'F' for both 'binary > floating point' *and* 'fraction', which would indeed lead to > madness. Well, only because I hadn't thought through to having it be a literal Fraction, which it turns out already has exactly this cool semantic. -- Cameron Simpson The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw From cs at zip.com.au Fri Mar 7 04:29:08 2014 From: cs at zip.com.au (Cameron Simpson) Date: Fri, 7 Mar 2014 14:29:08 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <862f6205-6b49-483a-a941-345f30bf60fb@googlegroups.com> References: <862f6205-6b49-483a-a941-345f30bf60fb@googlegroups.com> Message-ID: <20140307032908.GA46124@cskk.homeip.net> On 06Mar2014 18:08, Mark H. Harris wrote: > On Thursday, March 6, 2014 6:38:34 PM UTC-6, Chris Angelico wrote: > Once again, the problem occurs only because you're using a float > > literal, and 2.01 can't perfectly round-trip. > > > > >>> Decimal(2.01) > > Decimal('2.0099999999999997868371792719699442386627197265625') > > > > That's pretty much the value you had (I have a few more digits there, > > the square rooting and squaring probably cost some accuracy), > > hi Chris, yes, you are completely missing the point. We are talking past > each other. I DO NOT need you to explain to me why the is working just > like its supposed to... its broken and should not work this way ! > > If you write a number on paper do you write down '2.01' ? > > Do you write down d(2.01) ? > > Do you write down 2.01d ? > > (or) do you write down 2.01 ? [...] > When I want a square-root from python I want to enter s1=sqrt(2.01) > <====== this is normal So essentially you are saying: when I write Python code I do not want to have to put in all this special notation to get the actual value which I naturally mean. And if you write 2.01, you mean 2 + 1/100, without roundoff because you do not want to be working in a system which would round that off. i.e. a Decimal internal representation because you're writing a number in base 10. To my mind you want a Python _parser_ mode, because inside python, given the various numeric classes abounding, the actual _mechanisms_ already exist. So really you want to have a way of saying to the parser: in the code, 2.01 is not transformed into an IEEE float with some loss of precision, it is transformed into a Decimal floating point number, with no loss of precision. There are, it seems to me, two basic ways to approach this. The easy one is give Python something like: from __the_far_far_future__ import Decimal_numbers and have decimal literals converted into those instead of Python "floats". The alternative is the implement a Python class, let us call it "AbtractNumber", which stores the literal text you put in the programme code "2.01" and converts it, _when used_, to a suitable python type with the right semantics. Either would get you code where: x = 2.01 is stored without loss of precision, and may get you the behaviour you're after. Which of these more closely matches your desires? Please try to be precise. Examples don't quite do it without some rather precise accompanying lagunage which says what specific things the example is meant to illustrate. If one of my two suggestions above is very close to what you're after, please present an example where one suggestion does what you want and where the other would not, with an explaination of why. Just hoping to get at things more precisely and clearly, -- Cameron Simpson Careful and correct use of language is a powerful aid to straight thinking, for putting into words precisely what we mean necessitates getting our own minds quite clear on what we mean. - W.I.B. Beveridge From stephen at xemacs.org Fri Mar 7 04:30:55 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 07 Mar 2014 12:30:55 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5318EA28.3040305@stoneleaf.us> References: <201403051216.12392.shai@platonix.com> <16619289-2CDC-4C0A-B2FC-9B1EB58A29CD@masklinn.net> <5318EA28.3040305@stoneleaf.us> Message-ID: <87eh2eptw0.fsf@uwakimon.sk.tsukuba.ac.jp> Ethan Furman writes: > On 03/05/2014 07:42 AM, Paul Moore wrote: > > On 5 March 2014 15:08, Yann Kaiser wrote: > >> Let me show you an actual zero: > >> > >> if event.num_attendants: > >> prepare_cake() > >> else: > >> cancel_event() > > I'm sorry, are you really trying to say that the above code is better than > > > > if event.num_attendants != 0: > > prepare_cake() > > else: > > cancel_event() > > > > ? > Yes. This is Python. blah blah blah != 0 is unnecessary boiler-plate. I wouldn't call that *better*, just a different style. I agree I prefer "if blah.count:" to "if blah.count != 0:", but I might very well write "if blah.count > 0:". I don't see anything "wrong" with using an explicit comparison, but I don't have a problem reading the abbreviated style in this situation.[1] Personally I would *always* use the "implied boolean" style for emptiness tests (I'm an old Lisper), but I might very well use explicit comparisons against zero. For example, I would be likely to write the party example with a reversed test (to keep 'if' and 'else' close together): if event.num_attendants == 0: # nobody's coming cancel_event() else: # several-pages-long suite of preparations prepare_cake() and I think that looks better than if not event.num_attendants: # it's a count, not a boolean # etc But actually I'd probably design the event class differently, and write it as: if not event.list_of_attendants: # attendance list is empty # etc or perhaps if event.list_of_attendants: # attendance list is non-empty # reverse the suites (depending on the phase of the moon and whether the trout are running in Esopus Creek to choose between the last two :-). Footnotes: [1] I do have a real issue with the "if x:" to test for a sentinel meaning "uninitialized" that happens to evaluate to false. There's objectively a probability that it would pass an error that would be caught if the "is None" form were used, but that probability is admittedly low. Tastes may differ regarding "importance" here. From stephen at xemacs.org Fri Mar 7 04:37:02 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 07 Mar 2014 12:37:02 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53190936.6030608@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53190936.6030608@canterbury.ac.nz> Message-ID: <87d2hyptlt.fsf@uwakimon.sk.tsukuba.ac.jp> Greg Ewing writes: > It seems to me that those claiming "midnight is special" > are inventing a justification after the fact -- one > that is not supported by the actual behaviour. > > Altogether, the whole thing seems to be a mess. Mirroring the real world, no? From steve at pearwood.info Fri Mar 7 04:45:47 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 7 Mar 2014 14:45:47 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> Message-ID: <20140307034547.GO28804@ando> On Thu, Mar 06, 2014 at 04:17:55PM -0800, Mark H. Harris wrote: > I just had one more thought along this line; consider this: > > >>> from pdeclib import * > >>> s1=sqrt(2.01) > >>> s1 > Decimal('1.41774468787578244511883132198668766452744') > >>> s2=sqrt(d(2.01)) > >>> s2 > Decimal('1.41774468787578252029556185427085779261123') > >>> > >>> s1**2 > Decimal('2.00999999999999978683717927196994423866272') > >>> s2**2 > Decimal('2.01000000000000000000000000000000000000000') If you skip the conversion to Decimal, you actually get the right answer using floats: py> (2.01**0.5)**2 2.01 So the problem here isn't the binary float, but that Decimal by default has *too much precision* and consequently it ends up keeping digits that the user doesn't care about: py> from decimal import Decimal as D py> (D.from_float(2.01)**D("0.5"))**2 Decimal('2.009999999999999786837179272') Floats have about 14 significant base-10 figures of precision (more in base-2), so if we tell Decimal to use the same, we should get the same result: py> import decimal py> ct = decimal.getcontext() py> ct.prec = 14 py> (D.from_float(2.01)**D("0.5"))**2 Decimal('2.0100000000000') Decimal is not a panacea. Both Decimal and binary floats have the same limitations, they just occur in different places for different numbers. All floating point numbers have these same issues. Fixed point numbers have different issues, rationals have their own issues, and symbolic computations have a different set of issues. Computer maths is a leaky abstraction. No matter what you do, how you implement it, the abstraction leaks. Not even Mathematica can entirely hide the fact that it is computing rather than performing a Platonic ideal of mathematics. -- Steven From harrismh777 at gmail.com Fri Mar 7 04:53:15 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 19:53:15 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <1394160815.26581.YahooMailNeo@web181002.mail.ne1.yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> <1394160815.26581.YahooMailNeo@web181002.mail.ne1.yahoo.com> Message-ID: <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> On Thursday, March 6, 2014 8:53:35 PM UTC-6, Andrew Barnert wrote: > > > The only solution without changing Python is to train end-users to write > something correct, like Decimal('.1'). > hi Andrew, yes, that is the problem. And, to be fair, that example is not really the worst because it might be expected that the user should know how to construct Decimals, and could be educated to construct them properly--> Decimal('0.1'); I concur. It is worse in these two scenarios (and others too): sqrt(.1) sin(.1) No one would expect that the user should know to quote the number---when is that ever done? QED this is broken. Again, we know perfectly well why its happening (I am not ignorant) but its not right. > > The obvious solution for changing Python is to make it easier to create > Decimal numbers correctly and/or harder to create them incorrectly. For > example, a decimal suffix, as already proposed before this thread, would > completely solve the problem: > > >>> a = 1d > >>> b = .1d > >>> a+b > 1.1d > Yes, and at a bare minimum, that is the immediate change I have been asking for, for now; nothing more. I answered Guido's questions in hopes that he might be willing to dialogue --- not dismiss. > You proposed that Python should handle numbers in an OO way, with numbers > being real objects, instances of classes, with a hierarchy including > abstract base classes; all of this is already there in Python. > Yes, it is... but its not designed to use decimal floating point by default... in order to do that the entire OO setup will have to be changed (what Guido called a sweeping reform). Its like if we want to use floating point decimals in the 21st century, using python, we have to duck tape modules on and then educate users in the correct input of numbers. Seems convoluted to me. > > You went off on a long digression about how you could implement this using > the details of C++-style inheritance, when Python has a completely (and > more powerful) different solution to inheritance that has already been used > to solve this problem. > No, I did not. I answered Guido's questions regarding context as clearly as I could. If python has a more powerful way to handle this situation, gladly do it! I will be happy as a clam to beta test or help with the coding. > > You proposed some complicated AI-based solution to solve the problem of > using separate number classes in a single expression, even though Python > (almost exactly like C++, in this case) has already solved that problem > with operator overloading. > No, I did not. I suggested that unifying numbers in an (AI) way could solve this problem (conceptually) by regarding all numbers as *PythonNumbers. *Decimals should not only be default, they should be integrated, not tacked on with duck tape. > > (And note that Python is flexible enough that third-party libraries can > easily insert new types like quaternions, matrices, symbolic expressions, > etc. into the hierarchy in a way that's transparent to end users. I can > multiply a NumPy matrix of float64 values by the builtin in 2 just by > writing "m * 2", and it works exactly the way you'd want it to. It's hard > to imagine that would be even feasible with an AI-based solution, but with > the current design, that's the easiest part of NumPy.) > That's nice for you. Because sqrt(.23709) does not behave as I expect, sadly, I have to train my users to enter sqrt('0.23709'). > > There are some ideas in your posts that are worth responding to, > Thank you. If a user goes to the time and trouble to present an idea clearly, I would expect the responders to respect the effort and respond to the points that make sense. Andrew, I respect you for taking the time to dialogue, I appreciate it. Thanks. marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Fri Mar 7 04:50:35 2014 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 06 Mar 2014 19:50:35 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <20140306030002.GH28804@ando> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <20140306030002.GH28804@ando> Message-ID: <5319420B.3000004@stoneleaf.us> On 03/05/2014 07:00 PM, Steven D'Aprano wrote: > On Wed, Mar 05, 2014 at 09:23:37PM -0500, Donald Stufft wrote: > >> It?s hard to do any sort of search for this, however in an informal poll where I?ve shown >> people this code not a single person thought it made sense, and most of them responded >> with ?wtf??. > > Well I don't know who these people are, what their background is, or > exactly how you phrased the question. But in my experience, most > programmers have extremely strongly held opinions about the sensibility > of certain features that have little or nothing with any rational > analysis of the pros and cons and far more likely to be "that's > different from the first language I learned, therefore it's rubbish". As part of learning Python, I learned one of its core tenets was the divide between something and nothing (some of that from you, I believe ;), midnight is most certainly something, so I was very surprised to learn that bool(midnight) is False. -- ~Ethan~ From stephen at xemacs.org Fri Mar 7 04:58:45 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 07 Mar 2014 12:58:45 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53190A16.4020201@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <5318626F.5080203@btinternet.com> <20140306152936.3c990c46@anarchist.wooz.org> <53190A16.4020201@canterbury.ac.nz> Message-ID: <87bnxipslm.fsf@uwakimon.sk.tsukuba.ac.jp> Greg Ewing writes: > Barry Warsaw wrote: > > On Mar 06, 2014, at 11:56 AM, Rob Cliffe wrote: > > > >>Instances of existing code that would be broken by the change: 0 > > > > You can't know this because you can't audit all the Python code > > in the world. > > I think he means instances that have been pointed out > so far in this discussion. Well, either way it's a pretty careless claim. Alexander and Tim both have stated that they have used "if time:" to test for a zero time (per the documentation) in actual applications. I gather from the fact that Tim is "-0" on the change that his code was never widely distributed, but I don't know about Alexander's. Probably not, as he didn't post a URL, either. AFAIK the code doesn't have to be distributed for gratuitous code breakage to be considered a Very Bad Thing, though. One of Alexander's use cases (changing date in a simulation at midnight using naive times) is particularly salient here. Unlike any of the other cases described so far by either side, it's clear that his simulation would be completely broken by the proposed incompatible change in behavior, as the date would never change. (Granted, it's not clear to me whether he actually implemented this in production, but I also can't say from what I've read that he didn't.) From rosuav at gmail.com Fri Mar 7 05:16:27 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 15:16:27 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <1394157158.94258.YahooMailNeo@web181006.mail.ne1.yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <624af90f-50cd-4ac8-9401-f3023b2735f3@googlegroups.com> <1394157158.94258.YahooMailNeo@web181006.mail.ne1.yahoo.com> Message-ID: On Fri, Mar 7, 2014 at 12:52 PM, Andrew Barnert wrote: > From: Chris Angelico > > Sent: Thursday, March 6, 2014 4:29 PM > > >> So... I'm +1 for adding a literal syntax for decimals. +1 for adding a >> stating-the-default for floats (do it straight away, then code that >> uses it can be backported all the way even when there's a change of >> default). > > This makes sense if you also add an optional suffix for binary floats at the same time. Otherwise, it would be confusing to talk about the "default" when there's no way to make it explicit, and it would delay any potential change of the default by at least one version, if not more. > > Of course there's a lot of room for bikeshedding the suffix. The "f" suffix from C implies 32-bit float as opposed to 64-bit double, which is obviously wrong. The "d" suffix from C might be confusing as distinguishing "binary, not decimal". Maybe "b"? > Yep. That's what I mean (when I said "float"s up there, I meant the current type 'float', aka binary floating point). The suffix won't have any effect; it'll be like u"string" in Py3, explicitly stating the default, and added for the exact same reason. >> +0.5 for adding a syntax for fractions; support in principle >> but the devil's in the details. > > What details, other than bikeshedding the exact suffix? If 3r == fraction.Fraction(3), we're done, right? > Precisely that detail. Is it 3r? 3F? Something else? Would it look tidier as a prefix instead of a suffix? But if that can be resolved, it'd be good to have a syntax for fractions. I'm only +0.5 on that, as rationals aren't as big an advantage over the status quo as decimal is. It's a lot less common to see: >>> Fraction(1/3) Fraction(6004799503160661, 18014398509481984) than the oddities of decimal.Decimal construction that we're seeing here. Having a numeric suffix for decimal literals will be much more beneficial to the language, imo; if the bikeshedding of Fraction literals is problematic, I'd not be against doing decimal (and binary float) tags one version, and leaving Fraction for another version. ('Course, it might all work out perfectly, in which case great! Add 'em all at once.) ChrisA From harrismh777 at gmail.com Fri Mar 7 05:17:33 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 20:17:33 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <85k3c6bt27.fsf@benfinney.id.au> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <2f5ad6d3-d9e5-4866-a565-9b7a80977a1d@googlegroups.com> <85k3c6bt27.fsf@benfinney.id.au> Message-ID: <95630dc1-695a-4ab0-89be-8ed1c116768d@googlegroups.com> On Thursday, March 6, 2014 9:12:32 PM UTC-6, Ben Finney wrote: > But beware that even there, complaints about how Python behaves aren't > going to be well received if you show a wilful ignorance of that > behaviour. Mere ignorance is fine, of course: we all start out ignorant > of any given topic. But wilful ignorance isn't a good foundation for > expecting change. > Ben, excuse me, but you are out of line here. I have not shown will full ignorance in any of this discussion (None). I am not ignorant of the system, nor am I ignorant of the underlying caveats. I have studied here, and I have a pretty good handle on how things are working. When I have been confused I asked questions, read, experimented, and researched. I will not have it here said that I have displayed will full ignorance, nor should anyone believe it. I have a good understanding of why it is... I just don't like why it is... those are two very different things. I am fully aware of the issues created by IEEE 754 1985 floats and doubles. This is 2014. I would expect that python would be using IEEE 754 2008 not only for specification, but also for moving towards decimal floating point arithmetic by default. Continuing to stick with a 1985 standard, or even an IEEE 854 1987 standard, is putting all python communities behind the eight ball going forward into the 21st Century. This is not will full ignorance. Its eyes-wide-open thoroughly knowledgable concern with a genuine "will" to see the right thing done... because its the right thing to do. marcus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben+python at benfinney.id.au Fri Mar 7 05:27:39 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Fri, 07 Mar 2014 15:27:39 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <2f5ad6d3-d9e5-4866-a565-9b7a80977a1d@googlegroups.com> <85k3c6bt27.fsf@benfinney.id.au> <95630dc1-695a-4ab0-89be-8ed1c116768d@googlegroups.com> Message-ID: <85d2hybpl0.fsf@benfinney.id.au> "Mark H. Harris" writes: > On Thursday, March 6, 2014 9:12:32 PM UTC-6, Ben Finney wrote: > > > But beware that even there, complaints about how Python behaves aren't > > going to be well received if you show a wilful ignorance of that > > behaviour. Mere ignorance is fine, of course: we all start out ignorant > > of any given topic. But wilful ignorance isn't a good foundation for > > expecting change. > Ben, excuse me, but you are out of line here. I have not shown > will full ignorance in any of this discussion (None). I didn't mean to imply that, though I can see how the above can be read that way. My apologies for giving that impression. Nevertheless, the warning stands for those who wish to bring a complaint in this forum or the ?python-list? forum. -- \ ?Probably the toughest time in anyone's life is when you have | `\ to murder a loved one because they're the devil.? ?Emo Philips | _o__) | Ben Finney From rosuav at gmail.com Fri Mar 7 05:29:15 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 15:29:15 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <95630dc1-695a-4ab0-89be-8ed1c116768d@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <2f5ad6d3-d9e5-4866-a565-9b7a80977a1d@googlegroups.com> <85k3c6bt27.fsf@benfinney.id.au> <95630dc1-695a-4ab0-89be-8ed1c116768d@googlegroups.com> Message-ID: On Fri, Mar 7, 2014 at 3:17 PM, Mark H. Harris wrote: > On Thursday, March 6, 2014 9:12:32 PM UTC-6, Ben Finney wrote: > >> >> But beware that even there, complaints about how Python behaves aren't >> going to be well received if you show a wilful ignorance of that >> behaviour. Mere ignorance is fine, of course: we all start out ignorant >> of any given topic. But wilful ignorance isn't a good foundation for >> expecting change. > > Ben, excuse me, but you are out of line here. I have not shown > will full ignorance in any of this discussion (None). Hey hey, I'd be careful of calling someone out like that... might want to be a little humble and respectful here :) The main problem here is that you and the Python interpreter have different expectations about a string of digits in the source code. You expect them to be represented exactly; the language specifies that they be represented with the float type. Changing how the language interprets something as fundamental as "number with decimal point in it", even if unassailably correct, is a backward-incompatible change. (The full unification of the int and long types wasn't effected until Python 3, even though that change is unlikely to break much code.) If someone wants to push for it, write the PEP, go through all the details, then it'd be possible to have this for Python 3.5: >>> 0.1d == Decimal("0.1") True But you're not going to have that effect for untagged numbers without a long deprecation period; probably we're talking Python 4000, which may not ever even exist. It'd be possible to have a __future__ directive that switches around the two types, so decimal is the default and binary floats have to be tagged, but that could cause so much confusion that it'd itself be the subject of massive controversy. (Although there would be precedent for it. "from __future__ import unicode_literals" didn't destroy Py2 code readability.) ChrisA From cs at zip.com.au Fri Mar 7 05:32:33 2014 From: cs at zip.com.au (Cameron Simpson) Date: Fri, 7 Mar 2014 15:32:33 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> References: <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> Message-ID: <20140307043233.GA14220@cskk.homeip.net> On 06Mar2014 19:53, Mark H. Harris wrote: > On Thursday, March 6, 2014 8:53:35 PM UTC-6, Andrew Barnert wrote: [... lots of stuff, snipped along with Mark's replies ...] > > You proposed some complicated AI-based solution to solve the problem of > > using separate number classes in a single expression, even though Python > > (almost exactly like C++, in this case) has already solved that problem > > with operator overloading. > > No, I did not. I suggested that unifying numbers in an (AI) way > could solve this problem (conceptually) by > regarding all numbers as *PythonNumbers. *Decimals should not only be > default, they should be integrated, not > tacked on with duck tape. This sounds to me like keeping the original numeric text around and only turning it into some efficient-for-a-machine representation when it comes time to work on it. One issue with that is that when the work occurs, it can be far from where the number was defined, and the correct internal representation might be poorly chosen. > > (And note that Python is flexible enough that third-party libraries can > > easily insert new types like quaternions, matrices, symbolic expressions, > > etc. into the hierarchy in a way that's transparent to end users. I can > > multiply a NumPy matrix of float64 values by the builtin in 2 just by > > writing "m * 2", and it works exactly the way you'd want it to. It's hard > > to imagine that would be even feasible with an AI-based solution, but with > > the current design, that's the easiest part of NumPy.) > > That's nice for you. Because sqrt(.23709) does not behave as I > expect, sadly, I have to train my users to enter sqrt('0.23709'). That's partly because .23709, in current python, becomes an IEEE float with some loss of precision because binary fractions and base-10 fractions do not round trip. But also partly because sqrt() (in the pure mathematical sense) often produces transcendental numbers, which are not representation by any fixed precision intergal base notation - effectively IEEE floats and Decimal floats are fractions/rationals. So sqrt() will, for almost all numbers, involve loss of precision no matter what base your backing storage is: base 2 as in IEEE float or base 10 as in a Decimal. Steven (or Stephen) has already pointed this out to you; perhaps it has been missed. And going back (eg sqrt(2.01)*sqrt(2.01) ==> not-quite-2.01) just extends this loss of precision. This is an inherent problem unless sqrt() doesn't convert to a "concrete" type, and instead just lurks as some symbolic representation, so that any expression involving it becomes a progressively more elaboration representation of an algebraic expression. Which may be correct, but only until you try to evaluate it to get a concrete number again. > > There are some ideas in your posts that are worth responding to, > > Thank you. If a user goes to the time and trouble to present an > idea clearly, I would expect the responders > to respect the effort and respond to the points that make sense. Many people have. You should see the short shrift some ideas receive. I think part of the problem is not your wish for a "number" but that lack of a concrete proposal to implement it. Cheers, -- Cameron Simpson The Usenet is not the real world. The Usenet usually does not even resemble the real world. - spaf at cs.purdue.edu From rosuav at gmail.com Fri Mar 7 05:38:02 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 15:38:02 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <1394158780.26537.YahooMailNeo@web181002.mail.ne1.yahoo.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <1394158780.26537.YahooMailNeo@web181002.mail.ne1.yahoo.com> Message-ID: On Fri, Mar 7, 2014 at 1:19 PM, Andrew Barnert wrote: > If I were dictator of the world, I would ban DST. And 12-hour times. And MDY date formats. In fact, I would probably ban timezones. How hard would it be to learn that on the east coast you work from 0400-1200, not 9:00am-5:00pm? > Fortunately, you don't have to be dictator of the whole world. As admin of Minstrel Hall (minstrelhall.com), I simply made the declaration that all campaign times would be listed in UTC. That effectively bans DST and timezones. The in-game clock uses 24-hour time, so a lot of people follow that. Most things happen on a weekly cycle, so I haven't done anything about MDY (the in-game clock currently reads "Fri 04:36:05"), but again, I would personally use YMD most likely, and a lot of people will just follow that. Let's start creating pockets like that all over the place. Train people to manage international events in UTC. Eventually the benefits will start to be more visible :) ChrisA From rosuav at gmail.com Fri Mar 7 05:43:26 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 15:43:26 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <53192B14.4070304@canterbury.ac.nz> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <53190D28.50205@canterbury.ac.nz> <53192B14.4070304@canterbury.ac.nz> Message-ID: On Fri, Mar 7, 2014 at 1:12 PM, Greg wrote: > On 7/03/2014 1:13 p.m., Chris Angelico wrote: >> >> What operations can you do on a time-of-day-with-timezone? Give me >> some examples, and I'll show you, with the above two examples, how >> quirky that can be. > > > I'm not particularly attached to the idea of times of day with > timezones; I wouldn't mind if they didn't exist. > > The main point is that they definitely don't make sense for > time differences. An hour in New York is the same length as > an hour in Melbourne, on any day of the year, as far as I know. Sure. So a timedelta with timezone makes no sense. But we're not talking about timedelta here, we're talking about time. (And we're also ostriching leap seconds away. Don't wanna know! Don't wanna know!) A calendar that supports repeating events is going to need some kind of rule system anyway. I don't think a "time with timezone" is sufficient for that. I haven't used that kind of system (ever!), but from Lennart Regebro's PyCon 2013 talk "Blame it on Caesar", I gather that there is such a thing in Python. So... from this thread, it seems like there's only one real use for time-with-timezone: fracturing a datetime-with-timezone into two parts, date and time, and recombining losslessly. Anyone have other uses? ChrisA From harrismh777 at gmail.com Fri Mar 7 05:51:16 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 20:51:16 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <85d2hybpl0.fsf@benfinney.id.au> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <2f5ad6d3-d9e5-4866-a565-9b7a80977a1d@googlegroups.com> <85k3c6bt27.fsf@benfinney.id.au> <95630dc1-695a-4ab0-89be-8ed1c116768d@googlegroups.com> <85d2hybpl0.fsf@benfinney.id.au> Message-ID: On Thursday, March 6, 2014 10:27:39 PM UTC-6, Ben Finney wrote: > > > Ben, excuse me, but you are out of line here. I have not shown > > will full ignorance in any of this discussion (None). > > I didn't mean to imply that, though I can see how the above can be read > that way. My apologies for giving that impression. > > Nevertheless, the warning stands for those who wish to bring a complaint > in this forum or the ?python-list? forum. > hi Ben, forgive me, I misunderstood you. No problem, nor hard feelings. Chris is absolutely correct when he asks for humble respect. I absolutely respect you guys, and I'm here to learn as much as anything. Thank you for your insights. Kind regards, marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Fri Mar 7 06:02:54 2014 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 06 Mar 2014 21:02:54 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> <53187670.6070302@egenix.com> Message-ID: <531952FE.5050205@stoneleaf.us> On 03/06/2014 08:13 AM, Alexander Belopolsky wrote: > > On Thu, Mar 6, 2014 at 8:21 AM, M.-A. Lemburg > wrote: > > > Are they all False? No, no they're not (unless your local timezone is UTC): > > > >>>> bool(utcmidnight) > > False > >>>> bool(naivemidnight) > > False > >>>> bool(localmidnight) > > True > > Now this is a what I consider a valid argument for making a change. > > > FWIW, I would be +0 for making a change so that t.tzinfo is not None > implies bool(t.timetz()) is True. > > My intuition goes like this. Given > >>>> from datetime import * >>>> t1 = datetime(2014, 1, 1) >>>> t2 = datetime(2014, 1, 1, 12) >>>> t3 = datetime(2014, 1, 1, tzinfo=timezone.utc) > > Instance t1 has no time information, so t1.time() is false-y. If datetime actually worked like that I would agree with you; but it doesn't -- it says you have the time of midnight on 2014, 1, 1, not that you don't have a time at all. -- ~Ethan~ From steve at pearwood.info Fri Mar 7 06:25:21 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 7 Mar 2014 16:25:21 +1100 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <1394158780.26537.YahooMailNeo@web181002.mail.ne1.yahoo.com> Message-ID: <20140307052521.GP28804@ando> On Fri, Mar 07, 2014 at 03:38:02PM +1100, Chris Angelico wrote: > On Fri, Mar 7, 2014 at 1:19 PM, Andrew Barnert wrote: > > If I were dictator of the world, I would ban DST. And 12-hour times. And MDY date formats. In fact, I would probably ban timezones. How hard would it be to learn that on the east coast you work from 0400-1200, not 9:00am-5:00pm? > > > > Fortunately, you don't have to be dictator of the whole world. As > admin of Minstrel Hall (minstrelhall.com), I simply made the > declaration that all campaign times would be listed in UTC. That > effectively bans DST and timezones. No it doesn't. People still have to convert from the listed timezone to their own local timezone. The only difference is that instead of privileging some semi-arbitrary timezone on the basis of where your servers are, you're privileging an even more arbitrary timezone in Europe. Depending on the distribution of your users, chances are good that you're actually inconveniencing more people by your decision than if you used the local timezone. [...] > Let's start creating pockets like that all over the place. Train > people to manage international events in UTC. Eventually the benefits > will start to be more visible :) There are no benefits, not even to programmers, since they will still have to convert a local time to UTC. The only differences will be: - people whose local time happens to be UTC won't have to do anything; - everyone else will suffer more, as even local (to them) events will need to be converted from UTC. Really, all these (hopefully tongue-in-cheek) suggestions to ban timezones are as useful as those (unfortunately serious) suggestions to avoid all the issues with Unicode by going back to "good ol' ASCII" and insist that everybody write in American English. (Actually a subset of American English, since ASCII is missing some common American symbols.) -- Steven From abarnert at yahoo.com Fri Mar 7 06:30:47 2014 From: abarnert at yahoo.com (Andrew Barnert) Date: Thu, 6 Mar 2014 21:30:47 -0800 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> <1394160815.26581.YahooMailNeo@web181002.mail.ne1.yahoo.com> <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> Message-ID: <6F35C6C7-1809-4A3F-A7DF-E9EF8A628AE2@yahoo.com> On Mar 6, 2014, at 19:53, "Mark H. Harris" wrote: > On Thursday, March 6, 2014 8:53:35 PM UTC-6, Andrew Barnert wrote: >> >> >> The only solution without changing Python is to train end-users to write something correct, like Decimal('.1'). > > hi Andrew, yes, that is the problem. And, to be fair, that example is not really the worst > because it might be expected that the user should know how to construct Decimals, and > could be educated to construct them properly--> Decimal('0.1'); I concur. > It is worse in these two scenarios (and others too): > sqrt(.1) > sin(.1) No, that's not the same problem but worse, it's a completely different problem. In the first case, the user is trying to specify 0.1 as a decimal number, which is exactly representable, just not the way he's entered it. In these cases, the numbers are irrational, and therefore inherently impossible to represent exactly. It doesn't matter whether you use decimal floats or binary floats. > No one would expect that the user should know to quote the number---when is that ever done? What does quoting have to do with anything? Do you not understand why Decimal('.1') works? It's not because Python is a weakly-typed language that allows you to use strings as numbers, but because Decimal has a constructor that takes strings, for a specific and well-documented reason. Quoting here would just give you a TypeError. And nothing in your proposal(s) would change that. > QED this is broken. Again, we know perfectly well why its happening (I am not ignorant) but its not right. The only way to fix this second problem is to use a symbolic representation instead of a numeric one. The good news is that Python's design makes that pretty easy to add on--as SymPy demonstrates. Your proposal would actually make this kind of add-on much harder. >> The obvious solution for changing Python is to make it easier to create Decimal numbers correctly and/or harder to create them incorrectly. > > Yes, and at a bare minimum, that is the immediate change I have been asking for, for now; nothing more. And people have agreed with that, and proposed feasible extensions to it. Presenting it as the first step toward some radical and ill-formed transformation of the whole language weakens the case for this suggestion. Implying that it would solve problems (like handling irrational numbers) that it obviously can't also weakens the case. > I answered Guido's questions in hopes that he might be willing to dialogue --- not dismiss. He was willing to dialogue, as evidenced by his initial replies. It was only after you demonstrated your ignorance of basics fundamentals of Python (as a user, not even about its implementation) and math/numerics, and implied that you had no interest in correcting that ignorance, that he dismissed you. And he has every right to do so. He's the one donating his free time to make a great language for you (and many others) to use, not the other way around. >> You proposed that Python should handle numbers in an OO way, with numbers being real objects, instances of classes, with a hierarchy including abstract base classes; all of this is already there in Python. > > Yes, it is... but its not designed to use decimal floating point by default... in order to do that the entire OO > setup will have to be changed (what Guido called a sweeping reform). Nonsense. Python already has classes for both binary and decimal floats. They both fit into the hierarchy properly. They both interact with other types the way they should. Changing which one you get from the literal "0.1" would be a simple change to the parser, and have no effect whatsoever to the OO setup. >> You went off on a long digression about how you could implement this using the details of C++-style inheritance, when Python has a completely (and more powerful) different solution to inheritance that has already been used to solve this problem. > > No, I did not. I answered Guido's questions regarding context as clearly as I could. If python has a more powerful > way to handle this situation, gladly do it! I will be happy as a clam to beta test or help with the coding. It's already been done, years ago, so nobody has to do it. There's already an OO system that works, with abstract and concrete classes, and with a rich operator overloading system. And it's already been used to give you all of the abstract and concrete numeric types you want, and they do the things you asked for in this section, all without having to do any jumps through virtual pointer tables. >> You proposed some complicated AI-based solution to solve the problem of using separate number classes in a single expression, even though Python (almost exactly like C++, in this case) has already solved that problem with operator overloading. > > No, I did not. I suggested that unifying numbers in an (AI) way could solve this problem (conceptually) by > regarding all numbers as PythonNumbers. So you didn't suggest a complicated AI-based solution, you suggested a complicated AI-based solution? > Decimals should not only be default, they should be integrated, not > tacked on with duck tape. How does that have anything to do with the first half of this paragraph? And in what way are Decimals "tacked on with duck tape"? They're instances of Number, and of Real. They act like numbers of other types, including interacting properly with other types like int. What is missing from the Decimal type and the ABCs in Number that makes you think we need a radical change? If all you're suggesting is moving Decimal from the decimal module to builtins and/or adding parser support for decimal literals, those are not sweeping changes, they're both very simple changes. (That doesn't necessarily mean they're _desirable_ changes, but that's another argument--an argument nobody can actually begin until you make it clear whether or not that's what you're suggesting, which can't happen until you learn enough about using Python to know what you're suggesting.) >> (And note that Python is flexible enough that third-party libraries can easily insert new types like quaternions, matrices, symbolic expressions, etc. into the hierarchy in a way that's transparent to end users. I can multiply a NumPy matrix of float64 values by the builtin in 2 just by writing "m * 2", and it works exactly the way you'd want it to. It's hard to imagine that would be even feasible with an AI-based solution, but with the current design, that's the easiest part of NumPy.) > > That's nice for you. Because sqrt(.23709) does not behave as I expect, sadly, I have to train my users to enter sqrt('0.23709'). How do you expect it to behave? Again, using decimal floats here would make no difference. Instead of needing an infinite number of binary digits, you need an infinite number of decimal digits. Dividing infinite by log2(10) still leaves infinity. If you're trying to fix that, you're not trying to fix Python, you're trying to fix irrational numbers. This list cannot help you with that. Prayer is the only option, but medieval mathematicians tried that and didn't get very far, and eventually we had to accept that there are numbers that cannot be represented finitely. >> There are some ideas in your posts that are worth responding to, > > Thank you. If a user goes to the time and trouble to present an idea clearly, I would expect the responders > to respect the effort and respond to the points that make sense. > > > Andrew, I respect you for taking the time to dialogue, I appreciate it. Thanks. > > marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Fri Mar 7 06:11:55 2014 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 06 Mar 2014 21:11:55 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53190936.6030608@canterbury.ac.nz> Message-ID: <5319551B.6000000@stoneleaf.us> On 03/06/2014 04:08 PM, Tim Peters wrote: > [Greg Ewing] >> ... >> Altogether, the whole thing seems to be a mess. > > Although a mess that fits in a thimble that successfully hid in a dark > corner unnoticed for a decade ;-) If the decade is now, it didn't go that long. I discovered this irritation within a year of learning Python, and at least three years ago brought it up on one of the mailing lists. I ended up making my own Date, Time, and DateTime classes. -- ~Ethan~ From harrismh777 at gmail.com Fri Mar 7 05:05:02 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 20:05:02 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140307034547.GO28804@ando> References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> <20140307034547.GO28804@ando> Message-ID: <5a9524af-1d00-4663-9bca-1d04bbbc4fea@googlegroups.com> On Thursday, March 6, 2014 9:45:47 PM UTC-6, Steven D'Aprano wrote: > Decimal is not a panacea. Both Decimal and binary floats have the same > limitations, they just occur in different places for different numbers. > All floating point numbers have these same issues. Fixed point numbers > have different issues, rationals have their own issues, and symbolic > computations have a different set of issues. > hi Steven, yes, I concur. My primary objection (for immediate concern) is that we have now a very fast module for doing decimal floating point math with less of the issues you speak of. Doing decimal floating point math by default, or at a minimum, providing a way to enter decimal numbers 1.234d would do a lot to alleviate much of the perceived difficulty with float issues. > > Computer maths is a leaky abstraction. No matter what you do, how you > implement it, the abstraction leaks. Not even Mathematica can entirely > hide the fact that it is computing rather than performing a Platonic > ideal of mathematics. > Again, I concur. Leaky is one thing... but being mired in 40-year-old paradigms because IEEE 754 1985 floats |doubles are so entrenched just doesn't make sense to me, and should be corrected. I am not insisting on Guido's "sweeping" reform. I'm just trying to make like a little easier for number munching and get folks to be forward thinking about moving to a decimal based floating point system of number for python by default---sometime. Thank you for your response, Steven. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Fri Mar 7 05:47:26 2014 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 06 Mar 2014 20:47:26 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <87lhwnp6n9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> <53187670.6070302@egenix.com> <87mwh3pfbt.fsf@uwakimon.sk.tsukuba.ac.jp> <87lhwnp6n9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <53194F5E.8070103@stoneleaf.us> On 03/06/2014 09:40 AM, Stephen J. Turnbull wrote: > Antoine Pitrou writes: > > Le 06/03/2014 15:33, Stephen J. Turnbull a ?crit : > > > > never get fixed, and that "if var:" which is actually testing for > > > identity with a false-y sentinel is still strongly discouraged. > > > > Why "strongly discouraged"? This is more of a style issue than anything > > else? > > No, it's not just a style issue. As Skip points out, it's a > *semantic* issue as well. Indeed, I have been bitten by using the lazy method of `if var` instead of `if var is not None`, and then been briefly puzzled as why my empty string | container | whatever that I passed in did not give me the correct results. I'm still all for having truthy midnights. :) -- ~Ethan~ From steve at pearwood.info Fri Mar 7 07:11:21 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 7 Mar 2014 17:11:21 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> Message-ID: <20140307061121.GQ28804@ando> On Thu, Mar 06, 2014 at 06:19:56PM -0800, Mark H. Harris wrote: > >>> from decimal import Decimal > >>> a=Decimal(1) > >>> b=Decimal(.1) > >>> a+b > Decimal('1.100000000000000005551115123') <==== does this not bother > you at all ? Of course it bothers people a little. It bothers me. It also bothers me when I'm too hot wearing a coat and too cold when I take it off, but sometimes that's how the universe works. For the first few releases of Decimal, it prohibited direct conversion of floats specifically to avoid that issue: # Python 2.5 py> decimal.Decimal(2.01) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/decimal.py", line 648, in __new__ "First convert the float to a string") TypeError: Cannot convert float to Decimal. First convert the float to a string But that turned out to be more of a nuisance than what it was trying to protect from, so starting in Python 2.7 Decimal now supports direct and exact conversion from float. The problem is, you are focused on one application for numeric computing to the exclusion of all else, specifically using Python as an interactive calculator. But in practice, for many uses, nobody typed in 2.01 and nobody has any expectation that it will be exactly the value 2.01. Rather, the value will be the result of some calculation, and there is *absolutely no reason to think* that the decimal number 2.01 will be more accurate than the binary number 10.101000111101011100001010001111010111000010100, or for that matter, the base-7 number 2.0462046204620462. The difference between those three representations is usually minor compared to the actual measurement errors of the initial data and the rounding errors from the calculation. -- Steven From harrismh777 at gmail.com Fri Mar 7 07:24:47 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 22:24:47 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <6F35C6C7-1809-4A3F-A7DF-E9EF8A628AE2@yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> <1394160815.26581.YahooMailNeo@web181002.mail.ne1.yahoo.com> <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> <6F35C6C7-1809-4A3F-A7DF-E9EF8A628AE2@yahoo.com> Message-ID: On Thursday, March 6, 2014 11:30:47 PM UTC-6, Andrew Barnert wrote: > > I answered Guido's questions in hopes that he might be willing to > dialogue --- not dismiss. > > > He was willing to dialogue, as evidenced by his initial replies. It was > only after you demonstrated your ignorance of basics fundamentals of Python > (as a user, not even about its implementation) and math/numerics, and > implied that you had no interest in correcting that ignorance, that he > dismissed you. And he has every right to do so. He's the one donating his > free time to make a great language for you (and many others) to use, not > the other way around. > Andrew, I demonstrated no such thing. This is the second time you have accused me of being ignorant of basics and fundamentals. My answers in no way (implied or otherwise) ignorant, they were well defined, carefully articulated, and implied an ernest interest in understanding and cooperation. Your *ad hominem* comments about my so-called ignorance do not become you and are beginning to annoy me... I don't see any reason for it. I know how the system works... and I think it can be improved. My ideas are unpopular, I realize that, but that does not mean that I am ignorant, nor does it mean that I don't understand python fundamentals. I had a professor one time who told us, "You know when you have won the argument when they attack you personally (or call you names)". Why don't we keep the discussion on the details relevant to the topic and leave the personal attacks alone? marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Fri Mar 7 07:39:35 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 22:39:35 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140307061121.GQ28804@ando> References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> <20140307061121.GQ28804@ando> Message-ID: <31615f5e-5429-4027-915d-8ceea251465e@googlegroups.com> On Friday, March 7, 2014 12:11:21 AM UTC-6, Steven D'Aprano wrote: > For the first few releases of Decimal, it prohibited direct conversion > of floats specifically to avoid that issue: > > # Python 2.5 > py> decimal.Decimal(2.01) > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.5/decimal.py", line 648, in __new__ > "First convert the float to a string") > TypeError: Cannot convert float to Decimal. First convert the float to a > string > > > But that turned out to be more of a nuisance than what it was > trying to protect from, so starting in Python 2.7 Decimal now > supports direct and exact conversion from float. hey Steven, whoa...! that is useful, and very interesting news. That almost makes me want to cry.... Wait a minute, I'm going to check it out, ... son of a gun, you're right. My Py2.6.1 does not allow me to enter this sqrt( .789 ). What-da-ya-know........ Here is the output: >>> from pdeclib import * >>> sqrt(.789) Traceback (most recent call last): File "", line 1, in File "pdeclib.py", line 243, in sqrt sqr=Decimal(x).sqrt() File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/decimal.py", line 652, in __new__ "First convert the float to a string") TypeError: Cannot convert float to Decimal. First convert the float to a string >>> So, "ignorant boy" finds out that the community has come to court with unclean hands ! Everyone (even the core devs) know that this little problem sucks, and they've tried to fix it in different ways, and yet when I bring it up its like (hypocrisy) I'm the one with the problem--- when in fact all along everyone knows that this little IED was going to go off and make a mess. ~nice. Steven, I honor you and thank you for being honest and coming clean on this. Geeze... I'm going to bed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harrismh777 at gmail.com Fri Mar 7 07:01:51 2014 From: harrismh777 at gmail.com (Mark H. Harris) Date: Thu, 6 Mar 2014 22:01:51 -0800 (PST) Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <6F35C6C7-1809-4A3F-A7DF-E9EF8A628AE2@yahoo.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> <1394160815.26581.YahooMailNeo@web181002.mail.ne1.yahoo.com> <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> <6F35C6C7-1809-4A3F-A7DF-E9EF8A628AE2@yahoo.com> Message-ID: <523d520b-54a6-4782-970d-c34a6ff50cfd@googlegroups.com> On Thursday, March 6, 2014 11:30:47 PM UTC-6, Andrew Barnert wrote: > > No one would expect that the user should know to quote the > number---when is that ever done? > > > What does quoting have to do with anything? Do you not understand why > Decimal('.1') works? It's not because Python is a weakly-typed language > that allows you to use strings as numbers, but because Decimal has a > constructor that takes strings, for a specific and well-documented reason. > Quoting here would just give you a TypeError. And nothing in your > proposal(s) would change that. > > I understand precisely what it happening. It is just the opposite of what you are implying (that I'm ignorant) which you actually state later. I full well know that the quoted string is forcing the right constructor to be called for the Decimal object. I am an experienced OO programmer and have many years under my belt with C++, Smalltalk, and Java. Please don't be pedantic with me, nor imply that I am ignorant. It does not become you, and it irritates me... besides, it gets in the way of discussion. My point is not about loose typing, nor about Decimal constructors, ... my point is that an average user entering a number into a sqrt() function is not going to realize that they need to enter a quoted string in order to force the string constructor on the Decimal Class !! They are going to want to enter this --> sqrt( .789 ) not this sqrt( '0.789' ) I know how it works. I'm asking for a reasonable response to the need for normal usability. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at bytereef.org Fri Mar 7 09:11:44 2014 From: stefan at bytereef.org (Stefan Krah) Date: Fri, 7 Mar 2014 09:11:44 +0100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> Message-ID: <20140307081144.GA6899@sleipnir.bytereef.org> Mark H. Harris wrote: > You can't be serious. You have not commented yet... are you happy with > this: > > >>> from decimal import Decimal > >>> a=Decimal(1) > >>> b=Decimal(.1) > >>> a+b > Decimal('1.100000000000000005551115123') <==== does this not bother you at > all ? You can set a trap: >>> getcontext().traps[FloatOperation] = True >>> b = Decimal(.1) Traceback (most recent call last): File "", line 1, in decimal.FloatOperation: [] >>> Stefan Krah From mertz at gnosis.cx Fri Mar 7 10:17:26 2014 From: mertz at gnosis.cx (David Mertz) Date: Fri, 7 Mar 2014 01:17:26 -0800 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <2f5ad6d3-d9e5-4866-a565-9b7a80977a1d@googlegroups.com> References: <46c0dc14-6eda-45d5-8c3d-5e73b0d13146@googlegroups.com> <20140305135646.GB28804@ando> <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <2f5ad6d3-d9e5-4866-a565-9b7a80977a1d@googlegroups.com> Message-ID: On Thu, Mar 6, 2014 at 6:51 PM, Mark H. Harris wrote: > I hate this: > >>> from decimal import Decimal > >>> a=Decimal(1) > >>> b=Decimal(.1) > >>> a+b > Decimal('1.100000000000000005551115123') > >>> > ... and I think the people who DO know intimately how python works, should > do something to fix it. > The problem here--and the problem with the "default number type is decimal" is that what you want fixed is "unfixable." As a number of other people have noted, what you are demanding is that numbers have finite sized and exact representations, which they simply don't and can't in computers with finite memory. Your example, Mark, is merely one where you have misspelled your Python code: >>> from decimal import Decimal as D >>> D('1') + D('.1') Decimal('1.1') Fix your spelling error, and in this case you get what you want. However, what about this: >>> D(1/3) * 3 Decimal('0.9999999999999999444888487687') There's no way to fix that spelling. Yes, you might be able to play with a decimal.Context in a way that gets this one example to happen to round the way you want it to, but no context will do so generically for every similar expected identity under reciprocal operators. By coincidence, this works under binary FB *because* of the limited precision of floats: >>> 1/3 * 3 1.0 But that's just luck, basically, it's not because we've managed to precisely represent 1/3 as a binary float. We don't have to look all that far for a problem case: >>> 1/49 * 49 0.9999999999999999 Of course, we do have Fractions, which will always do the right thing under the reciprocal division and multiplication operators: >>> F('1/3') * 3 Fraction(1, 1) Don't misspell this either, of course: >>> F(1/3) * 3 Fraction(18014398509481983, 18014398509481984) However, even if Fraction were to become the default numeric type for Python, and preserve the reciprocity of div/mul, that wouldn't help us any under the hoped reciprocals of sqrt() and square. Similarly, of course, for trigonometric identities and various other numeric functions that produce irrational answers. E.g.: >>> from fractions import Fraction as F >>> sqrt(F('1/3'))**2 0.3333333333333333 >>> F(sqrt(F('1/3'))**2) Fraction(6004799503160661, 18014398509481984) Well, that answer is a binary floating point; we leave Fraction land pretty easily in Python. The float we get, of course, is something that's not exactly 1/3 (but is pretty close). Even if we imagined some future version of Python that did sqrt() purely as a Fraction without converting to IEEE 754, we STILL couldn't ever have an exact identity. There simply does not exist any Fraction that can accurately represent sqrt(F('1/3')); there are only rational numbers that are "pretty close." Maybe this one, for example: >>> F(sqrt(F('1/3'))) Fraction(1300077228592327, 2251799813685248) Maybe this hypothetical Python 4000 that didn't do the conversion to floating point would produce a different approximation, but it would always be an approximation, not the Real (irrational) answer. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saghul at gmail.com Fri Mar 7 10:37:58 2014 From: saghul at gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=) Date: Fri, 07 Mar 2014 10:37:58 +0100 Subject: [Python-ideas] Extend socket.accept to put accepted socket in non-blocking mode Message-ID: <53199376.40007@gmail.com> Hi, (I hope this list is the right place for this) I was browsing around for accept4 usage in Python and I saw it's already used internally in socket.accept (on Linux only), albeit it's not exposed, so accepting an incoming connection and setting it to be non-blocking takes 3 syscalls. accept4 allows us to do this with a single syscall, and it made it into FreeBSD 10, so that's another system that could benefit from this optimization. Would it be desirable to extend socket.accept to something like: socket.accept(set_non_blocking=False) which would use accept4's flags on supported systems and fallback to regular fcntl on others? The idea is to accept an incoming connection and make it non-blocking at the same time, asyncio and other frameworks would benefit from this by doing one function call and 2 syscalls less (on supported systems, that is). Cheers, -- Sa?l Ibarra Corretg? bettercallsaghul.com From steve at pearwood.info Fri Mar 7 11:12:35 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 7 Mar 2014 21:12:35 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> References: <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> <1394160815.26581.YahooMailNeo@web181002.mail.ne1.yahoo.com> <260d6bdc-6030-49cb-aa07-94adde2473b0@googlegroups.com> Message-ID: <20140307101235.GR28804@ando> On Thu, Mar 06, 2014 at 07:53:15PM -0800, Mark H. Harris wrote: [...] > because it might be expected that the user should know how to construct > Decimals, and > could be educated to construct them properly--> Decimal('0.1'); I concur. > It is worse in these two scenarios (and others too): > sqrt(.1) > sin(.1) Decimal won't save you in those two cases. For square roots, the result is usually a surd, an irrational number. The only way to store surds exactly is to store it symbolically. Should we try to turn Python into Mathematica? In the case of sines, the same applies. While it is possible to calculate exact rational values for some angles, but for most the calculation rapidly becomes untenable, and in general trigonometric values are irrational, like surds. > No one would expect that the user should know to quote the > number---when is that ever done? OF COURSE WE DO. This is a programming language, not a calculator. We expect users -- programmers -- to know how to write functions, define classes, import modules, use regular expressions, call external processes, and so on. In other words, we expect them to know how to program. > QED this is broken. No it is not. Another factor you are not taking into account is that there is a reason that the computer industry has standardised on base-2 floats rather than 10. 30 years ago, it was quite common to find applications using some variant of Decimal, perhaps using BCD (binary coded decimal) as their native numeric format. Going back even further, computers were built using decimal-based hardware: http://en.wikipedia.org/wiki/Decimal_computer But people moved to binary for multiple reasons: - it's cheaper; - it's faster; - it's less surprising. For example, between 1 and 100000, about 12% of integer-valued floats fail the "1/(1/n) == n" test, but over 51% of the integer-valued Decimals: py> from decimal import Decimal as D py> sum(1/(1/n) != n for n in range(1, 100001)) 11846 py> sum(1/(1/D(n)) != n for n in range(1, 100001)) 51665 Likewise we can test how many fail the "(1/n)*n == 1" test: py> sum((1/n)*n != 1 for n in range(1, 100001)) 13117 py> sum((1/D(n))*n != 1 for n in range(1, 100001)) 36806 13% for floats versus 36% for Decimals. One more to prove it isn't a fluke: the "sqrt(n)**2 == n" test: py> sum((n**0.5)**2 != n for n in range(1, 100001)) 49544 py> sum((n**D("0.5"))**2 != n for n in range(1, 100001)) 71303 That's three for three in favour of binary floats. [...] > Yes, and at a bare minimum, that is the immediate change I have been > asking for, for now; nothing more. You're not going to get an immediate change, no matter how solid the case you ask for, no matter how logical the argument. Python 3.4 is not receiving any new features. The earliest this could come out is 3.5, in about 18 months or so. > I answered Guido's questions in hopes that he might be willing to > dialogue --- not dismiss. You've had at least three emails from Guido. That's three more than most radical or wild ideas receive. The fact that so many people are continuing to discuss this with you is proof that we recognise that computer maths is hard and unintuitive. But just because you have identified a problem doesn't mean that your answer is a solution. [...] > > You proposed some complicated AI-based solution to solve the problem of > > using separate number classes in a single expression, even though Python > > (almost exactly like C++, in this case) has already solved that problem > > with operator overloading. > > No, I did not. I suggested that unifying numbers in an (AI) way > could solve this problem (conceptually) by > regarding all numbers as *PythonNumbers. *Decimals should not only be > default, they should be integrated, not > tacked on with duck tape. It's statements like this that strongly suggest that you don't really understand how numbers work in computer programming. Or the practical limitations of what is *possible*. And as soon as you start talking about using an AI to decide what value the user intended, you've entered crackpot territory. Speaking of AIs, perhaps you ought to see what Wolfram Alpha is capable of: https://www.wolframalpha.com/input/?i=%28square+root+of+2.01%29+to+the+power+of+2 Not surprisingly for something with Mathematica behind it, it gets the exact right answer. Do you understand why Python the language cannot duplicate Mathematica's abilities with symbolic maths? Hint: it's not because it isn't technically possible. See, for example, libraries like sympy. -- Steven From steve at pearwood.info Fri Mar 7 11:16:22 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 7 Mar 2014 21:16:22 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140307061121.GQ28804@ando> References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <8eb523ca-9945-498b-99a6-ed2c9ed25082@googlegroups.com> <20140307061121.GQ28804@ando> Message-ID: <20140307101622.GS28804@ando> On Fri, Mar 07, 2014 at 05:11:21PM +1100, Steven D'Aprano wrote: [...] > there is *absolutely no reason to think* that the decimal number 2.01 > will be more accurate than the binary number > 10.101000111101011100001010001111010111000010100, or for that matter, > the base-7 number 2.0462046204620462. The difference between those three > representations is usually minor compared to the actual measurement > errors of the initial data and the rounding errors from the calculation. Er, apparently I cannot convert fractions into base 7 even using Python. That should be 2.003300330033 in base 7. The number I gave was actually 2.1. -- Steven From steve at pearwood.info Fri Mar 7 11:39:56 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 7 Mar 2014 21:39:56 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> Message-ID: <20140307103956.GT28804@ando> On Fri, Mar 07, 2014 at 11:38:34AM +1100, Chris Angelico wrote: > Hmm. Is the rounding done by float.__str__() an attractive nuisance? It's not *rounding* precisely. Starting in Python 3.1, the float __repr__ will display the shortest decimal string that doesn't change the float's value. Reading the issue tracker history for this change is informative: http://bugs.python.org/issue1580 To the guys who worked on that, I take my hat off to you all. -- Steven From solipsis at pitrou.net Fri Mar 7 11:40:39 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 7 Mar 2014 11:40:39 +0100 Subject: [Python-ideas] Extend socket.accept to put accepted socket in non-blocking mode References: <53199376.40007@gmail.com> Message-ID: <20140307114039.720efff9@fsol> On Fri, 07 Mar 2014 10:37:58 +0100 Sa?l Ibarra Corretg? wrote: > > accept4 allows us to do this with a single syscall, and it made it into > FreeBSD 10, so that's another system that could benefit from this > optimization. If it doesn't, then perhaps the configure script needs to be fixed. > The idea is to accept an incoming connection and make it non-blocking at > the same time, asyncio and other frameworks would benefit from this by > doing one function call and 2 syscalls less (on supported systems, that is). That's not likely to do a significant difference (benchmarks welcome). Regards Antoine. From rob.cliffe at btinternet.com Fri Mar 7 11:51:12 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Fri, 07 Mar 2014 10:51:12 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <87bnxipslm.fsf@uwakimon.sk.tsukuba.ac.jp> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <5318626F.5080203@btinternet.com> <20140306152936.3c990c46@anarchist.wooz.org> <53190A16.4020201@canterbury.ac.nz> <87bnxipslm.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5319A4A0.10905@btinternet.com> On 07/03/2014 03:58, Stephen J. Turnbull wrote: > Greg Ewing writes: > > Barry Warsaw wrote: > > > On Mar 06, 2014, at 11:56 AM, Rob Cliffe wrote: > > > > > >>Instances of existing code that would be broken by the change: 0 > > > > > > You can't know this because you can't audit all the Python code > > > in the world. > > > > I think he means instances that have been pointed out > > so far in this discussion. > > Well, either way it's a pretty careless claim. > > Please read what I actually said: Let's _start_ a survey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Fri Mar 7 11:57:32 2014 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 7 Mar 2014 21:57:32 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <862f6205-6b49-483a-a941-345f30bf60fb@googlegroups.com> References: <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> <862f6205-6b49-483a-a941-345f30bf60fb@googlegroups.com> Message-ID: <20140307105732.GU28804@ando> On Thu, Mar 06, 2014 at 06:08:28PM -0800, Mark H. Harris wrote: > If you write a number on paper do you write down '2.01' ? > Do you write down d(2.01) ? > Do you write down 2.01d ? Sometimes I write down 2.01 subscript 10. That's just a different way of spelling 2.01d. (That's the trouble with rhetorical questions. Sometimes people will give an answer other than what you were expecting.) > (or) do you write down 2.01 ? > > When you punch a number into your TI89 do you punch in {'} {2} {.} {0} > {1} {'} ? > (or) do you punch in {2} {.} {0} {1} ? For what it's worth, the TI-89 stores numbers using a decimal floating point format. -- Steven From rosuav at gmail.com Fri Mar 7 12:05:09 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 22:05:09 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <20140307103956.GT28804@ando> References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> <20140307103956.GT28804@ando> Message-ID: On Fri, Mar 7, 2014 at 9:39 PM, Steven D'Aprano wrote: > On Fri, Mar 07, 2014 at 11:38:34AM +1100, Chris Angelico wrote: > >> Hmm. Is the rounding done by float.__str__() an attractive nuisance? > > It's not *rounding* precisely. Starting in Python 3.1, the float > __repr__ will display the shortest decimal string that doesn't change > the float's value. > > Reading the issue tracker history for this change is informative: > > http://bugs.python.org/issue1580 > > To the guys who worked on that, I take my hat off to you all. That effect, yes. Let's call it "the magic of float.__str__", because it really is pretty amazing. But it's still post-processing magic. It means that strings appear to round-trip through floats, as long as you're a long way within the available precision; but as soon as you do operations, that ceases to be the case. I think it's great for display, but is putting that into __repr__ (at least, they do appear to be the same) an attractive nuisance, in that it encourages people to treat float("...") as a true representation? Don't get me wrong, it's a really *awesome* feature. It just happens to have been partially responsible for this thread, which I think is approaching 300 posts. ChrisA From rosuav at gmail.com Fri Mar 7 12:06:03 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 22:06:03 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> <20140307103956.GT28804@ando> Message-ID: On Fri, Mar 7, 2014 at 10:05 PM, Chris Angelico wrote: > Don't get me wrong, it's a really *awesome* feature. It just happens > to have been partially responsible for this thread, which I think is > approaching 300 posts. Whoops, no. This one's only approaching 100. It's the "should midnight be true or false" that's approaching 300. Sorry! ChrisA From rosuav at gmail.com Fri Mar 7 12:08:23 2014 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 7 Mar 2014 22:08:23 +1100 Subject: [Python-ideas] Extend socket.accept to put accepted socket in non-blocking mode In-Reply-To: <53199376.40007@gmail.com> References: <53199376.40007@gmail.com> Message-ID: On Fri, Mar 7, 2014 at 8:37 PM, Sa?l Ibarra Corretg? wrote: > The idea is to accept an incoming connection and make it non-blocking at the > same time, asyncio and other frameworks would benefit from this by doing one > function call and 2 syscalls less (on supported systems, that is). Is the benefit that it's simply more efficient, or is there a specific benefit from atomicity? The latter is a pretty strong argument (look at close-on-exec for instance), if it applies. ChrisA From saghul at gmail.com Fri Mar 7 12:14:04 2014 From: saghul at gmail.com (=?UTF-8?B?U2HDumwgSWJhcnJhIENvcnJldGfDqQ==?=) Date: Fri, 07 Mar 2014 12:14:04 +0100 Subject: [Python-ideas] Extend socket.accept to put accepted socket in non-blocking mode In-Reply-To: <20140307114039.720efff9@fsol> References: <53199376.40007@gmail.com> <20140307114039.720efff9@fsol> Message-ID: <5319A9FC.1010609@gmail.com> On 03/07/2014 11:40 AM, Antoine Pitrou wrote: > On Fri, 07 Mar 2014 10:37:58 +0100 > Sa?l Ibarra Corretg? > wrote: >> >> accept4 allows us to do this with a single syscall, and it made it into >> FreeBSD 10, so that's another system that could benefit from this >> optimization. > > If it doesn't, then perhaps the configure script needs to be fixed. > Probably not, I'll have a look. >> The idea is to accept an incoming connection and make it non-blocking at >> the same time, asyncio and other frameworks would benefit from this by >> doing one function call and 2 syscalls less (on supported systems, that is). > > That's not likely to do a significant difference (benchmarks welcome). > Actually, after http://hg.python.org/cpython/rev/5f0d1aad7322/ it's 2 function calls (accept + set_blocking)+ 2 syscalls (accept + ioctl FIONBIO) vs 1 function call (accept) + 1 syscall (accept4). -- Sa?l Ibarra Corretg? bettercallsaghul.com From rob.cliffe at btinternet.com Fri Mar 7 12:13:29 2014 From: rob.cliffe at btinternet.com (Rob Cliffe) Date: Fri, 07 Mar 2014 11:13:29 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <1394158163.96645.YahooMailNeo@web181005.mail.ne1.yahoo.com> Message-ID: <5319A9D9.8000302@btinternet.com> On 07/03/2014 02:16, Tim Peters wrote: > [Tim] >>> No, it's bizarre to attach a timezone to a time object because most >>> tzinfo subclasses don't - and can't - know what to return for the UTC >>> offset in the absence of - at least - month and day info too. Hour, >>> minute, second and microsecond aren't usually enough to determine >>> whether "daylight time" is in effect, and most tzinfo subclasses do >>> attempt to model daylight time. And because daylight time is a >>> political conceit, most tzinfo subclasses also need year info. That >>> has nothing to do with whether times are viewed abstractly, >>> concretely, etc - it has to do with that time zones generally aren't >>> _defined_ in terms of isolated time-of-day info. It's 7:13 PM in US >>> Central. Is that daylight (CDT) or standard (CST) time? It's >>> impossible to answer. What's the corresponding UTC time? Ditto. > [Andrew Barnert ] >> Well, a time in Central is useless, but a time in CDT or CST is not, and you can >> design a library that's smart enough to give you a CDT or CST (as appropriate) time >> from a Central datetime. > Tell me how. You have, in context, a Python `time` object with a > "Central" tzinfo member. That's all you get from the user. You're > given absolutely no information about day, month, or year. What's > your algorithm for implementing picking CDT or CST "as appropriate"? > Note that we're NOT talking about datetime.datetime objects here. > These are datetime.time objects. > > This isn't a problem for datetime.datetime objects. A "Central" > tzinfo timeclass has no problem at all picking CDT or CST as > appropriate given all the info in a datetime.datetime object. > _______________________________________________ > Guys, please. This discussion is getting increasingly esoteric and has become irrelevant to the original proposition. What it does show is that the current truthy behaviour of time objects is incomprehensible to the average programmer. And therefore useless to her. Rob Cliffe From p.f.moore at gmail.com Fri Mar 7 14:00:10 2014 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 7 Mar 2014 13:00:10 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5319A9D9.8000302@btinternet.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <1394158163.96645.YahooMailNeo@web181005.mail.ne1.yahoo.com> <5319A9D9.8000302@btinternet.com> Message-ID: On 7 March 2014 11:13, Rob Cliffe wrote: > Guys, please. This discussion is getting increasingly esoteric and has > become irrelevant to the original proposition. Everything here is irrelevant to the original proposition. The bug report has been reopened. The next (relevant) step is to create a patch and post it to the bug report. Everything else is just people having a chat... Paul From dickinsm at gmail.com Fri Mar 7 14:07:15 2014 From: dickinsm at gmail.com (Mark Dickinson) Date: Fri, 7 Mar 2014 13:07:15 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <1F349B3B-7D36-402F-B9FE-93D7EC11FEF8@stufft.io> <5318336F.7030009@egenix.com> <53184EE4.80105@egenix.com> <53185658.5080507@egenix.com> Message-ID: On Thu, Mar 6, 2014 at 12:08 PM, Nick Coghlan wrote: > Now, let's consider the time with the *best* possible claim to being > false: timestamp zero. How does that behave? > > [... snipped ...] > So, unless I happen to live in UTC, it's highly unlikely that I'm > going to infer from Python's *behaviour* that datetime.time() (unlike > datetime.date() and datetime.datetime()) belong in the "number" > category, rather than the "arbitrary object" category. > This one's even *more* fun if you live in the UK. I live on the Greenwich Meridian (and I mean that quite literally: it goes through the middle of my living room), and since the epoch was in January, well away from British Summer Time, I shouldn't see any of those pesky timezone-related problems that those poor underprivileged people living in non-UTC timezones see. Right? Here's Python 2.7 on my Mac laptop, whose timezone is set to London time: >>> import datetime as dt >>> bool(dt.datetime.fromtimestamp(0).time()) True And on Windows (again with timezone set to the UK): >>> import datetime as dt >>> bool(dt.datetime.fromtimestamp(0).time()) False Wait, what? It turns out that in January 1970, the UK government was in the middle of an experimental change to a year-round GMT+1 timezone. Some operating systems seem to be aware of that fact; some aren't. Count me in the bool(time(0)) should be True camp, by the way. -- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From breamoreboy at yahoo.co.uk Fri Mar 7 15:41:18 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Fri, 07 Mar 2014 14:41:18 +0000 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5319A9D9.8000302@btinternet.com> References: <201403051216.12392.shai@platonix.com> <53179F55.3080501@egenix.com> <85siqwcmvt.fsf@benfinney.id.au> <5317A696.8040605@egenix.com> <53181ADA.2030401@canterbury.ac.nz> <5318F8F2.5010209@canterbury.ac.nz> <1394158163.96645.YahooMailNeo@web181005.mail.ne1.yahoo.com> <5319A9D9.8000302@btinternet.com> Message-ID: On 07/03/2014 11:13, Rob Cliffe wrote: > > On 07/03/2014 02:16, Tim Peters wrote: >> [Tim] >>>> No, it's bizarre to attach a timezone to a time object because most >>>> tzinfo subclasses don't - and can't - know what to return for the UTC >>>> offset in the absence of - at least - month and day info too. Hour, >>>> minute, second and microsecond aren't usually enough to determine >>>> whether "daylight time" is in effect, and most tzinfo subclasses do >>>> attempt to model daylight time. And because daylight time is a >>>> political conceit, most tzinfo subclasses also need year info. That >>>> has nothing to do with whether times are viewed abstractly, >>>> concretely, etc - it has to do with that time zones generally aren't >>>> _defined_ in terms of isolated time-of-day info. It's 7:13 PM in US >>>> Central. Is that daylight (CDT) or standard (CST) time? It's >>>> impossible to answer. What's the corresponding UTC time? Ditto. >> [Andrew Barnert ] >>> Well, a time in Central is useless, but a time in CDT or CST is not, >>> and you can >>> design a library that's smart enough to give you a CDT or CST (as >>> appropriate) time >>> from a Central datetime. >> Tell me how. You have, in context, a Python `time` object with a >> "Central" tzinfo member. That's all you get from the user. You're >> given absolutely no information about day, month, or year. What's >> your algorithm for implementing picking CDT or CST "as appropriate"? >> Note that we're NOT talking about datetime.datetime objects here. >> These are datetime.time objects. >> >> This isn't a problem for datetime.datetime objects. A "Central" >> tzinfo timeclass has no problem at all picking CDT or CST as >> appropriate given all the info in a datetime.datetime object. >> _______________________________________________ >> > Guys, please. This discussion is getting increasingly esoteric and has > become irrelevant to the original proposition. > What it does show is that the current truthy behaviour of time objects > is incomprehensible to the average programmer. And therefore useless to > her. > Rob Cliffe I disagree. People here have stated that they use it. I could use it if I wanted to, having been raised to do some strange things, as in read docs, so I'm firmly in favour of sticking with the status quo. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From stephen at xemacs.org Fri Mar 7 15:59:38 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 07 Mar 2014 23:59:38 +0900 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> <20140307103956.GT28804@ando> Message-ID: <878usmoy05.fsf@uwakimon.sk.tsukuba.ac.jp> Chris Angelico writes: > That effect, yes. Let's call it "the magic of float.__str__", because > it really is pretty amazing. > > But it's still post-processing magic. It means that strings appear to > round-trip through floats, as long as you're a long way within the > available precision; but as soon as you do operations, that ceases to > be the case. I think it's great for display, but is putting that into > __repr__ (at least, they do appear to be the same) an attractive > nuisance, in that it encourages people to treat float("...") as a true > representation? What makes you think they need more encouragment? Seriously, as one data point, I don't think having more "human" representations encourages me the think of floating point results as the product of arithmetic on real numbers. I don't think anybody who knows how tricky "floating point" arithmetic can be is going to be fooled by the "pretty eyes" of a number represented as "2.0" rather than "1.99999999999999743591". From rosuav at gmail.com Fri Mar 7 16:09:12 2014 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 8 Mar 2014 02:09:12 +1100 Subject: [Python-ideas] Python Numbers as Human Concept Decimal System In-Reply-To: <878usmoy05.fsf@uwakimon.sk.tsukuba.ac.jp> References: <41b59536-c503-4105-a89b-61cbaf493dc1@googlegroups.com> <3452d513-0f5a-4365-96c3-c593263daa7d@googlegroups.com> <9ebb139a-8b51-451e-83a1-a4011b0cd4c2@googlegroups.com> <9a4504fb-a5a9-4a9b-a07e-d004ebee96e7@googlegroups.com> <20140307103956.GT28804@ando> <878usmoy05.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Sat, Mar 8, 2014 at 1:59 AM, Stephen J. Turnbull wrote: > Seriously, as one data point, I don't think having more "human" > representations encourages me the think of floating point results as > the product of arithmetic on real numbers. I don't think anybody who > knows how tricky "floating point" arithmetic can be is going to be > fooled by the "pretty eyes" of a number represented as "2.0" rather > than "1.99999999999999743591". Fair enough. I just remember reading, back in my really REALLY early days with GW-BASIC, an explanation of why 3.2# (the hash made it double-precision) came out as whatever-it-did. Went into a full explanation of the nature of binary floating point, and the issue was forced to your attention because just about _any_ value that wasn't a neat multiple of a (negative) power of two would do that. You can lead a programmer to docs, but you can't make him understand. ChrisA From stephen at xemacs.org Fri Mar 7 16:53:55 2014 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 08 Mar 2014 00:53:55 +0900 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <5319A4A0.10905@btinternet.com> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <5318626F.5080203@btinternet.com> <20140306152936.3c990c46@anarchist.wooz.org> <53190A16.4020201@canterbury.ac.nz> <87bnxipslm.fsf@uwakimon.sk.tsukuba.ac.jp> <5319A4A0.10905@btinternet.com> Message-ID: <877g86ovho.fsf@uwakimon.sk.tsukuba.ac.jp> Rob Cliffe writes: > Please read what I actually said: > ??? Let's start a survey. Ah, OK. You started a survey, but don't care if it is accurate. I remain deeply unimpressed with your methodology. From guido at python.org Fri Mar 7 18:17:45 2014 From: guido at python.org (Guido van Rossum) Date: Fri, 7 Mar 2014 09:17:45 -0800 Subject: [Python-ideas] Please reconsider the Boolean evaluation of midnight In-Reply-To: <877g86ovho.fsf@uwakimon.sk.tsukuba.ac.jp> References: <201403051216.12392.shai@platonix.com> <201403051805.15363.shai@platonix.com> <201403051838.25342.shai@platonix.com> <5317BF90.9030901@btinternet.com> <5318626F.5080203@btinternet.com> <20140306152936.3c990c46@anarchist.wooz.org> <53190A16.4020201@canterbury.ac.nz> <87bnxipslm.fsf@uwakimon.sk.tsukuba.ac.jp> <5319A4A0.10905@btinternet.com> <877g86ovho.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: If I had to do it over again I would *definitely* never make a time value "falsy". The datetime module was conceived long ago, when the dangers of falsy objects that weren't clearly trying to be "like numbers" or "like collections" weren't so clear. Today I would argue that times aren't enough "like numbers" to qualify. The only question left in my mind is how safe it is to change the current behavior, given that it's been documented and implemented for over a decade. If this was for Python 3.0 (or even 3.1) I would definitely vote for fixing it, damn the torpedoes. But given that we're talking about 3.5, I'm more hesitant. It's also not something for which a deprecation warning would work well. (When would it be issued? Whenever bool(