If we in the end decide that we would like a propose the PEP, does
anyone feel the odds are anything but very, very slim? I don't think
I've heard a single positive word about the proposal so far except
from Cython devs, so I'm reluctant to spend my own and your time on
a fleshing out a ful
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 would behave (both at the class and metaclass leve
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 Thu, 17 May 2012 20:13:41 +0200, Dag Sverre Seljebotn
wrote:
> Every time Cython becomes able to do stuff more easily in this domain,
> people thank us that they didn't have to dig up Fortran but can stay
> closer to Python.
>
> Sorry for going off on a rant. I find that people will give we
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 to have the u
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 C,
# but allow just us
PEP 421 has reached a good place and I'd like to ask for pronouncement. Thanks!
-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ar
Mark Shannon, 17.05.2012 12:38:
> Dag Sverre Seljebotn wrote:
>> 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 tha
Dag Sverre Seljebotn wrote:
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 lev
So maybe it's worth thinking about making a general mechanism
available for third parties to extend the type object without
them all needing to have their own tp_flags bits and without
needing to collude with each other to avoid conflicts.
That mechanism is already available. Subclass PyTypeType
> http://hg.python.org/cpython/rev/cdcc816dea85
> changeset: 76971:cdcc816dea85
> user: Antoine Pitrou
> date: Tue May 15 23:48:04 2012 +0200
> summary:
> Issue #14624: UTF-16 decoding is now 3x to 4x faster on various inputs.
> Patch by Serhiy Storchaka.
Such optimization should
11 matches
Mail list logo
