Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))
[EMAIL PROTECTED] wrote: > > In the past I've begged off of actually writing PEPs because I don't > have the time, but if there is interest in codifying this I think I > don't have the time *not* to write it. I'd prefer to document the > pending/deprecate/remove policy first, but I can write up something more > complicated about community buildbots and resolving disputes around > potential breakages if there is actually no consensus about that. > Please do write this up. It's a good policy and should be codified. # Steve ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.0: JIT compilers for free and more
Aahz wrote: > On Tue, Mar 27, 2007, Armin Rigo wrote: >> Sorry for the spamming. I hope this will be of interest to some of you. > > This is not spamming, this is wonderful news! Congratulations! Second the congrats! ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
Greg Ewing wrote: > Guido van Rossum wrote: > >> But what's the point, given that numpy already exists? Wouldn't you >> just be redoing the work that numpy has already done? >> > > Sometimes I just want to do something simple like > adding two vectors together, and it seems unreasonable > to add the whole of numpy as a dependency just to > get that. ... > > I'd like to see some of the core machinery of numpy moved > into the Python stdlib, and numpy refactored so that it > builds on that. Then there wouldn't be duplication. > Concur. Array processing would be a very practical addition to the standard library. It's used extensively in engineering, finance, and the sciences. It looks like they may find room in the OLPC XO for key subsets of NumPy and Matplotlib. They want it both as a teaching resource and to optimize their software suite as a whole. If they're successful, we'll have a lot of young pythoneers expecting this functionality. # Steve ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
Guido van Rossum wrote: > I still don't see why the standard library needs to be weighed down > with a competitor to numpy. Including a subset of numpy was considered > in the past, but it's hard to decide on the right subset. In the end > it was decided that numpy is too big to become a standard library. > Given all the gyrations it has gone through I definitely believe this > was the right decision. A competitor to NumPy would be counter-productive, but including a core subset in the standard library that NumPy could be built upon would add valuable functionality to Python out of the box. It was probably the best decision to not include NumPy when it was previously considered, but I think it should be reconsidered for Python 3.x. While defining the right subset to include has it's difficulties, I believe it can be done. What would be a reasonable target size for inclusion in the standard library? # Steve ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
Greg Ewing wrote: > Martin v. Löwis wrote: > >> I think this requires a PEP, and explicit support from the >> NumPy people. >> > > Someone who knows more about numpy's internals would > be needed to figure out what the details should be > like in order to be usable by numpy. But I could write > a PEP about how what I have in mind would look from > the Python level. > I'm confident that the NumPy developers would support this in principle. If you want help with the PEP, I'm willing to help. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
Guido van Rossum wrote: > What makes 3.0 so special? Additions to the stdlib can be considered > at any feature release. Frankly, 3.0 is already so loaded with new > features (and removals) that I'm not sure it's worth pile this onto > it. > I actually wrote 3.x, not 3.0. I agree that it makes no sense to add anything more to 3.0. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
Robert Kern wrote: > I invite Greg and Steven and whoever else is interested to discuss ideas for > the > PEP on numpy-discussion. I'm skeptical, seeing what currently has been > suggested, but some more details could easily allay that. > > http://projects.scipy.org/mailman/listinfo/numpy-discussion > Accepted, that's probably the best place for this to continue. Greg's suggestion sounds plausible to me, but needs to be fleshed out. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Exploration PEP : Concurrency for moderately massive (4 to 32 cores) multi-core architectures
Krishna Sankar wrote: > Folks, >As a follow-up to the py3k discussions started by Bruce and Guido, I > pinged Brett and he suggested I submit an exploratory proposal. Would > appreciate insights, wisdom, the good, the bad and the ugly. > > A)Does it make sense ? > B)Which application sets should we consider in designing the > interfaces and implementations > C)In this proposal, parallelism and concurrency are used in an > interchangeable fashion. Thoughts ? > D)Please suggest pertinent links, discussions and insights. > E)I have kept the proposal to a minimum to start the discussions and > to explore if this is the right thing to do. Collaboratively, as we > zero-in on one or two approaches, the idea is to expand it to a crisp > and clear PEP. Need to do some more formatting as well. > Cheers > > P.S : I had sent this to python-ideas couple of days ago and received > two comments (Thanks Leonardo, Thanks Adam) I haven't incorporated their > comments yet. Folks who are on both lists, pardon me for the spam. # Proto-PEP elided. Other than number of cores, you don't mention hardware architecture. I presume that you're thinking of symmetric multiprocessor architectures. If so, this should be explicit. You should also consider that SMP may not be the predominant multi-core architecture in the future, the Cell processor has one general purpose processor and eight more specialized processors. You might not want to limit the PEP to 32 cores, I know of startups working on 40 and 64 core chips. Shared memory may be necessary for good performance, but it doesn't have to be exposed at the language level. While Erlang has strictly message passing semantics, I believe that it uses shared memory in the low level implementation. # Steve ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Proposed revision of PEP 3 (using the issue tracker)
Ron Adam wrote: > Nick Coghlan wrote: > >> Martin v. Löwis wrote: >> >>> One issue to consider is also politeness. People sometimes complain that >>> they feel treated unfair if their report is declared "invalid" - they >>> surely believed it was a valid report, at the time they made it. >>> >> I agree with Martin for both of these - 'works for me' and 'out of date' >> convey additional information to the originator of the bug, even if they >> don't make a signifcant difference from a development point of view. >> > > The term 'works for me' can be confused with 'solution/patch works for me'. > I've generally seen the phrase 'works for me' to mean agreement of a > proposed action of some sort. > > Maybe something along the lines of 'can not reproduce' would be better? > > +1 for 'can not reproduce' or perhaps 'can not duplicate' # Steve ___ 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/archive%40mail-archive.com
