-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 2, 2008, at 6:00 PM, Barry Warsaw wrote:
>
> This is a reminder that I am going to start building the next alpha
> releases for Python 2.6 and 3.0 now. Please, no checkins unless you
> get approval from me, and until you hear that the freez
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| All I really mean to fix is to standardize the terminology,
I have recently been thinking about how to present/explain the basics of
Python3 to someone with no experience of Python1/2 or any need to know
about the
On Thu, Apr 3, 2008 at 12:10 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 2:47 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]>
> wrote:
> > Stop me if I'm wrong, but I thought that bytes objects are immutable
> > (they are based on the PyStringType, after all)
>
> Righ
On Wed, Apr 2, 2008 at 4:45 PM, Paul Prescod <[EMAIL PROTECTED]> wrote:
> Also, could the types module be renamed "builtin_classes" or
> "core_classes" or something like that? It was always a weird name
> because it wasn't if it contained all of the types in a Python
> distribution. Just a set o
No, we're not renaming fundamentals like that. 3.0a4 goes out tomorrow
and we want stability.
On Wed, Apr 2, 2008 at 4:39 PM, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On Wed, Apr 2, 2008 at 11:57 PM,
> > Paul Prescod <[EMAIL PROTECTED]> wrote:
> > > But does anyone
Also, could the types module be renamed "builtin_classes" or
"core_classes" or something like that? It was always a weird name
because it wasn't if it contained all of the types in a Python
distribution. Just a set of core-to-the-implementation ones.
Just out of curiousity: why is the type(x) func
Guido van Rossum wrote:
> On Wed, Apr 2, 2008 at 11:57 PM,
> Paul Prescod <[EMAIL PROTECTED]> wrote:
> > But does anyone else find it odd that the types of some things
> > are classes and the classes of some things are types?
> >
> > >>> type(socket.socket())
> >
> > >>> type("abc")
> >
> > >>>
On Wed, Apr 2, 2008 at 4:19 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 2:14 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Thomas Wouters's changes for variable tuple packing might fix this, if
> > we can agree to add that feature.
> In all fairness, liberating the
On Wed, Apr 2, 2008 at 2:14 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Thomas Wouters's changes for variable tuple packing might fix this, if
> we can agree to add that feature.
>
In all fairness, liberating the argument-unpacking doesn't *require* the
variable sequence unpacking patch, al
On Wed, Apr 2, 2008 at 10:30 PM, Alexander Belopolsky <
[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 3:47 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > > > Thomas Wouters's changes for variable tuple packing might fix
> this, if
> > > > we can agree to add that feature.
> ..
>
Guido van Rossum schrieb:
> On Wed, Apr 2, 2008 at 3:03 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]>
> wrote:
>> On Wed, Apr 2, 2008 at 11:57 PM, Paul Prescod <[EMAIL PROTECTED]> wrote:
>> > But does anyone else find it odd that the types of some things are
>> > classes and the classes of som
No. types *have* a __dict__, but it's readonly.
Some type *instances* don't have a __dict__, but that's up to the
individual type.
All I really mean to fix is to standardize the terminology, especially
in repr().
On Wed, Apr 2, 2008 at 4:04 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
>
>
On 2-Apr-08, at 3:48 PM, Martin v. Löwis wrote:
>> On Wed, Apr 2, 2008 at 5:08 PM, Mike Klaas <[EMAIL PROTECTED]>
>> wrote:
>>> ...and the majority of these cases would work fine with views (input
>>> to sorted(), etc).
>>
>> Suppose "the majority" here means 36 of the 46 cases.
>
> What makes yo
On Wed, Apr 2, 2008 at 6:01 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I don't recall proposing a name change. And I still don't see what
> metaclasses have to do with it; I just mentioned them because 'type'
> is both usable as a built-in function to access an object's class, and
> as a me
I don't recall proposing a name change. And I still don't see what
metaclasses have to do with it; I just mentioned them because 'type'
is both usable as a built-in function to access an object's class, and
as a metaclass (in fact it is the root metaclass).
On Wed, Apr 2, 2008 at 3:58 PM, Benjamin
I have no idea what you are saying here (and I did s/since/sense/ :-).
On Wed, Apr 2, 2008 at 3:34 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Wed, Apr 2, 2008 at 5:20 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Apr 2, 2008 at 3:03 PM, Amaury Forgeot d'Arc <[E
On Wed, Apr 2, 2008 at 5:51 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I have no idea what you are saying here (and I did s/since/sense/ :-).
Another lesson to me, that I should proofread my Python impulses: :P
Especially because of that I think we should do that. list, dict, and set
aren'
On 2-Apr-08, at 3:33 PM, Jason Orendorff wrote:
> On Wed, Apr 2, 2008 at 5:08 PM, Mike Klaas <[EMAIL PROTECTED]>
> wrote:
>> ...and the majority of these cases would work fine with views (input
>> to sorted(), etc).
>
> Suppose "the majority" here means 36 of the 46 cases. Then what
> you're sa
> On Wed, Apr 2, 2008 at 5:08 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
>> ...and the majority of these cases would work fine with views (input
>> to sorted(), etc).
>
> Suppose "the majority" here means 36 of the 46 cases.
What makes you suppose so. In the standard library of Python 2.5, I
cou
On Wed, Apr 2, 2008 at 5:33 PM, Jason Orendorff <[EMAIL PROTECTED]>
wrote:
> On Wed, Apr 2, 2008 at 5:08 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
> > ...and the majority of these cases would work fine with views (input
> > to sorted(), etc).
>
> Suppose "the majority" here means 36 of the 46 ca
On Wed, Apr 2, 2008 at 5:20 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 3:03 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]>
> wrote:
> > On Wed, Apr 2, 2008 at 11:57 PM, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > > But does anyone else find it odd that the types of s
On Wed, Apr 2, 2008 at 5:08 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
> ...and the majority of these cases would work fine with views (input
> to sorted(), etc).
Suppose "the majority" here means 36 of the 46 cases. Then what
you're saying is, if I write .items() without thinking, there's about
On Wed, Apr 2, 2008 at 3:03 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 11:57 PM, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > But does anyone else find it odd that the types of some things are
> > classes and the classes of some things are types?
> >
> > >>>
On 2-Apr-08, at 2:59 PM, Martin v. Löwis wrote:
> Jason Orendorff wrote:
>> On Tue, Apr 1, 2008 at 9:37 PM, "Martin v. Löwis"
>> <[EMAIL PROTECTED]> wrote:
>>> I think it's fairly obvious why the 2.x .keys() has to change. It's
>>> just too wasteful to actually build the list of all keys of a
>
Amaury Forgeot d'Arc wrote:
> Stop me if I'm wrong, but I thought that bytes objects are immutable
> (they are based on the PyStringType, after all)
>
> But I was surprised by this code in test_socket.py::
>
> buf = b" "*1024
> nbytes = self.cli_conn.recv_into(buf)
>
I'm not sur
On Wed, Apr 2, 2008 at 2:47 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Stop me if I'm wrong, but I thought that bytes objects are immutable
> (they are based on the PyStringType, after all)
Right. In 3.0a1 they were mutable, that's probably where these
examples come from.
> But I was
Hello,
On Wed, Apr 2, 2008 at 11:57 PM, Paul Prescod <[EMAIL PROTECTED]> wrote:
> Apologies if this has been discussed before.
>
> But does anyone else find it odd that the types of some things are
> classes and the classes of some things are types?
>
> >>> type(socket.socket())
>
> >>> type
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a reminder that I am going to start building the next alpha
releases for Python 2.6 and 3.0 now. Please, no checkins unless you
get approval from me, and until you hear that the freeze is lifted.
I am now on freenode #python-dev, IM, and
Jason Orendorff wrote:
> On Tue, Apr 1, 2008 at 9:37 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> I think it's fairly obvious why the 2.x .keys() has to change. It's
>> just too wasteful to actually build the list of all keys of a dictionary
>> (or even of all values, as you have to creat
Apologies if this has been discussed before.
But does anyone else find it odd that the types of some things are
classes and the classes of some things are types?
>>> type(socket.socket())
>>> type("abc")
>>> socket.socket().__class__
>>> "abc".__class__
In a recent talk I could only explain
On Tue, Apr 1, 2008 at 9:37 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I think it's fairly obvious why the 2.x .keys() has to change. It's
> just too wasteful to actually build the list of all keys of a dictionary
> (or even of all values, as you have to create all the tuples as well),
>
Stop me if I'm wrong, but I thought that bytes objects are immutable
(they are based on the PyStringType, after all)
But I was surprised by this code in test_socket.py::
buf = b" "*1024
nbytes = self.cli_conn.recv_into(buf)
And this in getargs.c::
case 'w': { /* memory b
On Wed, Apr 2, 2008 at 11:36 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The problem is that if you make the slow and fool-proof implementation
> the common name, you'll have to invent another name for the fast (but
> sometimes less convenient) method. This is what we ended up doing in
>
On Wed, Apr 2, 2008 at 3:47 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Thomas Wouters's changes for variable tuple packing might fix this, if
> > > we can agree to add that feature.
..
>
> Thomas isn't finished yet.
The reason I am asking is that I've been looking into ways of f
On Wed, Apr 2, 2008 at 12:39 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 1, 2008 at 8:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ..
> > Thomas Wouters's changes for variable tuple packing might fix this, if
> > we can agree to add that feature.
> >
>
> Do you
On Tue, Apr 1, 2008 at 8:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
> Thomas Wouters's changes for variable tuple packing might fix this, if
> we can agree to add that feature.
>
Do you mean http://bugs.python.org/issue2292 ? From description it
does not seem to address function call
> Is there a particular rationale describing the use of function calls
> vs. object properties in core Python?
>
> When I see a function call required for something that could be
> conveniently expressed as a property, it generally tells me "I'm
> computing something. It might be expensive,
We went over this a few years ago when we first reviewed this design
from every POV. We decided that .keys() has been ingrained in the
collective mind of Python users for such a long time that it would be
a mistake to change it.
On Wed, Apr 2, 2008 at 11:57 AM, Ivan Krstić
<[EMAIL PROTECTED]> wrot
On Apr 2, 2008, at 11:36 AM, Guido van Rossum wrote:
> I predict that list(x.keys()) will remain a rarity (except in
> code converted by 2to3). However sorted(x.keys()) will become a
> well-known idiom, and it's a much better one than the old idiom
> keys = x.keys()
> keys.sort()
> which doesn't
On Tue, Apr 1, 2008 at 11:00 PM, David Pokorny <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 1, 2008 at 7:37 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I think it's fairly obvious why the 2.x .keys() has to change. It's
> > just too wasteful to actually build the list of all keys of a dict
> The biggest concern I have is over whether the following works:
>
> for i, k in enumerate(d.keys()):
> if i % 2: del d[k]
>
> If this code works as is in py3k, I have no concerns over whether
> keys(), etc., return snapshots or live views.
Define "works". This code does not "work"
On Wed, Apr 2, 2008 at 6:30 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> One of the issues with porting to Py3k is the problem that __getattr__
> and __getattribute__ can't reliably provide special methods like __add__
> the way __getattr__ could with classic classes. (As first noted by Terry
>
On Wed, Apr 2, 2008 at 7:30 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> One of the issues with porting to Py3k is the problem that __getattr__
> and __getattribute__ can't reliably provide special methods like __add__
> the way __getattr__ could with classic classes. (As first noted by Terry
>
On Tue, Apr 1, 2008 at 11:39 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
...
> > keys = mydict.keys()
> > keys.sort()
> > for key in keys:
>
> That is indeed a frequent case in 2.x. Fortunately, it is what David
> calls "loud" breakage:
>
> py> keys = mydict.keys()
> py> keys.sort()
Michael Urman schrieb:
> for i, k in enumerate(d.keys()):
> if i % 2: del d[k]
>
> If this code works as is in py3k, I have no concerns over whether
> keys(), etc., return snapshots or live views. If this code instead
> requires the snapshot that list(d) or list(d.keys()) provides, the
Michael Urman gmail.com> writes:
> The biggest concern I have is over whether the following works:
>
> for i, k in enumerate(d.keys()):
> if i % 2: del d[k]
>
Well:
Python 3.0a3+ (py3k, Mar 30 2008, 21:14:40)
[GCC 4.2.3 (4.2.3-5mnb1)] on linux2
Type "help", "copyright", "credits"
2008/4/2, David Pokorny <[EMAIL PROTECTED]>:
> describe, but I don't understand why the behavior of the most common
> name should be the most efficient implementation of the most common
> scenario. One could propose an alternate policy: the behavior of the
Half of the magic power of Python, IM
On Wed, Apr 2, 2008 at 1:39 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I'd say not clear, for two reasons. One is that I pretty much never
> > use keys() in a for loop, I just use the dictionary.
>
> Ok. Consider items() then. Again, I claim that the common use of
> items() is to iterate
One of the issues with porting to Py3k is the problem that __getattr__
and __getattribute__ can't reliably provide special methods like __add__
the way __getattr__ could with classic classes. (As first noted by Terry
Reedy years ago, and recently seeing some new activity on the bug
tracker [1])
On Wed, Apr 2, 2008 at 9:58 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> > > In the py3k branch I've assigned the audio resource to the winsound
> > > tests. Only regrtest.py -uall or -uaudio runs the winsound test.
> > Reason:
> > > the test sound was freaking out my poor cat. :/
> >
> > I f
> > In the py3k branch I've assigned the audio resource to the winsound
> > tests. Only regrtest.py -uall or -uaudio runs the winsound test.
> Reason:
> > the test sound was freaking out my poor cat. :/
>
> I feel with your cat ;-).
> This would not help on the buildbot since it runs 'rt.bat -d -q
On Wed, Apr 2, 2008 at 4:36 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Tue, Apr 1, 2008 at 6:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Well, it *is* part of the public interface of io.py, and it *is* the
> > implementation of the built-in open() function. So I don't th
52 matches
Mail list logo
