On Sun, Nov 30, 2014 at 10:14 PM, Mark Shannon m...@hotpy.org wrote:
Hi,
This discussion has been going on for a while, but no one has questioned the
basic premise. Does this needs any change to the language or interpreter?
I believe it does not. I'm modified your original metamodule.py to
On Mon, Dec 1, 2014 at 12:59 AM, Nathaniel Smith n...@pobox.com wrote:
On Sun, Nov 30, 2014 at 10:14 PM, Mark Shannon m...@hotpy.org wrote:
Hi,
This discussion has been going on for a while, but no one has questioned the
basic premise. Does this needs any change to the language or interpreter
On Sun, Nov 30, 2014 at 8:54 PM, Guido van Rossum gu...@python.org wrote:
On Sun, Nov 30, 2014 at 11:29 AM, Nathaniel Smith n...@pobox.com wrote:
On Sun, Nov 30, 2014 at 2:54 AM, Guido van Rossum gu...@python.org
wrote:
All the use cases seem to be about adding some kind of getattr hook
types.py and importlib use it.) So in my mind I sorta lumped it in
with my Option 2, minor compatibility break. OTOH maybe anyone who
creates a module object without going through PyModule_New deserves
whatever they get.
-n
On Sun, Nov 30, 2014 at 5:02 PM, Nathaniel Smith n...@pobox.com wrote
On Sat, Nov 29, 2014 at 4:21 AM, Guido van Rossum gu...@python.org wrote:
Are these really all our options? All of them sound like hacks, none of them
sound like anything the language (or even the CPython implementation) should
sanction. Have I missed the discussion where the use cases and
On Sat, Nov 29, 2014 at 11:32 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 29 Nov 2014 01:59:06 +
Nathaniel Smith n...@pobox.com wrote:
Option 1: Make it possible to change the type of a module object
in-place, so that we can write something like
sys.modules[__name__
Hi all,
There was some discussion on python-ideas last month about how to make
it easier/more reliable for a module to override attribute access.
This is useful for things like autoloading submodules (accessing
'foo.bar' triggers the import of 'bar'), or for deprecating module
attributes that
On 15 Nov 2014 10:10, Paul Moore p.f.mo...@gmail.com wrote:
Incidentally, it would be really useful if python.org provided stable
url's that always redirected to the latest .msi installers, for
bootstrapping purposes. I'd prefer to not rely on chocolatey (or on
scraping the web site) for
On Tue, Nov 4, 2014 at 4:52 PM, Roberto Martínez
robertomartin...@gmail.com wrote:
Hi folks,
I am trying to replace dinamically the __call__ method of an object using
setattr.
Example:
$ cat testcall.py
class A:
def __init__(self):
setattr(self, '__call__', self.newcall)
On 29 Oct 2014 14:47, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 29 Oct 2014 10:31:50 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Wed, 29 Oct 2014 10:22:14 -0400, Tres Seaver tsea...@palladion.com
wrote:
On 10/28/2014 11:59 PM, Stephen J. Turnbull wrote:
most
On Wed, Oct 29, 2014 at 10:46 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 October 2014 22:19, Ethan Furman et...@stoneleaf.us wrote:
Yeah, I wondered about that. I'll work up a patch for that. But the
more I think about it, it really is trivial:
I am reminded of an interview question I
On Mon, Oct 27, 2014 at 5:48 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 26 October 2014 23:44, Paul Moore p.f.mo...@gmail.com wrote:
On 26 October 2014 23:11, Ray Donnelly mingw.andr...@gmail.com wrote:
I don't know where this ABI compatible thing came into being;
Simple. If a mingw-built
On 11 Oct 2014 14:42, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 11 Oct 2014 00:30:51 + (UTC)
Sturla Molden sturla.mol...@gmail.com wrote:
Larry Hastings la...@hastings.org wrote:
CPython doesn't require OpenBLAS. Not that I am not receptive to the
needs of the numeric
I'm not at all an expert on Fortran ABIs, but I think there are two
distinct issues being conflated here.
The first is that there is no standard way to look at some Fortran source
code and figure out the corresponding C API. When trying to call a Fortran
routine from C, then different Fortran
On Fri, Oct 10, 2014 at 1:29 AM, Victor Stinner
victor.stin...@gmail.com wrote:
Hi,
Windows is not the primary target of Python developers, probably
because most of them work on Linux. Official Python binaries are
currently built by Microsoft Visual Studio. Even if Python developers
get free
I admit I spent the first half of the email scratching my head and trying
to figure out what NULL had to do with argument clinic specs. (Maybe it
would mean that if the argument is not given in some appropriate way then
we set the corresponding C variable to NULL?) Finding out you were talking
Once 7 Jun 2014 06:19, Nick Coghlan ncogh...@gmail.com wrote:
On 7 June 2014 15:05, Donald Stufft don...@stufft.io wrote:
I don’t particularly care too much though, I just think that bumping
the compiler in a 2.7.Z release is a really bad idea and that either
of the other two options are
On Sat, Jun 7, 2014 at 1:37 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Julian Taylor wrote:
tp_can_elide receives two objects and returns one of three values:
* can work inplace, operation is associative
* can work inplace but not associative
* cannot work inplace
Does it really
On 6 Jun 2014 17:07, Sturla Molden sturla.mol...@gmail.com wrote:
We would in total need two mutexes, one condition variable, a pthread, and
a heap.
The proposal in my initial email requires zero pthreads, and is
substantially more effective. (Your proposal reduces only the alloc
overhead for
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the hassle of doing a Python 2.8 or not giving a
clear signal as to when Python
On Fri, Jun 6, 2014 at 11:33 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Nathaniel Smith n...@pobox.com wrote:
The proposal in my initial email requires zero pthreads, and is
substantially more effective. (Your proposal reduces only the alloc
overhead for large arrays; mine reduces both
Hi all,
There's a very valuable optimization -- temporary elision -- which
numpy can *almost* do. It gives something like a 10-30% speedup for
lots of common real-world expressions. It would probably would be
useful for non-numpy code too. (In fact it generalizes the str += str
special case
On Thu, Jun 5, 2014 at 10:37 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 5 June 2014 21:51, Nathaniel Smith n...@pobox.com wrote:
Is there a better idea I'm missing?
Just a thought, but the temporaries come from the stack manipulation
done by the likes of the BINARY_ADD opcode. (After all
On Thu, Jun 5, 2014 at 11:12 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 5 June 2014 22:47, Nathaniel Smith n...@pobox.com wrote:
To make sure I understand correctly, you're suggesting something like
adding a new set of special method slots, __te_add__, __te_mul__,
etc.
I wasn't thinking
On 6 Jun 2014 02:16, Nikolaus Rath nikol...@rath.org wrote:
Nathaniel Smith n...@pobox.com writes:
Such optimizations are important enough that numpy operations always
give the option of explicitly specifying the output array (like
in-place operators but more general and with clumsier
On 5 Jun 2014 23:58, Terry Reedy tjre...@udel.edu wrote:
On 6/5/2014 4:51 PM, Nathaniel Smith wrote:
In fact, AFAICT it's 100% correct for libraries being called by
regular python code (which is why I'm able to quote benchmarks at you
:-)). The bytecode eval loop always holds a reference
On Sat, May 17, 2014 at 6:14 AM, Nick Coghlan ncogh...@gmail.com wrote:
During a conversation today, I realised that the convention of
returning None from methods that change an object's state isn't
captured the Programming Recommendations section of PEP 8.
Specifically, I'm referring to this
On 30 Apr 2014 19:17, francis franci...@email.de wrote:
On 04/30/2014 04:45 AM, Adam Polkosnik wrote:
Gentlemen,
On 04/30/2014 04:48 AM, Jessica McKellar wrote:
Hi Adam,
Gentlemen,
Thanks for contributing to Python! But not everyone on this list is a
guy.
That was a fast reply
On Sat, Apr 19, 2014 at 3:31 AM, Nick Coghlan ncogh...@gmail.com wrote:
Some Python 2 code that uses ``d.keys()`` may be migrated to Python 3
(or the common subset of Python 2 and Python 3) without alteration, but
*all* code using the iterator based API requires modification. Code that
is
On Wed, Apr 16, 2014 at 12:51 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
Hi,
In NumPy what we want is the tracing, not the exchangeable allocators.
I don't think it is a good idea for the core of a whole stack of
C-extension based modules to replace the default allocator or
On Wed, Apr 16, 2014 at 7:35 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Hi,
2014-04-16 7:51 GMT-04:00 Julian Taylor jtaylor.deb...@googlemail.com:
In NumPy what we want is the tracing, not the exchangeable allocators.
Did you read the PEP 445? Using the new malloc API, in fact you
On Tue, Apr 15, 2014 at 9:31 AM, Charles-François Natali
cf.nat...@gmail.com wrote:
Indeed, that's very reasonable.
Please open an issue on the tracker!
Done!
http://bugs.python.org/issue21233
I'll ping numpy-discussion and see if I can convince someone to do the work ;-).
-n
--
Nathaniel
Hi all,
The new tracemalloc infrastructure in python 3.4 is super-interesting
to numerical folks, because we really like memory profiling. Numerical
programs allocate a lot of memory, and sometimes it's not clear which
operations allocate memory (some numpy operations return views of the
original
On 9 Apr 2014 12:34, Robert Kern robert.k...@gmail.com wrote:
On 2014-04-09 12:12, Nick Coghlan wrote:
On 8 April 2014 18:32, cjw fn...@ncf.ca wrote:
Guido,
I am sorry to read this.
I shall be responding more completely in a day or two.
In my view, @ and @@ are completely redundant.
On Wed, Apr 9, 2014 at 4:25 PM, Björn Lindqvist bjou...@gmail.com wrote:
2014-04-08 14:52 GMT+02:00 Nathaniel Smith n...@pobox.com:
On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist bjou...@gmail.com wrote:
2014-04-07 3:41 GMT+02:00 Nathaniel Smith n...@pobox.com:
So, I guess as far as I'm
On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist bjou...@gmail.com wrote:
2014-04-07 3:41 GMT+02:00 Nathaniel Smith n...@pobox.com:
So, I guess as far as I'm concerned, this is ready to go. Feedback welcome:
http://legacy.python.org/dev/peps/pep-0465/
Couldn't you please have made your
On 9 Apr 2014 00:15, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Victor Stinner wrote:
I started to implement the RFC 1924 to have a full support.
3 days later, when my code was working, I saw the date of the RFC...
Do you still have the code? It needn't go to waste -- this
would make
On Mon, Apr 7, 2014 at 7:54 PM, francis franci...@email.de wrote:
So, I guess as far as I'm concerned, this is ready to go. Feedback
welcome:
http://legacy.python.org/dev/peps/pep-0465/
Hi,
just curiosity: why is the second parameter 'o2' in:
PyObject* PyObject_MatrixMultiply(PyObject
On Mon, Apr 7, 2014 at 9:38 PM, Victor Stinner victor.stin...@gmail.com wrote:
Hi,
2014-04-07 3:41 GMT+02:00 Nathaniel Smith n...@pobox.com:
So, I guess as far as I'm concerned, this is ready to go. Feedback welcome:
http://legacy.python.org/dev/peps/pep-0465/
I'm not convinced yet
Hi all,
I've just finished updating PEP 465 with resolutions to the various
issues that were raised during the python-ideas thread about it. (The
main changes since that thread are that @@ has been removed, and we
now definitely propose that @ have the same precedence and
associativity as *.)
I
401 - 440 of 440 matches
Mail list logo
