Guido van Rossum 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
>
> At some point it wi
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
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
At some point it will appear on python.org: http://python.o
On 12/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Well, sys is pretty much a grab-bag.
>
> That is very true. =) I talked about breaking it up. Still want to see a
> PEP on that someday?
>
> > And you can't tell me that
> > compile() isn't a hook into system internals. :-) (The compiler i
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/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 updated the patch at SF. While you're at it, in PEP
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 updated the patch at SF. While you're at it, in PEP 3100 there's
> > > "compile(): put in sys (or perhaps in a m
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/18/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
[me]
> > Well, what do you think of my pronouncement in response to Thomas's
> > mail (just rename a bunch of things that don't conform to our own
> > naming standard)? That should limit the discussion to what's the best
> > name for StringIO etc
On 12/18/06, Talin <[EMAIL PROTECTED]> wrote:
> There's a Python prototype of the string formatting PEP in my Mercurial
> repository here:
>
> http://www.viridia.org/hg/python/string_format
>
> The main thing that needs to be done is to graft what's there in the
> prototype into the actual
On 12/19/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > - turning list comprehensions into syntactic sugar for generator expressions
>
> I'd like to point out that there is already my patch for that, which
> implements
> set comprehensions and list comprehensions exactly as syntactic sugar for
>
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...
Hm, I think it would be fine to move, it's pretty specializ
On 12/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> 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 d
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/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 received a few contributions
> I'd also like to see peo
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
> > would be limited to strings or just that you wou
On Tuesday 19 December 2006 16:47, Terry Reedy wrote:
> I am pretty sure that a large majority of people learning Python for the
> first time with Python 3 would prefer this. If Python3 is as successful
> as we might hope, new Pythoneers will become the majority.
Agreed. Those who are interes
On 12/19/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Neal Norwitz" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > What do we want to do with the current versionadded/versionchanged
> > markups in the doc for 3k? Should we remove all references to 1.x
> > changes? all 2.x chan
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
> > would be limited to strings or just that you would only use it to
> > store per-argument docstrings? The lat
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> What do we want to do with the current versionadded/versionchanged
> markups in the doc for 3k? Should we remove all references to 1.x
> changes? all 2.x changes? Keep them? all of them?
>
> Given we are trying to cl
On 12/18/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> 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 ye
On 12/19/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Tuesday 19 December 2006 16:03, Neal Norwitz wrote:
> > have all the doc be clean. My only concern is that it might be
> > confusing for people. Though my first guess is that it won't be any
> > more confusing than anything else w
On Tuesday 19 December 2006 16:03, Neal Norwitz wrote:
> have all the doc be clean. My only concern is that it might be
> confusing for people. Though my first guess is that it won't be any
> more confusing than anything else we do, so I'd prefer to see it
> cleaned up.
Remove them from the
Guido van Rossum wrote:
> I'm allowing for small incompatibilities between 3.0, 3.1 and 3.2 only
> because I expect that 3.0, when it comes out, will be the first
> version that most users will try, and we will surely have to release a
> few quick upgrades to address the most egregious mistakes. B
What do we want to do with the current versionadded/versionchanged
markups in the doc for 3k? Should we remove all references to 1.x
changes? all 2.x changes? Keep them? all of them?
Given we are trying to clean things up, I think I'd prefer to remove
all the old references to 1.x/2.x changes.
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
> to help transition but in the
Guido van Rossum schrieb:
> 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.
>>
>> python-future. (python-ideas
Barry Warsaw schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Dec 19, 2006, at 1:03 PM, Guido van Rossum wrote:
>
>> On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>> Georg Brandl wrote:
>>>
so what about id() and intern(). Care to pronounce?
>>>
>>> moving/removing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 19, 2006, at 1:03 PM, Guido van Rossum wrote:
> On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Georg Brandl wrote:
>>
>>> so what about id() and intern(). Care to pronounce?
>>
>> moving/removing id()? please don't do that; id(obj) a
Guido van Rossum wrote:
>> an alternative would be to move concrete 3.0-related implementation
>> discussions back to python-dev, and keep this list for Python 3.0 PEP
>> work and "year 3000" stuff.
>
> But that's confusing since the 3.0 PEP work is *also* concrete
> implementation related (at le
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.
>
> python-future. (python-ideas is a little too ambiguous, as it c
Guido van Rossum schrieb:
> On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Georg Brandl wrote:
>>
>> > so what about id() and intern(). Care to pronounce?
>>
>> moving/removing id()? please don't do that; id(obj) and type(obj) are
>> essential tools for learning object semantics, and sho
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.
python-future. (python-ideas is a little too ambiguous, as it could also
overlap with python-users.)
-- Talin
On 12/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I think a reasonable solution here is to make the C version an
> > optional implementation detail of the Python version, such as was done
> > for the heapq module already (the C version is _heapq and
> > automaticall
Yes, please move this to python-dev.
On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > So think about what you think would make sense, perhaps propose it here,
> > and/or write a PEP.
>
> here's the PEP:
>
>http://mail.python.org/pipermail/python-3000/2006-Nov
On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
>
> > so what about id() and intern(). Care to pronounce?
>
> moving/removing id()? please don't do that; id(obj) and type(obj) are
> essential tools for learning object semantics, and should be trivial to
> access and use
On 12/19/06, Jim Jewett <[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 module/
On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > - a spec for the string unification (Perhaps Fredrik has done some
> > work on it in one of those threads that I haven't opened yet?)
>
> I seem to remember that Google developers have access to other
> developer'
On 12/19/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 12/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > > [EMAIL PROTECTED] anyone?
> >
> > Quaint. I can live with that.
>
> While I'm not against it, python-ideas may be a better name, simply
> because it doesn't have a connotation that any c
On Dec 18, 2006, at 5:14 PM, Guido van Rossum wrote:
> On 12/18/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
>>> - optional signature annotations (but without type checking
>>> connotations); e.g. ``def foo(a: 42) -> "hello kitty": pass'' should
>>> be fine; see my Artima blogs
>>
>> I have been
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 module/package naming convention,
> like StringIO, cPickle or User
Josiah Carlson wrote:
> So think about what you think would make sense, perhaps propose it here,
> and/or write a PEP.
here's the PEP:
http://mail.python.org/pipermail/python-3000/2006-November/004147.html
also see mike's concretization here:
http://mail.python.org/pipermail/python-dev/2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 19, 2006, at 12:10 AM, Josiah Carlson wrote:
>> I feel strongly that modules os, os.path, shutil, etc. that deal with
>> files and paths need reorganizing.
>
> So think about what you think would make sense, perhaps propose it
> here,
> and/o
Georg Brandl wrote:
> so what about id() and intern(). Care to pronounce?
moving/removing id()? please don't do that; id(obj) and type(obj) are
essential tools for learning object semantics, and should be trivial to
access and use.
___
Python-3000
Guido van Rossum schrieb:
[snip... full ACK]
> For example, there are some PEPs that I'd like to see written where
> the basic goal has been firmly established but the details need
> working out:
>
> - a collection of ABCs to be used with the standard types; see Bill
> Janssen's wiki page
> - op
Guido van Rossum wrote:
> Perhaps we can create a python-4000 list for folks who would like to
> discuss changes to the language beyond Python 3.0
an alternative would be to move concrete 3.0-related implementation
discussions back to python-dev, and keep this list for Python 3.0 PEP
work and "
On 12/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] anyone?
>
> Quaint. I can live with that.
While I'm not against it, python-ideas may be a better name, simply
because it doesn't have a connotation that any conclusions reached on
the list are unlikely to be implemented :-
Guido van Rossum wrote:
> I think a reasonable solution here is to make the C version an
> optional implementation detail of the Python version, such as was done
> for the heapq module already (the C version is _heapq and
> automatically imported by heapq.py if it exists). If this requires
> that s
Manuzhai wrote:
> Guido van Rossum wrote:
>> - make keys(), items(), values() return pseudo-sets/collections rather
>> than lists
>
> Great to see you're back on the Py3k thing (but Mondrian looks really
> cool!).
>
> I got the impression before that keys(), items() and values() would
> become
Guido van Rossum wrote:
> - a spec for the string unification (Perhaps Fredrik has done some
> work on it in one of those threads that I haven't opened yet?)
I seem to remember that Google developers have access to other
developer's home directories, but I thought that only applied to
Google emp
Guido van Rossum wrote:
> - make keys(), items(), values() return pseudo-sets/collections rather
> than lists
Great to see you're back on the Py3k thing (but Mondrian looks really
cool!).
I got the impression before that keys(), items() and values() would
become generators (or iterators) that d
51 matches
Mail list logo
