On 1/9/2012 2:45 AM, Robert Kern wrote:
On 1/9/12 5:35 AM, John Nagle wrote:
Python has some serious problems that preclude optimization.
Basically, the language is designed to be run by a naive (non-optimizing)
interpreter, and allows things that are easy
for such an implementation but very to
On 01/09/2012 04:35 PM, John Nagle wrote:
A type-inferring compiler has to analyze the whole program at
once, because the type of a function's arguments is determined
by its callers. This is slow. The alternative is to guess
what the type of something is likely to be, compile code at
run time, an
On 1/9/12 5:35 AM, John Nagle wrote:
Python has some serious problems that preclude optimization.
Basically, the language is designed to be run by a naive (non-optimizing)
interpreter, and allows things that are easy
for such an implementation but very tough to optimize. An
example is the abilit
On 1/3/2012 6:15 PM, alex23 wrote:
On Jan 4, 6:38 am, Terry Reedy wrote:
Shredskin compiles a subset of
Python, or a subset of usages, to C, with similar benefits.
That is, of course, 'Shedskin' and 'C++' :)
+1 for either Cython or Shedskin as your next step for more performant
Python.
Terry Reedy於 2012年1月5日星期四UTC+8上午4時22分03秒寫道：
> On 1/4/2012 1:37 AM, Terry Reedy wrote:
> > On 1/3/2012 8:04 PM, Devin Jeanpierre wrote:
>
> >> [ An example of a simple dependently typed program:
> >> http://codepad.org/eLr7lLJd ]
> >
> > Just got it after a minute delay.
>
> A followup now that I
> where n,m are compiler variables used to define the dependent
> (paramaterized) types array(int,n) and int(n)/ The double use of n means
> that the compiler checks that length n of the array equals the length
> passed.
>
> My response: in Python, there is no need to pass concrete collection sizes
On 1/4/2012 1:37 AM, Terry Reedy wrote:
On 1/3/2012 8:04 PM, Devin Jeanpierre wrote:
[ An example of a simple dependently typed program:
http://codepad.org/eLr7lLJd ]
Just got it after a minute delay.
A followup now that I have read it. Removing the 40 line comment, the
function itself is
On Wed, 2012-01-04 at 11:30 -0300, Sean Wolfe wrote:
> On Tue, Jan 3, 2012 at 7:28 PM, Ben Finney wrote:
> > Sean Wolfe writes:
> >
> >> Hello everybody, I'm a happy pythonista newly subscribed to the group.
> >
> > Welcome!
>
> Thanks! and thanks to all, hjaha.
>
> >
> >> I have a theoretical
On 1/4/2012 12:37 AM, Terry Reedy wrote:
>
> Using induction, I can prove, for instance, that these two functions
> [snip]
> are equivalent, assuming enough stack and normal procedural Python
> semantics. (And assuming no typos ;-).
YOU proved that; your type system didn't. With a powerful enough
On Tue, Jan 3, 2012 at 7:28 PM, Ben Finney wrote:
> Sean Wolfe writes:
>
>> Hello everybody, I'm a happy pythonista newly subscribed to the group.
>
> Welcome!
Thanks! and thanks to all, hjaha.
>
>> I have a theoretical / philosophical question regarding strong vs duck
>> typing in Python. Let'
> Since Python does not 'silently convert types' as I understand those 3
> words, you lose me here. Can you give a code example of what you mean?
I mean the reasoning behind the arguments like
'X isn't strongly typed because 2 + "3" = 5 but "3" + 2 = "32"'.
OCaml considers this a problem and bans
On 1/3/2012 8:04 PM, Devin Jeanpierre wrote:
Can you give an actual example of such a definition of 'strongly typed
object' that excludes Python objects?
I'd love to, but I neglected to above because I don't really know
where we share ideas, and I wouldn't want to jump ahead and say
something
On Jan 4, 6:38 am, Terry Reedy wrote:
> Shredskin compiles a subset of
> Python, or a subset of usages, to C, with similar benefits.
That is, of course, 'Shedskin' and 'C++' :)
+1 for either Cython or Shedskin as your next step for more performant
Python.
--
http://mail.python.org/mailman/listi
> This strikes me as petty hair-splitting.
Maybe it is! I don't know what "petty" means.
> 1. By tacking on the qualification, I was acknowledging that someone,
> somewhere, might controvert it. If you allow for arbitrary redefinitions of
> words, you could claim that any statement is an opinion.
Terry Reedy writes:
> On 1/3/2012 1:13 PM, Sean Wolfe wrote:
>
> > I have a theoretical / philosophical question regarding strong vs
> > duck typing in Python. Let's say we wanted to type strongly in
> > Python
>
> Python objects are strongly typed, in any sensible meaning of the
> term. What you
Sean Wolfe writes:
> Hello everybody, I'm a happy pythonista newly subscribed to the group.
Welcome!
> I have a theoretical / philosophical question regarding strong vs duck
> typing in Python. Let's say we wanted to type strongly in Python
There may be an unstated assumption there, and your w
On 1/3/2012 4:06 PM, Devin Jeanpierre wrote:
Python objects are strongly typed, in any sensible meaning of the term.
There are people that hold definitions of strong typing that preclude
Python. Those people think their definition is reasonable, but at the
Can you give an actual example of su
On 3 January 2012 20:38, Terry Reedy wrote:
> On 1/3/2012 1:13 PM, Sean Wolfe wrote:
>
> I have a theoretical / philosophical question regarding strong vs duck
>> typing in Python. Let's say we wanted to type strongly in Python and
>>
>
> Python objects are strongly typed, in any sensible meanin
> Python objects are strongly typed, in any sensible meaning of the term.
There are people that hold definitions of strong typing that preclude
Python. Those people think their definition is reasonable, but at the
same time haven't confused static typing with strong typing. I guess
the problem is
On 1/3/2012 1:13 PM, Sean Wolfe wrote:
I have a theoretical / philosophical question regarding strong vs duck
typing in Python. Let's say we wanted to type strongly in Python and
Python objects are strongly typed, in any sensible meaning of the term.
What you mean is statically or explicitly t
On 1/3/2012 13:13, Sean Wolfe wrote:
> What I am driving at is, if we are coding in python but looking for
> more performance, what if we had an option to 1) restrict ourselves
> somewhat by using strong typing to 2) make it easy to compile or
> convert down to C++ and thereby gain more performance
On 2012-01-03, David Harks wrote:
> On 1/3/2012 12:13 PM, Sean Wolfe wrote:
>> if we are coding in python but looking for
>> more performance,
>
> Are you in fact in this situation? Despite years of folks
> mentioning how Python is 'slower than C++', I've seen a project
> where a developer churned
On 1/3/2012 12:13 PM, Sean Wolfe wrote:
if we are coding in python but looking for
more performance,
Are you in fact in this situation? Despite years of folks mentioning how
Python is 'slower than C++', I've seen a project where a developer
churned out a feature using Python's generators that
On 12-01-03 01:13 PM, Sean Wolfe wrote:
Hello everybody, I'm a happy pythonista newly subscribed to the group.
Welcome.
The question is, given this possibility, would this get us closer to
being able to compile down to a language like C or C++?
That's "a" question. "The" question is "do yo
On Tue, Jan 3, 2012 at 1:13 PM, Sean Wolfe wrote:
> Hello everybody, I'm a happy pythonista newly subscribed to the group.
> How is it going?
> I have a theoretical / philosophical question regarding strong vs duck
> typing in Python. Let's say we wanted to type strongly in Python and
> were willi
Hello everybody, I'm a happy pythonista newly subscribed to the group.
How is it going?
I have a theoretical / philosophical question regarding strong vs duck
typing in Python. Let's say we wanted to type strongly in Python and
were willing to compromise our code to the extent necessary, eg not
cha
26 matches
Mail list logo
