hi mike,
Great work. You might want to advertise this on the main site
(currently it states that this is impossible).
yes, thank you for reminding me.
You've said somewhere that you didn't/don't plan on working on this
aspect, but it is surely the killer feature of shed skin needed to
for
On Jun 29, 3:48 am, Mark Dufour [EMAIL PROTECTED] wrote:
I have just released version 0.0.22 of Shed Skin, an experimental
Python-to-C++ compiler. Among other things, it has the exciting new
feature of being able to generate (simple, for now) extension modules,
so it's much easier to compile
hi felix,
On 6/29/07, felix seltzer [EMAIL PROTECTED] wrote:
does this project include support for pygtk type GUI's?
No, it won't work for arbitrary python programs. Shed Skin is
currently limited to smallish programs (up to a few hundred lines),
that only use a few basic modules (random, math,
On Jun 29, 7:48 am, Mark Dufour [EMAIL PROTECTED] wrote:
Hi all,
I have just released version 0.0.22 of Shed Skin, an experimental
Python-to-C++ compiler. Among other things, it has the exciting new
feature of being able to generate (simple, for now) extension modules,
so it's much easier to
Hi all,
I have just released version 0.0.22 of Shed Skin, an experimental
Python-to-C++ compiler. Among other things, it has the exciting new
feature of being able to generate (simple, for now) extension modules,
so it's much easier to compile parts of a program and use them (by
just importing
does this project include support for pygtk type GUI's?
On 6/29/07, Mark Dufour [EMAIL PROTECTED] wrote:
Hi all,
I have just released version 0.0.22 of Shed Skin, an experimental
Python-to-C++ compiler. Among other things, it has the exciting new
feature of being able to generate (simple, for
On 2 Apr, 20:17, Kay Schluehr [EMAIL PROTECTED] wrote:
Note that the conflict of putting modules on top level or better
within separate packages is not an either-or decision from a
programmers point of view who just wants to access those modules. A
top level module like lib or std can be
You still dream of this, isn't it? Type inference in dynamic languages
doesn't scale. It didn't scale in twenty years of research on
SmallTalk and it doesn't in Python. However there is no no-go theorem
type inference sure is difficult business, and I won't deny there are
scalability issues,
[EMAIL PROTECTED] wrote:
but in any case, I believe there are several reasons why type
inference scalability is actually not _that_ important (as long as it
works and doesn't take infinite time):
-I don't think we want to do type inference on large Python programs.
this is indeed asking for
On 2 Apr, 09:17, John Nagle [EMAIL PROTECTED] wrote:
Something else worth trying: type inference for separately
compiled modules using the test cases for the modules.
I mentioned such possibilities once upon a time:
http://blog.amber.org/2004/12/23/static-typing-and-python/
Note the
On Apr 2, 9:17 am, John Nagle [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
but in any case, I believe there are several reasons why type
inference scalability is actually not _that_ important (as long as it
works and doesn't take infinite time):
-I don't think we want to do type
Paul Boddie:
the author's frustration with the state of the standard library:
something which almost always gets mentioned in people's pet Python
hates, but something mostly ignored in the wider enthusiasm for
tidying up the language.
There is some possibility that Python 3.1 will have what
On 2 Apr, 13:05, [EMAIL PROTECTED] wrote:
There is some possibility that Python 3.1 will have what you ask
for:http://www.python.org/dev/peps/pep-3108/
Prior to that PEP being written/published, I made this proposal:
Paul Boddie:
Prior to that PEP being written/published, I made this proposal:
http://wiki.python.org/moin/CodingProjectIdeas/StandardLibrary/Restru...
On first sight it looks good. Python 3.0-3.1 is the best and probably
only possibility for such improvement (I have said 3.1 too because I
think
On Apr 2, 1:27 pm, Paul Boddie [EMAIL PROTECTED] wrote:
On 2 Apr, 13:05, [EMAIL PROTECTED] wrote:
There is some possibility that Python 3.1 will have what you ask
for:http://www.python.org/dev/peps/pep-3108/
Prior to that PEP being written/published, I made this proposal:
On Mar 31, 11:26 pm, Luis M. González [EMAIL PROTECTED] wrote:
On Mar 31, 8:38 am, Bjoern Schliessmann usenet-
[EMAIL PROTECTED] wrote:
Mark Dufour wrote:
Shed Skin allows for translation of pure (unmodified), implicitly
statically typed Python programs into optimized C++, and hence,
Anyway, the only real point is that if there is a concern about the
copyright and licensing of the output of ShedSkin, then we merely need
to ask the author of it to clarify matters and move on with life. With
the exception of GNAT, to date no GPL'd compiler has ever placed a GPL
restriction
Kay Schluehr wrote:
Indeed. The only serious problem from an acceptance point of view is
that Mark tried to solve the more difficult problem first and hung on
it. Instead of integrating a translator/compiler early with CPython,
doing some factorization of Python module code into compilable and
I don't see how that can be--we're talking about a GCC-based compiler,
right?
no, Shed Skin is a completely separate entity, that outputs C++ code.
it's true I only use GCC to test the output, and I use some GCC-
specific extensions (__gnu_cxx::hash_map/hash_set), but people have
managed to
[EMAIL PROTECTED] writes:
I don't see how that can be--we're talking about a GCC-based compiler,
right?
no, Shed Skin is a completely separate entity,
I was referring to GNAT.
--
http://mail.python.org/mailman/listinfo/python-list
On Apr 1, 6:07 pm, John Nagle [EMAIL PROTECTED] wrote:
Kay Schluehr wrote:
Indeed. The only serious problem from an acceptance point of view is
that Mark tried to solve the more difficult problem first and hung on
it. Instead of integrating a translator/compiler early with CPython,
doing
Kay Schluehr wrote:
On Apr 1, 6:07 pm, John Nagle [EMAIL PROTECTED] wrote:
Kay Schluehr wrote:
Indeed. The only serious problem from an acceptance point of view is
that Mark tried to solve the more difficult problem first and hung on
it. Instead of integrating a translator/compiler early with
Hi all,
I have recently released version 0.0.20 and 0.0.21 of Shed Skin, an
optimizing Python-to-C++ compiler. Shed Skin allows for translation of
pure (unmodified), implicitly statically typed Python programs into
optimized C++, and hence, highly optimized machine language. Besides
many bug
Mark Dufour wrote:
Shed Skin allows for translation of pure (unmodified), implicitly
statically typed Python programs into optimized C++, and hence,
^
highly optimized machine language.
Wow, I bet all C++
Björn Mark Dufour wrote:
Shed Skin allows for translation of pure (unmodified), implicitly
statically typed Python programs into optimized C++, and hence,
highly optimized machine language.
Bjoern
Bjoern Wow, I bet all C++ compiler manufacturers
[EMAIL PROTECTED] wrote:
Why are you taking potshots at Mark?
What suggests that I'm taking potshots at Mark?
He's maybe onto something and he's asking for help. If he can
generate efficient C++ code from implicitly statically type Python
it stands to reason that he can take advantage of
On Mar 31, 8:38 am, Bjoern Schliessmann usenet-
[EMAIL PROTECTED] wrote:
Mark Dufour wrote:
Shed Skin allows for translation of pure (unmodified), implicitly
statically typed Python programs into optimized C++, and hence,
^
Luis M. González [EMAIL PROTECTED] writes:
On Mar 31, 8:38 am, Bjoern Schliessmann usenet-
[EMAIL PROTECTED] wrote:
Mark Dufour wrote:
Shed Skin allows for translation of pure (unmodified), implicitly
statically typed Python programs into optimized C++, and hence,
Alexander Schmolck wrote:
Regardless of its merrits, it's GPL'ed which I assume is an immediate turn-off
for many in the community.
In the way that tools such as gcc are GPL-licensed, or do you have
something else in mind?
Paul
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 31, 6:45 pm, Alexander Schmolck [EMAIL PROTECTED] wrote:
Regardless of its merrits, it's GPL'ed which I assume is an immediate turn-off
for many in the community.
Why would that be? GPL'ed code libraries can be a turn-off for those
who want to release commercial products using them,
Paul McGuire [EMAIL PROTECTED] writes:
Why would that be? GPL'ed code libraries can be a turn-off for those
who want to release commercial products using them, but a GPL'ed
utility such as a compiler bears no relationship or encumbrance on the
compiled object code it generates.
For some of
Luis M. González wrote:
I think he should be taken very seriously.
Agreed.
Okay, it seems focusing a discussion on one single point is
difficult for many people. Next time I'll be mind-bogglingly clear
that even the last one understands after reading it one time ...
Regards,
Björn
Fup2 p
On Mar 31, 10:31 pm, Bjoern Schliessmann usenet-
[EMAIL PROTECTED] wrote:
Luis M. González wrote:
I think he should be taken very seriously.
Agreed.
Okay, it seems focusing a discussion on one single point is
difficult for many people. Next time I'll be mind-bogglingly clear
that even the
On Sun, 2007-04-01 at 02:49 +, Dennis Lee Bieber wrote:
Take that up with ACT... GNAT 3.15p was explicitly unencumbered, but
the current version of GNAT, in the GPL (no-service contract) form has
gone the other direction, claiming that executables must be released
GPL.
The
Michael Torrie [EMAIL PROTECTED] writes:
The no-service contract version of the GPL is not the same as the
standard GPLv2.
I don't see how that can be--we're talking about a GCC-based compiler,
right?
--
http://mail.python.org/mailman/listinfo/python-list
On Sat, 2007-03-31 at 20:47 -0700, Paul Rubin wrote:
Michael Torrie [EMAIL PROTECTED] writes:
The no-service contract version of the GPL is not the same as the
standard GPLv2.
I don't see how that can be--we're talking about a GCC-based compiler,
right?
Well, that's beside the point
On Sat, 2007-03-31 at 20:47 -0700, Paul Rubin wrote:
Michael Torrie [EMAIL PROTECTED] writes:
The no-service contract version of the GPL is not the same as the
standard GPLv2.
I don't see how that can be--we're talking about a GCC-based compiler,
right?
I found the real reason why the
Mark Dufour wrote:
Hi all,
I have recently released version 0.0.20 and 0.0.21 of Shed Skin, an
optimizing Python-to-C++ compiler. Shed Skin allows for translation of
pure (unmodified), implicitly statically typed Python programs into
optimized C++, and hence, highly optimized machine
38 matches
Mail list logo
