On 9/4/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> According to PEP 358, "bytes" will be in both 2.6 and 3.0. It would
> be nice if the C API for "bytes" existed in the trunk, so that it
> could be used for new code that will port more easily to 3.0.
>
> Bill
I assume this includes the new b
This is the plan. We're just short on cheap labor to implement it. I
wish I could quote an email that you sent long, long ago (in ILU
times) about having set up a drummer in the back of the room to entice
the 50 coding slaves to more productivity. I believe there was a whip
involved too. :-)
On 9/
According to PEP 358, "bytes" will be in both 2.6 and 3.0. It would
be nice if the C API for "bytes" existed in the trunk, so that it
could be used for new code that will port more easily to 3.0.
Bill
___
Python-3000 mailing list
Python-3000@python.org
I am prepping for a presentation on Python 3.0 that I am giving
tonight and I had some questions about PEP 3121 that the example
creates.
First is whether the name of the function that returns the
module-specific memory is PyModule_GetData() or PyModule_GetState()?
The former is listed by the PEP
Hi,
I recently worked on Python audio device support for Linux and OS X. Not
so recently, I wrote a DirectSound module for win32.
Python 2 has support for various audio devices, but they have no common
interface and some are broken or obsolete. Python 3000 might be a chance
to improve on this.
2007/9/4, Greg Ewing <[EMAIL PROTECTED]>:
> I think its main use is as a source of functions for passing
> to map(). Unless I'm mistaken, that's still going to be faster
Or to sort:
>>> import operator
>>> l = [(1, 3), (2, 2)]
>>> sorted(l, key=operator.itemgetter(1))
[(2, 2), (1, 3)]
>>>
Regar
Guido van Rossum wrote:
> PS. I don't know how useful the operator module really is
I think its main use is as a source of functions for passing
to map(). Unless I'm mistaken, that's still going to be faster
than a listcomp when a built-in function is used, isn't it?
--
Greg
_
Nicholas Bastin wrote:
> On 9/4/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> > Well, what about dict((x, d[x]) for x in d) ? Doesn't strike me as ugly...
>
> It doesn't strike me as ugly, it just strikes me as slow.
Are people forgetting that in 3.0
dict(d.items())
will do the same thing
Noam Raphael wrote:
> Just out of curiousity - do you remember these reasons?
I don't remember the discussion in detail, but a couple of
reasons that come to mind:
* It would be confusing to have "x in d" and "for x in d"
meaning subtly different things.
* It's more efficient to iterate over ju
Guido van Rossum wrote:
> Since IndexError and KeyError are conceptually like ValueError but in
> a more narrowly defined context, I think IndexError and KeyError
> actually make sense here (even though they don't inherit from
> ValueError).
>
> --Guido
Okay, I'll change these to IndexError and K
On 9/4/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Georg Brandl schrieb:
> Oh, and another thing: the items views can contain unhashable values, so
>
> d.items() & d.items()
>
> will fail for such dictionaries since the operands are converted to sets
> before doing the intersection.
>
> I suspec
>>> What use case are you thinking of that this would address?
>> It would allow to treat the items view as a proper set (which
>> it still is).
>
> Can you give some examples?
You mean, actual applications where people would want to perform
set operations on .items()? No - I was just trying to g
"Noam Raphael" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The reasoning is simple: Iteration over an object usually gets all the
| data it contains. A dict can be seen as an unordered collection of
| tuples (key, value), indexed by key. So, iteration over a dict should
| yield
On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >>> Oh, and another thing: the items views can contain unhashable values
> >> That, of course, could be fixed: if the key-value pairs would only
> >> has
Guido van Rossum schrieb:
> On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> Oh, and another thing: the items views can contain unhashable values
>> That, of course, could be fixed: if the key-value pairs would only
>> hash by key (ignoring the value), they would remain hashable.
>
> Ho
> I've been doing some profiling of 3.0 vs. 2.6 release builds on
> Windows XP for the purpose of hopefully closing the performance
> gap. This data is very preliminary, but I thought I'd throw it out
> here in case someone else also wanted to look into this. Also,
> possibly useful for comparing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 4, 2007, at 2:08 PM, Brett Cannon wrote:
> On 9/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Since x[a:b] is not basic syntax (like it once was) but simply the
>> combination of operator.getitem and slice() I don't see the point of
>> k
On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Oh, and another thing: the items views can contain unhashable values
>
> That, of course, could be fixed: if the key-value pairs would only
> hash by key (ignoring the value), they would remain hashable.
I understand what you mean, but wi
On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Oh, and another thing: the items views can contain unhashable values
>
> That, of course, could be fixed: if the key-value pairs would only
> hash by key (ignoring the value), they would remain hashable.
How would that help? The key/value
> Oh, and another thing: the items views can contain unhashable values
That, of course, could be fixed: if the key-value pairs would only
hash by key (ignoring the value), they would remain hashable.
Regards,
Martin
___
Python-3000 mailing list
Python-3
On 9/4/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Georg Brandl schrieb:
> > While looking at documenting the dict view changes, I came across an
> > inconsistency in how the dict views' set-like operations are implemented:
> > with sets/frozensets, the operator versions only work if the other op
On 9/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> After Nick's last message I went searching for "iteritems" in the docs. I
> fixed a couple places (not yet checked in), but eventually came across
> Mailbox.iteritems. Looking at the mailbox.py code, sure enough, it still
> exists:
>
>
On 9/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Since x[a:b] is not basic syntax (like it once was) but simply the
> combination of operator.getitem and slice() I don't see the point of
> keeping operator.getitem.
>
> PS. I don't know how useful the operator module really is -- in all
> th
Georg Brandl schrieb:
> While looking at documenting the dict view changes, I came across an
> inconsistency in how the dict views' set-like operations are implemented:
> with sets/frozensets, the operator versions only work if the other operand
> is a set/frozenset, while the dict view operators a
On Sep 4, 2007, at 1:27 PM, [EMAIL PROTECTED] wrote:
> After Nick's last message I went searching for "iteritems" in the
> docs. I
> fixed a couple places (not yet checked in), but eventually came across
Timing is great! I checked in a bunch of doc changes on this exact
topic. Watch for con
After Nick's last message I went searching for "iteritems" in the docs. I
fixed a couple places (not yet checked in), but eventually came across
Mailbox.iteritems. Looking at the mailbox.py code, sure enough, it still
exists:
def iteritems(self):
"""Return an iterator over (key, mess
While looking at documenting the dict view changes, I came across an
inconsistency in how the dict views' set-like operations are implemented:
with sets/frozensets, the operator versions only work if the other operand
is a set/frozenset, while the dict view operators allow any iterable.
Do we care
On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > (assuming d[x] is O(log n))
>
> In Python, d[x] is typically considered to be O(1) (unlike in C++,
> where it is O(log n)). Of course, with Python using a hashtable,
> performance may decrease in the presence of collisions. In the
> nor
On 9/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/4/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> > However, all that said, you'd probably
> > never write the above line of code, and d.iteritems() will continue to
> > suffice if there are concerns about 'for (k,v) in d' being materia
Thanks, Mark! Fixed by changing "B\n" into "B". :-)
On 9/3/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> Forwarded: a comment on the 3.0 What's New.
>
> --amk
>
>
> -- Forwarded message --
> From: Mark Summerfield <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Date: Sat, 1 Sep 2007
On 9/4/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > (assuming d[x] is O(log n))
> >
> > In Python, d[x] is typically considered to be O(1) (unlike in C++,
> > where it is O(log n)). Of course, with Python using a hashtable,
> > perf
I've added a basic skeleton of documentation for the "abc" module, but it
would be nice if somebody proofread it and at add more from PEP 3119 if
desired.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and
On 9/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > (assuming d[x] is O(log n))
>
> In Python, d[x] is typically considered to be O(1) (unlike in C++,
> where it is O(log n)). Of course, with Python using a hashtable,
> performance may decrease in the presence of collisions. In the
> norma
Guido van Rossum wrote:
> On 9/4/07, Noam Raphael <[EMAIL PROTECTED]> wrote:
>> On 9/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>>> Noam Raphael wrote:
The default dict iterator should in principle be iteritems(), and not
iterkeys().
>>> This was discussed at length back when "in" suppor
> (assuming d[x] is O(log n))
In Python, d[x] is typically considered to be O(1) (unlike in C++,
where it is O(log n)). Of course, with Python using a hashtable,
performance may decrease in the presence of collisions. In the
normal case, dict((x, d[x]) for x in d) will be O(n) in Python.
Regards
On 9/4/07, Noam Raphael <[EMAIL PROTECTED]> wrote:
> On 9/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Noam Raphael wrote:
> > > The default dict iterator should in principle be iteritems(), and not
> > > iterkeys().
> >
> > This was discussed at length back when "in" support was
> > added to di
I only care about getting this right when there is a reasonable chance
that a class is being used as an object. For example, at the sprint we
ran into this with the __format__ special method, when someone
discovered that format(object, "") raised a weird error rather than
returning str(object), whi
Since x[a:b] is not basic syntax (like it once was) but simply the
combination of operator.getitem and slice() I don't see the point of
keeping operator.getitem.
PS. I don't know how useful the operator module really is -- in all
those years it's existed I haven't really used it myself, and I'm
al
On 9/4/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Noam Raphael schrieb:
> > Just out of curiousity - do you remember these reasons? I just have
> > the feeling that back then, iterations were less common, since you
> > couldn't iterate over dicts without creating new lists, and you didn't
> > ha
Noam Raphael schrieb:
> On 9/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Noam Raphael wrote:
>> > The default dict iterator should in principle be iteritems(), and not
>> > iterkeys().
>>
>> This was discussed at length back when "in" support was
>> added to dicts. There were reasons for choosin
On 9/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
> > The default dict iterator should in principle be iteritems(), and not
> > iterkeys().
>
> This was discussed at length back when "in" support was
> added to dicts. There were reasons for choosing to do it
> the way it's done
Georg Brandl wrote:
> Thomas Heller schrieb:
>
>> IIUC, in py3k, classic classes do not exist any longer, so the __metaclass__
>> line
>> has no effect anyway. Is this behaviour intended?
>
> It is another incarnation of special methods being looked up on the class,
> not the instance. This was
Thomas Heller schrieb:
> IIUC, in py3k, classic classes do not exist any longer, so the __metaclass__
> line
> has no effect anyway. Is this behaviour intended?
It is another incarnation of special methods being looked up on the class,
not the instance. This was always the behavior with new-sty
On 9/4/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Shouldn't the __getattr__ implementation find the __iter__ method
> of the _stream instance variable?
No. For new-style classes, the special methods (that are part of the PyType
C struct) are always looked up on the class, never the instance.
I was looking into the Lib\test\test_uuid on Windows, which fails with this
traceback:
test test_uuid failed -- Traceback (most recent call last):
File "C:\buildbot\work\3.0.heller-windows\build\lib\test\test_uuid.py", line
323, in test_ipconfig_getnode
node = uuid._ipconfig_getnode()
Fi
Noam Raphael wrote:
> The default dict iterator should in principle be iteritems(), and not
> iterkeys().
This was discussed at length back when "in" support was
added to dicts. There were reasons for choosing to do it
the way it's done, and I don't think it's likely to be
changed.
--
Greg
__
Noam Raphael schrieb:
> As I see it, the only reason for the current status is the desire to
> make "x in dict" equivalent to "dict.has_key(x)", since has_key is a
> common operation and "x in" is shorter. But actually "dict.has_key(x)"
> explains exactly what's intended, while "x in dict" isn't r
On 9/4/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> Are they useful enough to keep?
operator.*slice? They're rather convenient when you don't want to bother
with creating a slice object yourself, but I'm not worried either way.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature viru
Hello,
Just a thought that came to me after writing a code that deals quite a
lot with dicts:
The default dict iterator should in principle be iteritems(), and not
iterkeys().
This is probably just theoritical, since it will break a lot of code
and not gain a lot, but it may be remembered when s
On 9/4/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
>
> On 9/3/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 8/31/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I haven't heard yet that merging is impossible or useless; there's
> > > still a lot of similarity between the tru
50 matches
Mail list logo
