On Fri, 2006-03-10 at 12:46 +1300, Greg Ewing wrote:
> Steven Elliott wrote:
> > One way of handling it is to
> > alter STORE_ATTR (op code for assigning to mod.str) to always check to
> > see if the key being assigned is one of the default builtins. If it is,
> > then
On 3/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Nick Coghlan]
> > I agree it makes sense to have "decorator", "memoize", "deprecated" and
> > "partial" all being members of the same module, whether the name be
> > "functools" or "functional" (although I have a slight preference for
> >
On Thu, 2006-03-09 at 08:51 -0800, Raymond Hettinger wrote:
> [Steven Elliott]
> > As you probably know each access of a builtin requires two hash table
> > lookups. First, the builtin is not found in the list of globals. It is
> > then found in the list of builtins.
>
&
Georg Brandl wrote:
> Nick Coghlan wrote:
> > Georg Brandl wrote:
> >> some time ago, someone posted in python-list about icons using the Python
> >> logo from the new site design [1]. IMO they are looking great and would
> >> be a good replacement for the old non-scaling snakes on Windows in 2.5.
Sorry about the delay folks. Here's the summary for the first half of
February. I'm going to try to get the ones out for the second half of
February and first half of March shortly.
Please send me any comments/corrections!
=
Announcements
=
-
Ok, here's the summary for the second half of February. Again,
comments and corrections are greatly appreciated! (And thanks to
those who already gave me some for the last summary.)
=
Announcements
=
---
Python release schedule
---
ot;
<http://mail.python.org/pipermail/python-dev/2006-March/062322.html>`__
- `Coverity report
<http://mail.python.org/pipermail/python-dev/2006-March/062434.html>`__
[SJB]
---
Speeding up lookups of builtins
---
Steven Elliott was looking into r
The "make" Statement
Version: $Revision: 45366 $
Last-Modified: $Date: 2006-04-13 07:36:24 -0600 (Thu, 13 Apr 2006) $
Author: Steven Bethard <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History
On 4/13/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > I know 2.5's not out yet, but since I now have a PEP number, I'm going
> > to go ahead and post this for discussion. Currently, the target
> > version is Python 2.6. You
On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > I know 2.5's not out yet, but since I now have a PEP number, I'm going
> > to go ahead and post this for discussion. Currently, the target
> > version is Python
On 4/13/06, Ian D. Bollinger <[EMAIL PROTECTED]> wrote:
> I guess I fail to see how this syntax is a significant improvement over
> metaclasses (though __metaclass__ = xyz may not be the most aesthetic
> construct.)
It doesn't seem strange to you to have to use a *class* statement and
a __meta*cla
On 4/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:05 PM 4/13/2006 -0600, Steven Bethard wrote:
> >On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Steven Bethard wrote:
> > > > I know 2.5's not out yet, but since I
On 4/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
> >Sorry, I'm not clear on exactly what you're suggesting. Are you
> >suggesting I try to implement the make-statement using context
> >managers? Or th
On 4/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote:
[snip examples using class/__metaclass__ statements to create non-types]
> >The question is, is the intent still clear?
>
> Depends on your use case. I'm just sa
On 4/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> >make :
> >
>
> I don't like the position of the name being defined.
> It should be straight after the opening keyword, as
> with 'def' and 'class
On 4/17/06, Russell E. Owen <[EMAIL PROTECTED]> wrote:
> At some point folks were discussing use cases of "make" where it was
> important to preserve the order in which items were added to the
> namespace.
>
> I'd like to suggest adding an implementation of an ordered dictionary to
> standard pytho
On 4/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > This PEP proposes a generalization of the class-declaration syntax,
> > the ``make`` statement. The proposed syntax and semantics parallel
> > the syntax for class definitio
ussions to consider
a few alternate keywords and to indicate some of the difficulties in
allowing a ``__make_dict__`` attribute for customizing the dict in
which the block is executed.
PEP: 359
Title: The "make" Statement
Version: $Revision: 45366 $
Last-Modified: $Date: 2006-04-13 07:36
On 4/18/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I've updated PEP 359 with a bunch of the recent suggestions. The
> patch is available at:
> http://bugs.python.org/1472459
> and I've pasted the full text below.
>
> I've tried to be more explici
On 4/29/06, Talin <[EMAIL PROTECTED]> wrote:
> PEP: 3102
> Title: Keyword-Only Arguments
> Version: $Revision$
> Last-Modified: $Date$
> Author: Talin
> Status: Draft
> Type: Standards
> Content-Type: text/plain
> Created: 22-Apr-2006
> Python-Version: 3.0
> Post-History:
>
>
> Abstract
>
> T
On 5/7/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> I do know enough about Python to know that the make_person function is
> a really bad example.
Totally agreed. I've been ignoring most of that discussion because it
seemed really irrelevant.
> would be nice to instead see some real examples
On 5/7/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > Braces can be escaped using a backslash:
> >
> > "My name is {0} :-\{\}".format('Fred')
> >
> > Which would produce:
> >
> > "My name is Fred :-{}"
>
> Do backslashes also need to be backslashed then?
On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
> I've updated PEP 3101 based on the feedback collected so far.
[snip]
> Compound names are a sequence of simple names seperated by
> periods:
>
> "My name is {0.name} :-\{\}".format(dict(name='Fred'))
>
> Compound names can be use
On 5/21/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum:
> > This was proposed and rejected before.
>
> I haven't seen this proposed before (at least not in PEP form, or with a
> working implementation against the current trunk, or just in some f
On 5/26/06, Facundo Batista <[EMAIL PROTECTED]> wrote:
> All this different ways enforce my vote: we should get an error...
Perhaps you missed Tim's post, so here's a few lines of my own code
that I know would break:
padding = [None] * (self.width - len(leaves))
left_padding = [None]
Sorry I'm so far behind -- I'm aiming to get mostly caught up this
week. Please read through the summary if you have the time and send
me any comments or corrections.
Thanks!
=
Announcements
=
---
Python 2.5 schedule
---
Python 2.5 is mo
``ir`` prefixes, and it would
have forced some rewriting of the tools that currently do string
extraction using ``_()``, so the idea was rejected.
Contributing thread:
- `The "i" string-prefix: I18n'ed strings
<http://mail.python.org/pipermail/python-dev/2006-April/063488.ht
On 5/29/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
> >> .. _contributor agreement:
> >> http://www.python.org/psf/contrib-form-python.html
> >
> > By itself, this link is inadequate since there is a blank for 'Initial
> > License' with no choices indicated. So the summary nee
[Steven Bethard]
> I think that having a package level that exactly matches the divisions
> in the Library Reference (http://docs.python.org/lib/lib.html) would
> be great.
[Brett Cannon]
> Makes sense to me.
>
[snip]
> > 5. Miscellaneous Services
>
> I don't
Ok, here's the summary for the second half of April. My brain is numb
from the setuptools ane PEP 343 discussions, so please have a look
over it and see what I messed up. ;-)
As always, if you have any corrections or comments, please let me know.
=
Announcements
=
-
Ok, here's the frist half or May. I'd almost feel like I was catching
up if there wasn't going to be another summary waiting for me in two
days. ;-)
As always, please look it over and let me know if you have any
corrections/comments.
Thanks!
=
Announcements
=
-
Ok, for the first time in a few months, you're getting this summary
before the next one is due. Woo-hoo! (Yes, I know I'm not even a day
ahead. Let me enjoy my temporary victory.) =)
Here's the draft summary for the second half of May. Let me know what
comments/corrections you have. Thanks!
[delurking in response to the first really decisive message in the thread] ;-)
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition.
FWIW, +1.
Here's the summary for the first half of June. Thanks in advance for
your comments and corrections!
=
Announcements
=
---
Python 2.5 schedule
---
Python 2.5 is moving steadily towards its next release. See `PEP
356`_ for more details and
Here's the May 01-15 draft. Sorry for the delay. Please check the
Unicode summary at the end especially closely; I'm not entirely sure I
got that one all right. Thanks!
As always, please let us know if you have any corrections!
Steve
==
Summary Announcements
==
Here's our draft of the summary for the second half of June. As
usual, please let me, Tony or Tim know if you have any comments or
corrections.
-- Steven Bethard
=
Summary Announcements
=
--
OSCON Registration
--
T
On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> print """Usage: dostuff
>
> Options:
> -c - blah blah
> -f - do stuff with file "filename"
> -s - more blah"""
Isn't the standard idiom for this already:
import textwrap
...
print textwrap.dedent("""\
Usage: dos
Here's the draft for the first half of July. Please look especially
close at the "GCC/G++ Issues on Linux" thread; I'm not sure I got all
the details right.
=
Announcements
=
--
QOTF (Quotes of the Fortnight)
--
Mar
Raymond Hettinger wrote:
> If the PEP can't resist the urge to create new intermediate groupings,
> then start by grepping through tons of Python code to find-out which
> exceptions are typically caught on the same line. That would be a
> worthwhile empirical study and may lead to useful insights.
Raymond Hettinger wrote:
> [Ian Bicking]
> > I think partial() misses an important use case of method getting, for
> > instance:
> >
> > lst = ['A', 'b', 'C']
> > lst.sort(key=partialmethod('lower'))
>
> We've already got one:
>
>lst.sort(key=operator.attrgetter('lower'))
Doesn't
Martin v. Löwis wrote:
> So I would propose the syntax
>
> lst.sort(key=virtual.lower) # where virtual is functional.virtual
Shane Hathaway wrote:
> class virtual:
> def __getattr__(self, name):
> return lambda obj: getattr(obj, name)()
> virtual = virtual()
I think (perhaps beca
Josiah Carlson wrote:
> Steven Bethard <[EMAIL PROTECTED]> wrote:
> > If we're going to move away from the itemgetter() and attrgetter()
> > style, then we should be consistent about it and provide a solution
> > (or solutions) that answers all of these problems:
&
Martin v. Löwis wrote:
> Steven Bethard wrote:
> >>I thought that:
> >> operator.attrgetter() was for obj.attr
> >> operator.itemgetter() was for obj[integer_index]
> >
> >
> > My point exactly. If we're sticking to the same style, I would ex
[Guido van Rossum]
> And good riddance! The print statement harks back to ABC and even
> (unvisual) Basic. Out with it!
[Barry Warsaw]
> I have to strongly disagree. The print statement is simple, easy to
> understand, and easy to use.
[Paul Moore]
> I agree with Barry. In particular, the behavi
Reinhold Birkenfeld wrote:
> Raymond Hettinger wrote:
> > Actually, formatting needs to become a function. The overloading of the
> > arithmetic mod operator has proven to be unfortunate (if only because of
> > precedence issues).
>
> But then, a format() function would be necessary (equivalent t
[EMAIL PROTECTED] wrote:
> I don't find either the trailing comma or >> redirection ugly. If I have a
> long print line that's hard to read because it extends past column 80 (the
> print statement, not the output), it's easy to hit NL at an intermediate
> comma, then just type "print ", perhaps fo
Charles Cazabon wrote:
> Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > next use case:
> >
> > print 'foo:', foo, 'bar:', bar, 'baz:', baz,
> > if frobble > 0:
> > print 'frobble', frobble
> > else:
> > print 'no frobble today'
>
> The need to print /and/ not add a newlin
On 9/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Steven> print 'foo:', foo, 'bar:', bar, 'baz:', baz,
> Steven> print 'frobble', frobble
>
> Steven> In my proposed function:
>
&g
[EMAIL PROTECTED] wrote:
> the print statement is more convenient. Maybe a print builtin wouldn't kill
> me. In that case I'd want both output redirection and newline suppression
> though. I guess you'd have to use a keyword arg to specify an alternate
> stream. Perhaps if the last non-keyword
[EMAIL PROTECTED] wrote:
> Perhaps if the last non-keyword argument was exactly one space, the
> newline could be suppressed, e.g.:
>
> print("foo", "bar", "baz", " ", stream=sys.stderr)
Sorry, I missed the newline-suppression idea in my first reply. I
think the rule above is too confusing.
Paul Moore wrote:
> On 9/2/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> [...]
> > Since
> > the print function seems to be intended mainly for newbies and simple
> > debugging,
>
> I think there have been quite a few comments here from people who
>
Paul Moore wrote:
> Interestingly enough, the other languages I use most (C, Java,
> VB(Script) and Javascript (under Windows Scripting Host)) all use
> functions for output. Except for C, I uniformly dislike the resulting
> code - the output structure gets hopelessly lost under the weight of
> str
Nick Coghlan wrote:
> I actually hope that extended function call syntax in Py3k will
> use iterators rather than tuples so that this problem goes away.
I suggested this a while back on the Python list:
http://mail.python.org/pipermail/python-list/2004-December/257282.html
Raymond Hettinger b
Fredrik Lundh wrote:
> Steven Bethard wrote:
>
> >> - Error and help messages, often with print >>sys.stderr
> >
> > Use the print() method of sys.stderr:
> >
> >sys.stderr.print('error or help message')
>
> so who's going to
Guido van Rossum wrote:
> If there's demand, we could also introduce printf(), which would work
> just like C's printf() except it takes a keyword argument to redirect
> the output.
I think this is probably unnecessary if string formatting becomes a
function instead of the % operator (as has been
Bill Janssen wrote:
> So here's the summary of the arguments against: two style points
> (trailing comma and >>stream) (from the man who approved the current
> decorator syntax!), and it's hard to extend. (By the way, I agree that
> the ">>" syntax is ugly, and IMO a bad idea in general. Shame th
Bill Janssen wrote:
> I think what Nick really is asking for is a better print statement --
> and there's no particularly good reason to move to a function to
> attain that end.
Well one reason (you can judge for yourself whether it's "good" or
not) is that adding more syntax to the print statemen
[Raymond Hettinger]
> Actually, formatting needs to become a function. The overloading of the
> arithmetic mod operator has proven to be unfortunate (if only because of
> precedence issues).
[Guido van Rossum]
> For me, it's not so much the precedence, but the fact that "%s" % x
> doesn't work as
[Greg Ewing]
> While we're on the subject, in Py3k I'd like to see
> readline(), readlines(), etc. removed from file objects
> and made builtin functions instead. It should only
> be necessary to implement read() and write() to get
> a file-like object having equal status with all
> others.
[Fredr
Brett Cannon wrote:
> Is anyone truly attached to nested tuple function parameters; ``def
> fxn((a,b)): print a,b``?
I find 54 instances in my Python installation.
>grep -r "def.*([^=]*([^)]*,[^)]*).*):" *
aifc.py:def setparams(self, (nchannels, sampwidth, framerate,
nframes, comptype, compna
Sokolov Yura wrote:
> Would it be usefull to define new magic class variable __mixins__ for a
> new style classes, which
> will accept list of classes and will drop all members of them into
> definition of class before they went to metaclass.
First off, this is probably more appropriate for comp.l
Greg Ewing wrote:
> François Pinard wrote:
>
> > The only practical reason to like this feature is sparing the need of
> > finding an otherwise useless name for the formal argument.
>
> If the argument represents a coherent enough concept
> to be passed in as a tuple in the first place, it
> shou
Guido van Rossum wrote:
> Also, I bet many people will be surprised to know that this code doesn't work:
>
> add = lambda (x, y): x+y
> print add(1, 2)
What, an example using lambda syntax that's unintuitive? Never! ;-)
STeVe
--
You can wordify anything if you just verb it.
--- Buc
Guido van Rossum wrote:
> I think I'd prefer (if then else ) i.e. no
> colons. None of the other expression forms (list comprehensions and
> generator expressions) involving statement keywords use colons.
FWIW, I find this quite intuitive. It follows the same pattern as LCs
and GEs -- remove t
Adam wrote:
> So looking at a few alternatives ...
>
[snip]
> (e ? (e1 ? a1 : b1) : (e2 ? a2 : b2))
>
[snip]
> (if e, (if e1, a1 else b1) else (if e2, a2 else b2))
>
[snip]
> (if e then (if e1 then a1 else b1) else (if e2 then a2 else b2))
>
[snip
> (e selects (e1 selects a1 else b1) else (e2 selec
Jim Fulton wrote:
> A common use of read descriptors is for lazily computed data:
>
>class readproperty(object):
>"Create a read descriptor from a function"
>
>def __init__(self, func):
>self.func = func
>
>def __get__(self, inst, class_):
>if ins
On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
> Yesterday I ran into a bug in the C API docs. The top of this page:
>
> http://docs.python.org/api/unicodeObjects.html
>
> says:
>
> Py_UNICODE
> This type represents a 16-bit unsigned storage type which is
> used by Python internall
On 9/29/05, Guido van Rossum wrote:
> After a long discussion I've decided to add a shortcut conditional
> expression to Python 2.5.
>
> The syntax will be
>
> A if C else B
>
[snip]
>
> Congratulations gracefully accepted.
Congratulations, and many thanks for making this decision before the
t
Nick Coghlan wrote:
> So my vote would actually go for deprecating the use of square brackets to
> surround an assignment target list - it makes it look like an actual list
> object should be involved somewhere, but there isn't one.
I've found myself using square brackets a few times for more
comp
Nick Coghlan wrote:
> Having module attribute access obey the descriptor protocol (__get__, __set__,
> __delete__) sounds like a pretty good option to me.
>
> It would even be pretty backwards compatible, as I'd be hardpressed to think
> why anyone would have a descriptor *instance* as a top-level
Barry Warsaw wrote:
> On Mon, 2005-10-17 at 21:55, Guido van Rossum wrote:
>
> > Let's change the property built-in so that its arguments can be either
> > functions or strings (or None). If they are functions or None, it
> > behaves exactly like it always has.
> >
> > If an argument is a string, i
Michele Simionato wrote:
> This reminds me of an idea I have kept in my drawer for a couple of years or
> so.
> Here is my proposition: we could have the statement syntax
>
> :
>
>
> to be syntactic sugar for
>
> = (, , )
>
[snip]
> BTW, if the proposal was implemented, the 'class' would be
On 11/18/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
> > I just wanted to add another use case: long messages. Consider those
> > lines from idlelib/run.py:133
> >
> > msg = "IDLE's subprocess can't connect to %s:%d. This may be due "\
> > "to your
I wrote (in the summary):
> While there is no interface to the AST yet, one is
> intended for the not-so-distant future.
Simon Burton wrote:
> who is doing this ? I am mad keen to get this happening.
Brett Cannon wrote:
> No one yet. Some ideas have been tossed around (read the thread for
> deta
Barry Warsaw wrote:
> On Fri, 2005-12-09 at 15:38 -0600, Ian Bicking wrote:
> >Also decide whether your attributes should be private or not.
> >The difference between private and non-public is that the former
> >will never be useful for a derived class, while the latter migh
Jim Fulton wrote:
> Can we officially mark __private as a mistake. Perhaps:
>
> - Strongly discourage it in the style guide
+1
> - Mark it in the language reference as a deprecated feature
+1
> - Generate deprecation warnings when it is used?
-0
I don't see that this gains us much. It will c
On 12/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/11/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Keeping it for Py3K would be fine, if the mechanism was changed so that it
> > actually worked right. That is, the mechanics would be such that any two
> > concurrently existing class
On 12/12/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/11/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > class Document(_cdm.Document):
> > ...
> > # add convenience methods here
> > ...
>
> Personally, I find that naming
Mike Brown wrote:
> Catching up on some python-dev email, I was surprised to see that things seem
> to be barrelling ahead with the adding of ElementTree to Python core without
> any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of
> PyXML in order to satsify the demand for a
Martin v. Löwis wrote:
> Steven Bethard wrote:
> > I didn't really feel like the proposal was out of the blue. The
> > proposal has been brought up before, both on python-dev[1] and the
> > python-list[2]. ElementTree has a pretty large following - if you
> > lo
On 12/13/05, François Pinard <[EMAIL PROTECTED]> wrote:
> [Steven Bethard]
>
> >Ahh. I never run into this because I never import objects directly
> >from modules. So, instead of:
>
> >from elementtree.ElementTree import ElementTree
> >...
>
Here's the summary for the first half of November -- sorry for the bit
of a delay. As always, let me or Tony know if you have any
corrections!
=
Summary Announcements
=
--
Reminder: Python is now on Subversion!
[Raymond]
> Perhaps introduce a single function, base(val, radix=10,
> prefix=''), as a universal base converter that could replace
> bin(), hex(), oct(), etc.
+1 on introducing base()
[Skip]
> Would it (should it) work with floats, decimals, complexes? I presume it
> would work with ints and lo
John J Lee wrote:
> On Thu, 26 Jan 2006, Tony Meyer wrote:
> [...]
> > Well, if you include the much larger discussion on python-list,
> > people (including me) have said that removing __div__ is a good
> > idea. If it's included in the PEP, please at least include a
> > justification and cover th
Raymond Hettinger wrote:
> [Phillip J. Eby]
> > The only case that looks slightly less than optimal is:
> >
> >set((1, 2, 3, 4, 5))
> >
> > But I'm not sure that it warrants a special syntax just to get rid of the
> > extra ().
>
> The PEP records that Tim argued for leaving the extra parenthes
Guido van Rossum wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
Per
Robert Brewer wrote:
> Community consensus on syntax is a pipe dream.
+1 QOTF
And trust me, it'll be in there, since I'm one of the summary writers. ;-)
STeVe
--
Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy
___
Py
systems. I need to extract this
functionality out from _Py_set_inheritable because it needs to run in
the dangerous context of right after a fork and I don't believe it can
throw exceptions. How can I conditionally compile some library code
for certain platforms only?
Thank you,
Steven St
> Do you mean other than potentially detecting something in the
> configurescript and using an #ifdef guard?
Yes, that works on a static function inside a file level but I need to
conditionally include a whole file into the build.
___
Python-Dev mailing
Hello All,
I am new to this list, but I have been lurking around getting a feel for the
environment and processes. I had some discussion yesterday about the
developer documentation as well, since it’s what I do professionally. I am a
technical writer but also work in the web development arena (us
If we can recruit a bunch of somebodies who *do* care, then the wiki
> would be much more useful. But I still don't want to edit the
> dev docs there, if I have a choice :) There's a reason I stopped
> updating the wiki as soon as I moved to a code repository.
>
>
I think that there are plent
[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 u
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
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
> t
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 l
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 wri
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
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
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
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.
>>
1801 - 1900 of 1900 matches
Mail list logo
