On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >>I saw this too in the archives, and thought shit, that's going to mess
> >>up a lot of my code. I would assume (though it's a separate point of
> >>discussion) that Python 3k should still try hard to keep backward
> >
On 3/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > Testing whether an iterator is empty or not is an oxymoron; the only
> > > legit way is to call next() and see whether it raises StopIteration.
> > > This is the fundamental
On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
[SNIP]
> I'm testing if it is empty or not, which seems natural enough. Or would
> be, if it worked. So I start out doing:
>
>for item in select_results: ...
>
>
On 3/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> > > When I was just
> > > first learning Python I thought this would wo
On 3/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/23/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > I think there is a fundamental difference between your views of
> > iterators. It sounds like Ian is viewing them as a separate object;
> > something
On 3/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> The (pre-)PEP should be mostly self-explanatory. I'm trying to lay
> down some guidelines for how backwards-incompatible changes should be
> introduced in Python 3000. Feedback is greatly appreciated,
> especially in the Identifying Correct
On 3/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam DePrince wrote:
>
> >The following interface names are abbreviations for the following
> >permutations of the above.
> >
> >* Collection View( SetView + Multiview )
> >* ListView: (SetView + MultiView + OrderedView)
> >* O
On 3/29/06, Adam DePrince <[EMAIL PROTECTED]> wrote:
>
> > set interface where we could have a __container__/__view__/__set__
>
> Why would I call a method to get a view on an object when the object can
> just as well implement the view? The *only* time we want to call a
> method to get a view is
On 3/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
>
> > Basically a simple
> > set interface where we could have a __container__/__view__/__set__
> > whatever method to call to get a view of the data structure.
> > Basically a read-only
Woohoo! I get it, finally! Some comments below, but I suddenly feel
a little less stupid since I get the whole process now! =)
On 4/1/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Apr 1, 2006, at 8:31 AM, Aahz wrote:
> ...
> > Seriously, I can almost see why you think adaptation is a
On 4/1/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Apr 1, 2006, at 2:40 PM, Brett Cannon wrote:
>
> > Woohoo! I get it, finally! Some comments below, but I suddenly feel
> > a little less stupid since I get the whole process now! =)
>
> Well, I gues
On 4/2/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/2/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > A quick idea of mine: Wouldn't it be useful to maintain a list of what will
> > not change, collected in the discussions here? That way, people eager to
> > suggest
> > braces and whatno
On 4/3/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
>
> > On Apr 2, 2006, at 4:39 PM, Walter Dörwald wrote:
> >...
> >> Why not make the registry identical to the protocol? The protocol is
> >> just a convention anyway:
> >
> > Yes, a 1<->1 relationship between registrie
On 4/4/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-04-04 at 09:57 -0700, Guido van Rossum wrote:
> > On 4/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> > > I've been thinking that `hash` could be an attribute (or property if it
> > > needs to be calculated on-the-fly) rat
On 4/11/06, John J Lee <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Apr 2006, Michael Chermside wrote:
> [...]
> > There's a related change that I would love to see. Currently, we
> > have a large number of unit tests, but we have made no attempt to
> > distinguish between python language tests, and CPy
On 4/11/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> So Guido asked for more concrete discussion of things like views. A
> richer set of collections also fits in here, as for instance dict.keys()
> would be a view with a collection interface not exactly like other
> collections. I wrote up some n
On 4/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> I propose that strings (unicode/text) shouldn't be iterable. Seeing this:
>
>
>i
>t
>e
>m
>
>1
>
>
> a few too many times... it's annoying. Instead, I propose that strings
> get a list-like view on their characters. Oh
On 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Ivan Krstic wrote:
> > Nick Coghlan wrote:
> >> This is why I think the first step in a solid Python restricted
> >> execution framework isn't an implementation activity but a
> >> research/scoping activity, looking at the various systems alread
On 4/16/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 4/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Some of the coding projects I've recently been proposing as challenges
> > to certain wild feature proposals might make good topics for the
> > Google Summer of Code (see http://code.go
On 4/16/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 4/16/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> >
> > again, if my host at Google wants me to spend my working hours being a
> > good mentor I could possibly be convinced to make sure I get assigned
>
[forgot to cc: python-3000; sorry for the dup, Terry]
On 4/19/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > On 4/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> >> Py3k suggestion: make ... a generally legal expre
On 4/19/06, Luis P Caamano <[EMAIL PROTECTED]> wrote:
> It seems that python-3000 is more about language issues than CPython
> issues. Still, I'll ask the question just to nip it in the bud early:
>
> Any possibility of working on the CPython GIL and MP problems in python-3000?
>
> The reason I as
On 4/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> There are still a bunch of tests failing in the py3k (sic) branch:
>
> test_class fails because hash() of a new-style class that defines
> __eq__ or __cmp__ doesn't raise an exception. There's a design issue
> here: should the default hash b
On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/21/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 4/21/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > > To prevent more abominations like this, let me pronounce tha
On 4/22/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 4/22/06, Talin <[EMAIL PROTECTED]> wrote:
> > Well the problem is that decorator functions don't have access to the
> > machinery
> > that binds input arguments for formal parameters. So the wrapper function
> > has a
> > hard time knowing wh
On 4/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > > I'm afraid I disagree. PEP 302 actually has some tremendous advantages
> > > over a pure objects-on-sys.path approach:
> > >
> > > * Strings can be put in any configuration file, and used in .pth files
> > >
> >
s.
-Brett
--
PEP: XXX
Title: Introducing the __signature__ Attribute
Version: $Revision: 1.5 $
Last-Modified: $Date: 2005/06/07 13:17:37 $
Author: Brett Cannon <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: XX-XXX-
Post-History:
On 4/22/06, Talin <[EMAIL PROTECTED]> wrote:
> Brett Cannon python.org> writes:
>
> > [I am posting to python-3000 since this is where the parameter list
> > ideas are being discussed, but this is probably generic enough to
> > eventually make it into the 2.x li
On 4/25/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 4/25/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>...
> > If list comprehensions didn't come first (and even though list
> > comprehensions came first), I would argue that there should only be
> > generator expressions. If one wants a
On 4/27/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Fredrik Lundh]
> > no, because people enjoy writing readable code. doing things by exe-
> > cuting methods attached to literals isn't very readable, and isn't used
> > for anything else.
>
> As Barry often says, he spells it TAB.join() or BLANK.
On 4/27/06, Talin <[EMAIL PROTECTED]> wrote:
> Nick Coghlan gmail.com> writes:
>
> > > My mental model matches Brett's.
> >
> > I think of them as separate things, too. Separate attributes also makes it
> > easier to add additional metadata later, and the structure of each attribute
> > can be wel
On 4/29/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i first thought on focusing on the socket module, because it's the part that
> bothers me most, but since people have expressed their thoughts on
> completely
> revamping the IO stack, perhaps we should be open to adopting new ideas,
> mainly fr
On 4/29/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I just read PEP 3002 and while I like most of what I see (thanks
> > Steven Bethard!) there's one section that stands out as problematic.
> [snip]
> > Rather than a version of Python
On 5/7/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
On Sun, May 07, 2006 at 02:24:08PM -0700, Bill Janssen wrote:> I think that there is little of advantage in the Java type system to> be adopted into Python. One thing from Java I really miss in Python - declaration what
exception(s) a function/
On 5/17/06, tomer filiba <[EMAIL PROTECTED]> wrote:
hi alli would like to suggest changing the base-exception class, whateverit may be (Exception/BaseException) to work with keyword argumentsinstead of positional ones.Positional support is deprecated; there will only be support for a single argumen
can easily add your filename attribute.::
def __init__(self, filename): self.filename = filename BaseException.__init__(self, "%s does not exist" % filename) This also allows you to come up with an informative message if you so desire that is more standardized and based on
On 5/22/06, Talin <[EMAIL PROTECTED]> wrote:
The 3100 PEP has an item which states "Reorganize the standard libraryto not be as shallow". I presume that there are already numerousproposals for a new library organization; Is there a list of links that
someone can post so that I could check them out?
On 5/29/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:> I have to ignore this topic. It's too big and contentious to get easy> agreement. (The one thing I *don't* want is move the entire stdlib> hierarchy under 'py' or something like that.) Eric Raymond once made
> detailed proposal,
On 5/31/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
Le mardi 30 mai 2006 à 09:25 -0700, Brett Cannon a écrit :>> I think what needs to happen is decide if we want to group modules> into packages (but no deeper than a single depth), and then how to> handle general namin
On 5/31/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
Le mercredi 31 mai 2006 à 09:57 -0700, Brett Cannon a écrit :>> That might be true of http, but what about modules with a more> ambiguous name?Then perhaps the name can be made less ambiguous ;)
For example "ElementTree"
On 5/31/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
On 31-mei-2006, at 19:19, Antoine Pitrou wrote:> Le mercredi 31 mai 2006 à 09:57 -0700, Brett Cannon a écrit :>>>> That might be true of http, but what about modules with a more>> ambiguous name?
>> Then
On 5/31/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
Le mercredi 31 mai 2006 à 11:31 -0700, Brett Cannon a écrit :> If there were categories, though, I would most likely have the handful> of package names memorized. So I would run help() on the packages to
> see what modules t
On 6/1/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
On 1-jun-2006, at 13:29, Paul Moore wrote:> On 5/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:>> Why would a 3rd-party module be installed into the stdlib namespace?
>> net.jabber wouldn't exist unless it was
On 6/1/06, Aaron Bingham <[EMAIL PROTECTED]> wrote:
Paul Moore wrote:>On 5/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:>>>>Why would a 3rd-party module be installed into the stdlib namespace?
>>net.jabber wouldn't exist unless it was in the stdlib or the mod
On 6/1/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
On 1-jun-2006, at 17:44, Brett Cannon wrote:>>> On 6/1/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:> On 1-jun-2006, at 13:29, Paul Moore wrote:
>> > On 5/31/06, Brett Cannon <[EMAIL PROTECTED]> wro
On 6/2/06, Talin <[EMAIL PROTECTED]> wrote:
Ronald Oussoren wrote:> On 1-jun-2006, at 17:44, Brett Cannon wrote:>>I suppose that's at least partially not an issue at the moment>>because you can only add stuff to existing packages through hacks. I
>>wouldn't t
Right now a discussion is going on in python-dev about what is reasonable for special needs of developers who bring in modules to the stdlib. This of course brings up the idea of slimming down the stdlib, having sumo releases, etc.
That makes me think perhaps we should start thinking about collect
One thing I forgot to say in the initial email was that I am being intentially heavy-handed with restrictions on people to get some dialog and see where people think things are okay and not.
On 6/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> This is purely about
On 6/15/06, Talin <[EMAIL PROTECTED]> wrote:
Michael Chermside wrote:> I agree. If we have a PEP with rules for acceptance, then every time we> don't follow those rules exactly we will be accused of favoritism. If> we have informal rules like today and decide things on a case-by-case
> basis, then
On 7/6/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
I would like to propose a syntax that would explicitly be read as"Create an object of Foo converted from object Bar". Being explicit,as such, could bring about some interesting optimizations in thefuture or immediately, and reduce redundant sign
On 7/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Taking the "import system" to be the overall interaction between the Pythonmodule namespace and the file system of the underlying computer, I thought I'dstart compiling a list of the questions we'll want to consider for Py3k. The
answers to some o
On 7/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Walter Dörwald wrote:> I don't know about __call__, but str and unicode don't have __iter__,> list, tuple and dict do:That's probably because str and unicode don't do theirown iteration, but rely on the fallback implementation.
In which case it's pe
On 7/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 7/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:>> >> Why is this a defect? Have we abandoned the notion of SeqIter> >> automatically wrapping any object with __getitem__()?
> >> >> > Actually, the autowrapping was intended a backward
On 8/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Martin,I've thought about it more, and I think it's fine to use a singletype. It will surely simplify many things, and that alone might helpus win back some of the inefficiency this introduces. And it is best
for Python-level users.Woohoo! I
On 8/31/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
I thought I felt in the mood for some abuse today, so I'm proposingsomething sure to give me plenty of crap, but maybe someone will enjoythe idea, anyway.Never hurts too much to try, huh? =) Plus it gives me a break from my work.
This is a s
On 8/31/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
On 8/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> So this feels like the Perl idiom of using die: ``open(file) or die`` (or> something like that; I have never been a Perl guy so I could be off).
>> > ...>> T
On 9/2/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
While looking at the changes necessary to implement the exceptionrelated syntax changes (except ... as ..., raise without type),I came across some more substantial things that I think must be discussed.
You have read Ping's PEP 344, right? * How sh
On 9/2/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
On 9/2/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> Right, which is why the original suggestion came up in the first place. It> would be nice to compartmentalize exceptions entirely, but the worry of
> keeping a ont o
On 9/3/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> Basically. Memory usage goes up if you do this as it stands now.I'm not sure I follow that. The traceback gets created anyway,so how is it going to use more memory if it's attached to a
throwaway exception i
On 9/11/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Toby Donaldson writes:> Any suggestions for how educators interested in the> educational/learning aspects of Python 3000 could more fruitfully> participate?You're doing pretty well so far! Seriously... just speak up: Pythonistas
(including, i
On 9/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Andre Meyer wrote:> While I understand the difficulties in removing the GIL and the> potential negative effect on single-threaded applications I would very> much encourage discussion to seriously consider removing the GIL (maybe
> optionally) in P
On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:> > Before we can decide on the internal representation of our unicode
> > objects, we need to decide on their external interface. My thoughts
On 9/22/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[Michael Chermside]> I don't seem to have gotten anyone one board with the bold> proposal to just rip __del__ out and tell people to learn> to use weakrefs. But I'm hearing general agreement (at least
> among those contributing to this threa
On 10/13/06, Talin <[EMAIL PROTECTED]> wrote:
Giovanni Bajo wrote:>> Therefore, you have to obsolete old stuff if you want there to be>> only One Obvious Way To Do It.>> I'm totally in favor of obsoletion and removal of old cruft from the standard
> library.> I'm totally against not having a standa
On 11/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 11/1/06, Neil Toronto <[EMAIL PROTECTED]> wrote:> Ka-Ping Yee wrote:> > I have finally completed a draft of a PEP on rebinding of names> > in outer scopes. I've tried to go back and gather all of the
> > (amazingly numerous) proposals -- i
On 11/5/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
As an aside to the discussion about "nonlocal", here are a couple ofthoughts on backward compatibility.For some of the proposed keywords, here's the number of occurrencesof the keyword in the current standard library (not including comments
and doc
On 11/17/06, Talin <[EMAIL PROTECTED]> wrote:
Fredrik Lundh wrote:
> Talin wrote:
>
>> I expect to see a series of special-case syntactical work-arounds that
>> compensate for the lack of such a feature.
>
> yeah, because the "special-case syntactical work-arounds" are care-
> fully designed to
On 11/19/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> PEPs aren't only for difficult discussions. :-) They are also there
> for reference and to record agreement. Referring to an email isn't
> really a very good answer when someone asks (as happened here) "what
> is the
On 11/21/06, tomer filiba <[EMAIL PROTECTED]> wrote:
i read the references fredrik posted several days back, and it got
me thinking: why not add a "co_ast" attribute to code objects?
i.e., since (virtually) all code objects are constructed from source
code by compilation, the compiler could jus
On 11/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/24/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 11/23/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > > > I have a working optional argument syntax implementation, I'm
On 11/24/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
> Obviously signature objects would grow support for annotations, but I
> still need the information to be carried on the code object to
> incorporate into signature objects.
>
Signature objects still need a way to know the nested parameters,
On 11/26/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
On Nov 26, 2006, at 1:10 PM, Brett Cannon wrote:
On 11/24/06, Tony Lownds <[EMAIL PROTECTED]> wrote:
>
> > Obviously signature objects would grow support for annotations, but I
> > still need the information to be
On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Some comments:
>
> - Talin's solution seems to require the definition of an awful lot of
> new constants -- one per slot. And a lot of special-casing in the type
> initialization code to handle them because there are so many
On 11/29/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Have you thought much about the issue of different signature? The
> regular method table only has functions taking one or more objects and
> returning an object. (There are a few flags to indicate variations on
> the call ar
nderscore (__special__) naming
convention. A special method may or may not have a slot definition in
PyTypeObject. If there is such a slot, the method pointer will be stored
into it; If there is no such slot, then the method pointer is stored
into the class dict just like a normal method.
Because
On 12/2/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I'd love to see this idea explored; it sounds like it might well be
the right solution. (It's also an extension of the "separate tool for
conversion" idea that I floated earlier.)
One requirement: it should be possible to resume developmen
On 12/2/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:
> So you are basically saying you want the preprocessor step to be
> lightweight enough that you always develop with the file before the
> preprocessor is run instead of with some generated file, right?
On 12/2/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 2, 2006, at 3:58 PM, Neil Toronto wrote:
> One potential problem with this idea is that you can't drop into C
> code
> without calling an external C function, which may not be acceptable in
There is Google Code Hosting: http://code.google.com/hosting/ .
-Brett
On 12/5/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Mike Klaas wrote:
> The "magic" (and I don't mean that derogatorily) I'm talking
> about is the Python <-> c type conversion and assumption that all
> undeclared variables a
On 12/8/06, Talin <[EMAIL PROTECTED]> wrote:
One other minor brainstorm before I head off to work: I'd like function
decorators to work with assignment statements as well as 'def' statements.
Use case:
class Foo:
@private
def myfunc():
pass
@private
On 12/10/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
Has anyone considered consolidating the module pairs that have both a
C and Python implementation? For example, pickle and cPickle and
StingIO and cStringIO. It seems like keeping both around might be
counter productive. It leads to more co
On 12/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I am getting worried about the Py3k release schedule. According to PEP
3000, "I hope to have a first alpha release out sometime in 2007"
which would seem to give us another year at least; but in my mind I've
always interpreted this (and ex
On 12/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 12/18/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> I always wondered about that due date and when you really wanted to cut
an
> alpha.
Despite what the PEP says I've always *thought* of it as "early 2007&
On 12/18/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 12/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>
> Ok, so be it. Let this be a pronouncement -- the only stdlib reorg
> we're doing will be (a) deleting silly old stuff; (b) rename modules
> that don't conform to the current mo
On 12/18/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 12/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> As for using a lib-old idea, is that for Python 2.x to help transition,
> or did you want to do that for Py3K as well? I see the logic in the former
> t
On 12/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 12/18/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 12/18/06, Guido van Rossum <[EMAIL PROTECTED] > wrote:
> > When you say "just store strings" do you mean that the implementation
> > w
On 12/19/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
On 12/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> character, but AFAICT it fizzled; nobody has proposed to help with
> getting the int unification branch, which is mostly done but still has
> 22 failing tests last time I looked. I've re
On 12/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 12/19/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Okay, I updated the patch at SF. While you're at it, in PEP 3100 there's
> "compile(): put in sys (or perhaps in a module of its own)". I guess
that
> isn't really necessary either...
On 12/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 12/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
>
> On 12/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 12/19/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > > Okay, I upd
On 12/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 12/19/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Um, that was tongue-in-cheek. My serious proposal was python-4000, but
> > python-ideas sounds better to me because it won't eventually outdate
> > itself.
>
> pyt
On 12/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:
> No, but I view sys as place to put stuff that influences the running of
> the interpreter and I don't put compile() in that category.
So what about sys.argv, sys.std{in,out,err},
sys.exc_info, etc.
At Guido's suggestion, a new mailing list has been created named
Python-Ideas (http://mail.python.org/mailman/listinfo/python-ideas). This
list is meant as a place for speculative, pie-in-the-sky language design
ideas to be discussed and honed to the point of practically being a PEP
before being
On 12/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I've written a quick version of PEP 3106, which expresses my ideas
about how the dict methods to access keys, values and items should be
redone.
The text is in svn:
http://svn.python.org/view/peps/trunk/pep-3106.txt?rev=53096&view=markup
On 12/20/06, Talin <[EMAIL PROTECTED]> wrote:
1) What's the process for editing a PEP after it has been reviewed, but
before its been accepted?
If you are the original author, just edit it. If you are not, either get
the original author to change it or email python-dev/python-3000 your issue
On 12/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[SNIP]
Ok, so be it. Let this be a pronouncement -- the only stdlib reorg
we're doing will be (a) deleting silly old stuff; (b) rename modules
that don't conform to the current module/package naming convention,
like StringIO, cPickle or Us
On 12/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 12/20/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 12/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Ok, so be it. Let this be a pronouncement -- the only stdlib reorg
> > &g
I am starting to compile the list of modules to suggest for removal and I
noticed that there are still a large number for platform-specific
directories in Lib/. I was wondering if we should consider some platforms
for removal.
The reason I am not sending this to python-dev is I figure we could p
e in on this thread.
-Brett
> On 12/21/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > I am starting to compile the list of modules to suggest for removal and I
> > noticed that there are still a large number for platform-specific
> > directories in Lib/. I was wonderi
On 12/22/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 12/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Andre Roberge wrote:
> >
> > > The various possibilities mentioned in various forums include:
> > >
> > > ask()
> > > ask_user()
> > > get_string()
> > > input() # rejected by BDFL
>
On Dec 14, 2007 11:51 AM, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Python-related projects: join the PyCon Development Sprints!
>
> The development sprints are a key part of PyCon, a chance for the
> contributors to open-source projects to get together face-to-face for
> up to four days of inte
1 - 100 of 430 matches
Mail list logo
