Gregory Ewing :
> Marko Rauhamaa wrote:
>> It might even be tail-call optimized by Python. Only you can't count
>> on it because the language spec doesn't guarantee it.
>
> The language spec might permit it, but the BDFL has explicitly
> expressed a dislike for the idea of implicit tail call remo
Hi All,
I'm pleased to announce the release of xlrd 0.9.4:
http://pypi.python.org/pypi/xlrd/0.9.4
This release includes the following changes:
- Automated tests are now run on Python 3.4
- Use ElementTree.iter() if available, not deprecated getiterator()
when parsing xlsx files.
- Fix #106
Marko Rauhamaa wrote:
It might even be tail-call optimized by Python. Only you can't count on
it because the language spec doesn't guarantee it.
The language spec might permit it, but the BDFL has
explicitly expressed a dislike for the idea of implicit
tail call removal, so it's unlikely to ev
On Wed, Jul 15, 2015 at 11:01 AM, Terry Reedy wrote:
> On 7/14/2015 1:52 PM, Chris Angelico wrote:
>>
>> On Wed, Jul 15, 2015 at 3:43 AM, Marko Rauhamaa wrote:
>>>
>>> I don't like the way integer overflows are explicitly undefined in
>>> modern C.
>>>
>>> Similarly, I don't like the way tail cal
On Tue, 14 Jul 2015 17:31:31 -0700 (PDT), trentonwesle...@gmail.com
wrote:
>Greetings!
>You been Invited as a Beta User for TheGongzuo.com ( Absolutely Extended
>Trial).
>We bring to you TheGongzuo.com, Top notch highly talented IT (Information
>Technology / Software Industry) skilled Profession
I think I'm beginning to understand. Tail call elimination is
necessary to cope with a system of programming that has deliberately
excluded certain other options (eg mutables, in pure functional
languages),
Tail recursion is the functional way to write a while loop. To put is
another way, a
On 7/14/2015 1:52 PM, Chris Angelico wrote:
On Wed, Jul 15, 2015 at 3:43 AM, Marko Rauhamaa wrote:
I don't like the way integer overflows are explicitly undefined in
modern C.
Similarly, I don't like the way tail call behavior is undefined in
Python.
Where in the Python spec is it stated tha
On 7/14/2015 10:02 AM, Antoon Pardon wrote:
On 07/14/2015 03:43 PM, Chris Angelico wrote:
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa wrote:
No, tail call optimization doesn't change the behavior of the program,
for the worse anyway.
It does, because you lose traceback records. That's
Greetings!
You been Invited as a Beta User for TheGongzuo.com ( Absolutely Extended Trial).
We bring to you TheGongzuo.com, Top notch highly talented IT (Information
Technology / Software Industry) skilled Professional Candidates, where you can
find more than a resume.
___
On 7/14/2015 1:15 AM, Paul Rubin wrote:
def quicksort(array, start, end):
midp = partition(array, start, end)
if midp <= (start+end)//2:
quicksort(array, start, midp)
quicksort(array, midp+1, end)
else:
quicksort(array, midp+1, end)
quicks
On 15/07/2015 00:40, Mark Lawrence wrote:
On 13/07/2015 23:46, Terry Reedy wrote:
Optimizing specific tail calls is tricker. For one thing, calls to a
recursion-replacement function, such as recur, add a stack frame that
must also be popped. A CPython bytecode manimpuation solution was given
y
On 13/07/2015 23:46, Terry Reedy wrote:
Optimizing specific tail calls is tricker. For one thing, calls to a
recursion-replacement function, such as recur, add a stack frame that
must also be popped. A CPython bytecode manimpuation solution was given
years ago as a recipe on the ActiveState Pyt
On 7/14/2015 11:43 AM, Mark Lawrence wrote:
On 14/07/2015 16:21, Michael Torrie wrote:
You make a good point. Although Tk is considered part of the standard
Python library (though optional),
Python-coded tkinter depends on C-coded _tkinter and both are in the
stdlib, which means the code i
On Wed, Jul 15, 2015 at 5:09 AM, Terry Reedy wrote:
>> it wouldn't surprise
>> me if there are odd problems where something just doesn't work. Can
>> you reproduce the problem on Win 7 or newer? If it's just an XP
>> problem, I suspect the devs won't be very much interested in fixing it
>> (althou
Chris Angelico :
> Tail call elimination is necessary to cope with a system of
> programming that has deliberately excluded certain other options (eg
> mutables, in pure functional languages),
Tail call elimination is necessary for the functional programming style.
While Scheme strongly promotes
On 7/14/2015 7:56 AM, Chris Angelico wrote:
On Tue, Jul 14, 2015 at 8:15 AM, Colin Dick wrote:
when I run the downloaded version of this pgm "python-3.5.0b3.exe"
there are no visible selection box's except "cancel" on the
first screen shown
see the attached screen dump
its running on a win
On Wed, Jul 15, 2015 at 4:37 AM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Tail call behaviour is not undefined in Python. There is a strong
>> convention (followed by all implementations I know of) to follow the
>> reference implementation's (CPython) behaviour, which is not to
>> optimize t
Steven D'Aprano :
> Tail call behaviour is not undefined in Python. There is a strong
> convention (followed by all implementations I know of) to follow the
> reference implementation's (CPython) behaviour, which is not to
> optimize tail calls. But even if an implementation chooses to not
> follo
On 2015-07-14, Chris Angelico wrote:
> On Wed, Jul 15, 2015 at 3:28 AM, Grant Edwards
> wrote:
>> Comparing the size of Tcl+Tk and wx/Gtk doesn't really make sense
>> either since we're talking about MS Windows targets. Gtk isn't
>> involved. wxWindows on MS Windows runs on top of native widg
On Wed, 15 Jul 2015 03:43 am, Marko Rauhamaa wrote:
> The problem there is in the C standard, not the compiler that complies
> with the standard.
>
> I don't like the way integer overflows are explicitly undefined in
> modern C.
>
> Similarly, I don't like the way tail call behavior is undefined
Steven D'Aprano writes:
> Here's an example where an overzealous but standards-conforming optimization
> introduced a security bug:
> http://code.google.com/p/nativeclient/issues/detail?id=245
In that particular example, the refactored code simply looks wrong.
--
https://mail.python.org/mailman/
On Wed, Jul 15, 2015 at 3:43 AM, Marko Rauhamaa wrote:
> I don't like the way integer overflows are explicitly undefined in
> modern C.
>
> Similarly, I don't like the way tail call behavior is undefined in
> Python.
Where in the Python spec is it stated that tail call behaviour is
undefined? The
On Wed, 15 Jul 2015 03:29 am, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa
>> wrote:
>>> No, tail call optimization doesn't change the behavior of the
>>> program, for the worse anyway.
>>
>> It does, because you lose traceback records. That's pr
Steven D'Aprano :
> C, in my opinion, is the poster child for how a programming language
> should NOT be designed, and I don't want Python to go down the same
> path. John Regehr writes:
>
> "... there are compilers (like GCC) where integer overflow behaved a
> certain way for many years and then
On Wed, Jul 15, 2015 at 3:28 AM, Grant Edwards wrote:
> Comparing the size of Tcl+Tk and wx/Gtk doesn't really make sense
> either since we're talking about MS Windows targets. Gtk isn't
> involved. wxWindows on MS Windows runs on top of native widgets, not
> on top of Gtk.
Well, let's look at
On Tue, 14 Jul 2015 06:33 pm, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> On Mon, Jul 13, 2015 at 11:57 PM, Marko Rauhamaa
>> wrote:
>>> How about "return"?
>>
>> I think you miss my point entirely. "return" doesn't mean tail-call
>> optimize;
>
> Why not?
Because then you lose most of your debug
Chris Angelico :
> You're proposing making _every_ instance of "return func(...)" into
> this kind of thing.
Yes.
> That's not always recursion,
Correct.
> and it's certainly not always clear what called what to get you there.
Correct.
Marko
--
https://mail.python.org/mailman/listinfo/pyth
Chris Angelico :
> On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa wrote:
>> No, tail call optimization doesn't change the behavior of the
>> program, for the worse anyway.
>
> It does, because you lose traceback records. That's pretty significant
> when you come to try to debug something.
Does
On 2015-07-14, Mark Lawrence wrote:
> On 14/07/2015 16:21, Michael Torrie wrote:
>>> Why would you have to ship "extra" libraries for Windows? Extra
>>> compared to what? When I compared bundled apps for Windows using wx
>>> and Tk, you had to ship more libraries using Tk than you did with wx.
Ian Kelly :
> On Tue, Jul 14, 2015 at 2:33 AM, Marko Rauhamaa wrote:
>> The programmer shouldn't be controlling tail call optimizations.
>
> The programmer controls it regardless.
>
> return foo() # TCO
>
> result = foo() # No TCO
> return result # No TCO
Not necessarily. Compile
On Wed, 15 Jul 2015 01:43 am, Mark Lawrence wrote:
> Surely if Tk is optional then IDLE is also optional, as IDLE depends on
> Tk? But I thought that IDLE was always supplied with Python, so am I
> missing something, or am I simply plain wrong, or what?
If you try to run IDLE on a system that do
On 14/07/2015 16:21, Michael Torrie wrote:
On 07/14/2015 08:06 AM, Grant Edwards wrote:
On 2015-07-14, Michael Torrie wrote:
On 07/13/2015 08:42 AM, Grant Edwards wrote:
If it didn't have to run on Windows, I'd pick pygtk over wx. I've
never tried qt.
PyQt is very nice to work with. In so
On 07/14/2015 08:06 AM, Grant Edwards wrote:
> On 2015-07-14, Michael Torrie wrote:
>> On 07/13/2015 08:42 AM, Grant Edwards wrote:
>>> If it didn't have to run on Windows, I'd pick pygtk over wx. I've
>>> never tried qt.
>>
>> PyQt is very nice to work with. In some respects it's not as Pythoni
On 2015-07-14, Michael Torrie wrote:
> On 07/13/2015 08:42 AM, Grant Edwards wrote:
>> If it didn't have to run on Windows, I'd pick pygtk over wx. I've
>> never tried qt.
>
> PyQt is very nice to work with. In some respects it's not as Pythonic
> as PyGTK. It feels a lot like transliterated C+
On Wed, Jul 15, 2015 at 12:02 AM, Antoon Pardon
wrote:
> On 07/14/2015 03:43 PM, Chris Angelico wrote:
>> On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa wrote:
>>> Chris Angelico :
>>>
On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa wrote:
> I would rather optimize by default and dis
On 2015-07-14, Ian Kelly wrote:
> And yet, Python somehow manages to gain new features with each release.
>
> The reason why most proposals get rejected is because most proposals
> are bad. If every idea that came along just got accepted, we'd have a
> disastrous hodge-podge of a language.
And P
On 07/14/2015 03:43 PM, Chris Angelico wrote:
> On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa wrote:
I would rather optimize by default and disable optimizations with
--debug or equivalent.
>>> That as
On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa wrote:
>>> I would rather optimize by default and disable optimizations with
>>> --debug or equivalent.
>>
>> That assumes that it's simply an optimization. This is a d
Chris Angelico :
> On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa wrote:
>> I would rather optimize by default and disable optimizations with
>> --debug or equivalent.
>
> That assumes that it's simply an optimization. This is a distinct
> semantic change.
No, tail call optimization doesn't ch
On Tue, Jul 14, 2015 at 2:33 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> On Mon, Jul 13, 2015 at 11:57 PM, Marko Rauhamaa wrote:
>>> How about "return"?
>>
>> I think you miss my point entirely. "return" doesn't mean tail-call
>> optimize;
>
> Why not?
>
>> it just means to return the result.
>
On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Done explicitly like this, it avoids the problem of bad tracebacks,
>> because by definition you would use it only when you want the current
>> stack frame to be dropped. I wonder how hard it would be to hack this
>> i
Chris Angelico :
> Done explicitly like this, it avoids the problem of bad tracebacks,
> because by definition you would use it only when you want the current
> stack frame to be dropped. I wonder how hard it would be to hack this
> into CPython... Anyone feel like tackling it?
I would rather opt
Chris Angelico :
> On Tue, Jul 14, 2015 at 3:41 PM, Marko Rauhamaa wrote:
>> Tail-call optimization has nothing to do with converting algorithms into
>> iterations. It's a prosaic trick of dropping an unneeded stack frame
>> before making a function call.
>>
>>> The claim that TCO means you don't
On Tue, Jul 14, 2015 at 8:15 AM, Colin Dick wrote:
> when I run the downloaded version of this pgm "python-3.5.0b3.exe"
>
> there are no visible selection box's except "cancel" on the
> first screen shown
>
> see the attached screen dump
>
> its running on a win xp sp3 as a vmware vm
>
As of Pyt
On Tue, Jul 14, 2015 at 7:20 AM, Thomas Via wrote:
> I’m trying to reinstall Python 2.7.9/2.7.10, but during the installation, it
> didn’t let me, which gave me this:
>
> "There is a problem with this Windows Installer package. A program required
> for this install to complete could not be run. Co
On Tue, Jul 14, 2015 at 3:41 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> That's a prime example of recursion... but not of recursion that can
>> be tail-call optimized into iteration. It's an example of forking
>> recursion, where one call can result in multiple calls (same with tree
>> tra
On Tue, Jul 14, 2015 at 3:41 PM, Marko Rauhamaa wrote:
> Tail-call optimization has nothing to do with converting algorithms into
> iterations. It's a prosaic trick of dropping an unneeded stack frame
> before making a function call.
>
>> The claim that TCO means you don't need stack space for all
On 07/14/2015 10:34 AM, Ian Kelly wrote:
> On Tue, Jul 14, 2015 at 1:26 AM, Antoon Pardon
> wrote:
>> I expect any example given, to be used as a contest by those reading,
>> for finding
>> the least warped alternative and then using that to dismiss the example.
>>
>> So I really don't feel compel
Ian Kelly :
> On Mon, Jul 13, 2015 at 11:57 PM, Marko Rauhamaa wrote:
>> How about "return"?
>
> I think you miss my point entirely. "return" doesn't mean tail-call
> optimize;
Why not?
> it just means to return the result.
Same difference.
> This is what led to the confusion responsible for
On Tue, Jul 14, 2015 at 1:26 AM, Antoon Pardon
wrote:
> On 07/14/2015 05:20 AM, Steven D'Aprano wrote:
>> On Tue, 14 Jul 2015 12:05 am, Chris Angelico wrote:
>>
>>> If you want to make an assertion that iterative
>>> code requires equivalent warping to tail-recursive code, I want to see
>>> an exa
On Tue, Jul 14, 2015 at 7:13 AM, Chris Angelico wrote:
> On Tue, Jul 14, 2015 at 2:58 PM, Steven D'Aprano
> wrote:
> > On Tuesday 14 July 2015 14:07, Ian Kelly wrote:
> >
> >> On Mon, Jul 13, 2015 at 9:23 PM, Steven D'Aprano
> >> wrote:
> >>> Correct. But rather than removing it, it would be be
On Mon, Jul 13, 2015 at 11:57 PM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> On Mon, Jul 13, 2015 at 11:25 PM, Chris Angelico wrote:
>>> (Also, side point: Python can't actually optimize the above function,
>>> because it actually means "call quicksort, then discard its return
>>> value and return
On 14/07/2015 03:16, Michael Torrie wrote:
On 07/13/2015 08:42 AM, Grant Edwards wrote:
If it didn't have to run on Windows, I'd pick pygtk over wx. I've
never tried qt.
PyQt is very nice to work with. In some respects it's not as Pythonic
as PyGTK. It feels a lot like transliterated C++ co
On 14/07/2015 07:29, Gregory Ewing wrote:
Marko Rauhamaa wrote:
Ian Kelly :
Another point in favor of an explicit tail-call keyword. Then one
couldn't make that mistake.
How about "return"?
How about "goto"? :-)
Why not "goto"? It's use is scattered throughout the cpython code, and
to
Hello. I have a problem installing/uninstalling python.
I’m trying to reinstall Python 2.7.9/2.7.10, but during the installation, it
didn’t let me, which gave me this:
"There is a problem with this Windows Installer package. A program required for
this install to complete could not be
On 07/14/2015 05:20 AM, Steven D'Aprano wrote:
> On Tue, 14 Jul 2015 12:05 am, Chris Angelico wrote:
>
>> If you want to make an assertion that iterative
>> code requires equivalent warping to tail-recursive code, I want to see
>> an example of it. Is that difficult?
> Of course it is. If it wasn't
Gregory Ewing :
> Marko Rauhamaa wrote:
>> How about "return"?
>
> How about "goto"? :-)
>
> That's not entirely an unserious suggestion -- if you
> really believe that a "goto with arguments" is a good
> feature for a language to have, you shouldn't be
> afraid to spell it as such.
>
> def quic
57 matches
Mail list logo
