On 04/04/2014 12:42 AM, Sturla Molden wrote:
Kevin Modzelewski wrote:
Since it's the question that I think most people will inevitably (and
rightly) ask, why do we think there's a place for Pyston when there's PyPy
and (previously) Unladen Swallow?
Have you seen Numba, the Python JIT that in
On 09/23/2013 04:43 PM, R. David Murray wrote:
On Sun, 22 Sep 2013 16:19:21 -0700, Guido van Rossum wrote:
On Sun, Sep 22, 2013 at 2:41 PM, Xavier Morel wrote:
The points here are that there's a single source of truth (so we can't
have conflicting docstring and rst documentation), and documen
On 12/13/2012 06:11 AM, PJ Eby wrote:
On Wed, Dec 12, 2012 at 5:06 PM, Dag Sverre Seljebotn
wrote:
Perfect hashing already separates "hash table" from "contents" (sort of),
and saves the memory in much the same way.
Yes, you can repeat the trick and have 2 levels of indire
On 12/12/2012 11:06 PM, Dag Sverre Seljebotn wrote:
On 12/12/2012 10:31 PM, PJ Eby wrote:
On Wed, Dec 12, 2012 at 3:37 PM, Dag Sverre Seljebotn
wrote:
On 12/12/2012 01:15 AM, Nick Coghlan wrote:
On Wed, Dec 12, 2012 at 5:37 AM, Dino Viehland mailto:di...@microsoft.com>> wrote:
On 12/12/2012 10:31 PM, PJ Eby wrote:
On Wed, Dec 12, 2012 at 3:37 PM, Dag Sverre Seljebotn
wrote:
On 12/12/2012 01:15 AM, Nick Coghlan wrote:
On Wed, Dec 12, 2012 at 5:37 AM, Dino Viehland mailto:di...@microsoft.com>> wrote:
OTOH changing certain dictionaries in IronPython (s
e the dict
"unperfect"; one could also have a pack() method that made the dict
perfect again.).
That concludes the on-topic parts of my post.
--
Dag Sverre Seljebotn
APPENDIX
Going off-topic for those who are interested, here's the longwinded and
ugly details. My code [1] is b
I'll admit I didn't read through your email, but you should absolutely
check out Numba which is ramping up just now to do this:
https://github.com/numba
(I'm CC-ing their mailing list, perhaps some of them will read this and
respond.)
It is probably much less ambitious but that hopefully sho
On 06/23/2012 03:20 PM, Vinay Sajip wrote:
Dag Sverre Seljebotn astro.uio.no> writes:
Of course you can always do anything, as numpy.distutils is a living
proof of. Question is if it is good design. Can I be confident that the
hooks are well-designed for my purposes?
Only you can look
On 06/23/2012 02:27 PM, Vinay Sajip wrote:
Dag Sverre Seljebotn astro.uio.no> writes:
As for me, I believe I've been rather blunt and direct in my criticism
in this thread: It's been said by Tarek that distutils2 authors that
they don't know anything about compilers. The
On 06/23/2012 12:37 PM, Lennart Regebro wrote:
Why do I get the feeling that most people who hate distutils and want
to replace it, has transferred those feelings to distutils2/packaging,
mainly because of the name?
In the end, I think this discussion is very similar to all previous
packaging/bu
On 06/22/2012 12:20 PM, David Cournapeau wrote:
On Fri, Jun 22, 2012 at 10:38 AM, Donald Stufft wrote:
On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:
What Bento does is have one metadata file for the source-package, and
another metadata file (manifest) for the built-package
On 06/22/2012 11:38 AM, Donald Stufft wrote:
On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:
What Bento does is have one metadata file for the source-package, and
another metadata file (manifest) for the built-package. The latter is
normally generated by the build process (but
On 06/22/2012 10:40 AM, Paul Moore wrote:
On 22 June 2012 06:05, Nick Coghlan wrote:
distutils really only plays at the SRPM level - there is no defined OS
neutral RPM equivalent. That's why I brought up the bdist_simple
discussion earlier in the thread - if we can agree on a standard
bdist_sim
On 06/22/2012 12:05 AM, Dag Sverre Seljebotn wrote:
On 06/21/2012 11:04 PM, Tarek Ziadé wrote:
On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote:
...
I think we should, as you proposed, list a few projects w/ compilation
needs -- from the simplest to the more complex, then see how a standard
On 06/21/2012 11:04 PM, Tarek Ziadé wrote:
On 6/21/12 10:46 PM, Dag Sverre Seljebotn wrote:
...
I think we should, as you proposed, list a few projects w/ compilation
needs -- from the simplest to the more complex, then see how a standard
*description* could be used by any tool
It's not
On 06/21/2012 09:05 PM, Tarek Ziadé wrote:
On 6/21/12 4:26 PM, Dag Sverre Seljebotn wrote:
project should give me so I can compile its extensions ?" I think this
has nothing to do with the tools/implementations.
If you sit down and ask your self: "what are the information a pytho
On 06/21/2012 03:23 PM, Tarek Ziadé wrote:
On 6/21/12 2:45 PM, Dag Sverre Seljebotn wrote:
Guido was asked about build issues and scientific software at PyData
this spring, and his take was that "if scientific users have concerns
that are that special, perhaps you just need to go and do
On 06/21/2012 01:56 PM, Tarek Ziadé wrote:
On 6/21/12 11:08 AM, Dag Sverre Seljebotn wrote:
...
David Cournapeau's Bento project takes the opposite approach,
everything is explicit and without any magic.
http://cournape.github.com/Bento/
It had its 0.1.0 release a week ago.
Please, I
y magic.
http://cournape.github.com/Bento/
It had its 0.1.0 release a week ago.
Please, I don't want to reopen any discussions about Bento here --
distutils2 vs. Bento discussions have been less than constructive in the
past -- I just wanted to make sure
On 05/18/2012 12:57 AM, Nick Coghlan wrote:
I think the main things we'd be looking for would be:
- a clear explanation of why a new metaclass is considered too complex a
solution
- what the implications are for classes that have nothing to do with the
SciPy/NumPy ecosystem
- how subclassing woul
On 05/17/2012 05:00 AM, Greg Ewing wrote:
On 17/05/12 12:17, Robert Bradshaw wrote:
This is exactly what was proposed to start this thread (with minimal
collusion to avoid conflicts, specifically partitioning up a global ID
space).
Yes, but I think this part of the mechanism needs to be spell
On 05/17/2012 08:13 PM, Dag Sverre Seljebotn wrote:
Mark Shannon wrote:
Dag Sverre Seljebotn wrote:
from numpy import sin
# assume sin is a Python callable and that NumPy decides to support
# our spec to also support getting a "double (*sinfuncptr)(double)".
# Our mission: Avoid t
Mark Shannon wrote:
Dag Sverre Seljebotn wrote:
from numpy import sin
# assume sin is a Python callable and that NumPy decides to support
# our spec to also support getting a "double (*sinfuncptr)(double)".
# Our mission: Avoid to have the user manually import "sin" from
On 05/16/2012 10:24 PM, Robert Bradshaw wrote:
On Wed, May 16, 2012 at 11:33 AM, "Martin v. Löwis" wrote:
Does this use case make sense to everyone?
The reason why we are discussing this on python-dev is that we are looking
for a general way to expose these C level signatures within the Python
On 05/16/2012 02:47 PM, Mark Shannon wrote:
Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by its
On 05/16/2012 02:16 PM, Stefan Behnel wrote:
Stefan Behnel, 16.05.2012 13:13:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhea
On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so calling into
the C-API multiple times may be substantially more costly than, say,
calling through a function pointer onc
On 05/16/2012 10:36 AM, "Martin v. Löwis" wrote:
> And, we want this to somehow work with existing Python; we still
> support users on Python 2.4.
This makes the question out-of-scope for python-dev - we only discuss
new versions of Python here. Old versions cannot be developed anymore
(as the
On 05/16/2012 10:11 AM, Nick Coghlan wrote:
Use PyObject_HasAttr, just as people use hasattr() for ducktyping in Python.
In the Cython wrap-function-pointers case we really want performance
comparable to C, so we couldn't do the whole thing.
But I guess we could intern some char* (somehow),
g over the hundreds (thousands?) of
extensions relying on the NumPy C API is a lot of work, but we can at
least get started...
Ideas?
Dag Sverre Seljebotn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
> What is Spyke?
> In many performance critical projects, it is often necessary to
> rewrite parts of the application in C. However writing C wrappers can
> be time consuming. Spyke offers an alternative approach. You add
> annotations to your Python code as strings. These strings are
> discarded
> (Though as the saying goes, little duplication is normal (and perhaps
> wanted) for open source software.)
Sorry! I meant "a little", completely reversing the meaning of my sentence.
Dag Sverre
___
Python-Dev mailing list
Python-Dev@python.org
http:
32 matches
Mail list logo
