On 29-Jul-08, at 7:32 AM, Jesus Cea wrote:
Working on the 3.0 version of bsddb, I have the following issue.
Until 3.0, keys and values were strings. For bsddb, they are opaque,
and
stored unchanged.
In 3.0 the string type is replaced by unicode. A new "byte" type is
added. So, code like "d
On 28-May-08, at 6:23 PM, Daniel Wong wrote:
Currently, I must do the following instead:
for n, pair in enumerate(list_of_pairs):
a, b = pair
...
<>
Thoughts?
I find it hard to believe that you have even attempted this, which has
been valid in python for ages:
>>> for x, (a, b) in enu
On 29-Apr-08, at 2:08 PM, Brett Cannon wrote:
On Tue, Apr 29, 2008 at 8:05 AM, Alex Martelli <[EMAIL PROTECTED]>
wrote:
[SNIP - Alex's well-argued reasons to keep sched]
And then, if needed, we can discuss pure simulation (as opposed to
simulation-testing of systems designed to normally use
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 ma
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
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
>
On 29-Jan-08, at 2:29 PM, Greg Ewing wrote:
> Jim Jewett wrote:
>
>> The majority of uses need a mutable set that starts empty.
>
> Does anyone have evidence to support that assertion?
>
> Thinking about my own code, I probably do membership
> tests on constant sets (represented as tuples) about
On 18-Jan-08, at 1:37 PM, Lars Immisch wrote:
>
> I like cmp, too. I've looked through my code, and I've only used it in
> script-ish circumstances, but here is an example that sorts a list of
> files by modification date:
>
> def cmp_mtime(f, g):
> """Too much for a lambda for my tastes."""
>
On 14-Jan-08, at 5:49 PM, Jeffrey Yasskin wrote:
> On Jan 14, 2008 2:55 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
>> This is a misleading name. The number returned from qsize() [not
>> size
>> ()] is perfectly reliable, in the sense that it is the exact size of
>
On 14-Jan-08, at 1:32 PM, Charles Merriam wrote:
> Not to be pedantic, but the major concern others are voicing is that
> is that queue size is not reliable and is therefore a potential source
> of hard to find threading bugs by naive users. Why not just rename
> q.size() to the unweildy name of
On 11-Jan-08, at 11:13 AM, Raymond Hettinger wrote:
> I proposed to remove three methods from the queue module, qsize(),
> empty(), and full(). These are not reliable. The RightWay (tm) is
> to trap the Empty and Full exceptions or use the .join() approach.
-1. There are several "advisory"
On 9-Jan-08, at 11:41 AM, Oleg Broytmann wrote:
> On Wed, Jan 09, 2008 at 11:34:59AM -0800, Brett Cannon wrote:
>> On Jan 9, 2008 11:34 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>>>newlist = oldlist.sort(key=lambda v: v.attr_x)
>>
>> And don't forget about operator.attrgetter().
>
>I d
On 25-Sep-07, at 2:01 PM, Mark Summerfield wrote:
> On 2007-09-25, Guido wrote:
>>
>> For that to happen, someone has to write a production-quality
>> implementation, release it as a separate 3rd party module for a
>> while,
>> show that it is sufficiently stable and popular to be incorporated i
On 16-Sep-07, at 4:03 PM, Greg Ewing wrote:
> Paul Moore wrote:
>> On 15/09/2007, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>>
>>> similarly for the environment. os.environ dict
>>> should be bytes object keys and values
>>
>> You can't have bytes as keys - the type isn't hashable...
>
> Has th
On 10-Sep-07, at 8:33 AM, Thomas Wouters wrote:
> Alternatively, if you know what you're doing, you can edit the
> svnmerge-integrated property on the branch directly -- but don't
> mess it up :)
>
svnmerge also has a handy -M flag that marks a (set of) revisions as
merged, but doesn't act
On 8-Aug-07, at 2:28 AM, Nick Maclaren wrote:
> I have needed to push my stack to teach REs (don't ask), and am
> taking a look at the RE code. I may be able to extend it to support
> RFE 694374 and (more importantly) atomic groups and possessive
> quantifiers. While I regard such things as revo
On 6-Aug-07, at 7:06 PM, Guido van Rossum wrote:
> On 8/6/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
>> For instance, it is quite common to use integers as keys. If you are
>> inserting keys in order, it is about a hundred times faster to encode
>> the ints in big-
On 6-Aug-07, at 5:39 PM, Guido van Rossum wrote:
>
> I thought about this issue some more.
>
> Given that the *dbm types strive for emulating dicts, I think it makes
> sense to use strings for the keys, and bytes for the values; this
> makes them more plug-compatible with real dicts. (We should id
On 22-Jun-07, at 2:44 PM, Jean-Paul Calderone wrote:
> On Fri, 22 Jun 2007 14:28:12 -0700, Alex Martelli
> <[EMAIL PROTECTED]> wrote:
>
> Could be. I don't find many of my programs to be bottlenecked on
> compilation time or import time, so these optimizations look like
> pure lose to me.
Nor
On 20-Jun-07, at 10:51 AM, Jean-Paul Calderone wrote:
> On Wed, 20 Jun 2007 10:24:55 -0700, Guido van Rossum
> <[EMAIL PROTECTED]> wrote:
>
> > OTOH, pragmatically, people will generally use text strings for
> db keys.
>>
>> I'm not sure how to decide this; perhaps we need to take it public.
>
On 19-Jun-07, at 12:13 PM, Bill Janssen wrote:
>> map (especially the new iterized version) is a frequently-used
>> builtin, while reduce is a rarely-used builtin that requires some
>> head-wrapping. It makes sense to me to move it out of builtins.
>
> I've never understood this kind of argument
On 19-Jun-07, at 10:51 AM, Bill Janssen wrote:
>
> Though, from the standpoint of pragmatism, removing "reduce" from the
> built-in space will break code (*my* code, among others), and leaving
> it in will not affect "purity", as both "map" and "reduce" are being
> left in. So leaving it alone se
On 25-May-07, at 6:03 AM, Steve Howell wrote:
>
> We're just disagreeing about whether the Dutch tax law
> programmer has to uglify his environment with an alias
> of Python to "python3.0 -liberal_unicode," or whether
> the American programmer in an enterprisy environment
> has to uglify his envi
On 24-May-07, at 3:33 PM, Martin v. Löwis wrote:
>> Alas, the coding directive is not good enough. Have a look at this:
>>
>> http://zesty.ca/python/tricky.png
>>
>> That's an image of a text editor containing some Python code. Can
>> you
>> tell whether running it (post-PEP-3131) will del
On 16-May-07, at 6:06 PM, tomer filiba wrote:
>
> === help people who can't type english ===
> since the keywords remain ASCII, along with stdlib and all other major
> third party libs -- how does that help the english-illiterate
> programmer?
>
> import random
> 満は = range(100)
> ra
On 5/9/07, Talin <[EMAIL PROTECTED]> wrote:
<>
> This much I agree: There's no point in talking about supporting multiple
> processors using threads as long as we're living in a refcounting world.
<>
But python isn't--CPython, though, certainly is. The CPython
interpreter has enormous stability,
On 5/4/07, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
> maybe we could have a "dedent" literal that would remove the first newline and
> all indentation so that you can just write:
>
> call_something( d'''
> first part
> second line
> third line
On 5/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
>
> > http://mail.python.org/pipermail/python-3000/2006-April/001526.html
> >
> > where Guido states that he trusts me that it can be made to work,
> > and that "eventually" it needs to be supported.
+0
> He says "the tools
On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 4/23/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
> > Might it be possible to include variance bars?
>
> I'm not really sure what variance bars would reveal. Performing
> exactly the same operations fol
On 4/23/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> So you can see the performance of the BList in more detail, I've made
> several performance graphs available at the following link:
>http://stutzbachenterprises.com/blist/
Very cool. These detailed timings are very useful.
Might it b
On 4/16/07, Chris Rebert <[EMAIL PROTECTED]> wrote:
> I think someone has probably proposed this before, but why not use "{,}"
> as the empty set literal?
If you're sure, did you look for it first?
http://mail.python.org/pipermail/python-3000/2006-April/001400.html
-Mike
On 3/19/07, Andrew McCollum <[EMAIL PROTECTED]> wrote:
> > Changes like this don't do much for me. Sure, lowercase modifiers are
> > prettier, but why remove the general functionality and leave in a few
> > special cases, especially when functionality to display numbers in
> > those formats exist
> Semantic Changes
>
>
> The behavior of the 'int' builtin when passed a radix of 0 will be changed to
> follow the above grammar. This change is to maintain the specified behavior
> [5]_ that a radix of 0 mirrors the literal syntax. The behavior of this
> function will otherwise n
On 2/13/07, Chris Rebert <[EMAIL PROTECTED]> wrote:
> This PEP proposes new semantics for default arguments to remove
> boilerplate code associated with non-constant default argument values,
> allowing them to be expressed more clearly and succinctly.
> Specifically,
> all defau
On 1/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> * 'collections' package
>
> + heapq
> + Queue
Putting this in a collections package might exacerbate the confusion
over its intended use. It really is more of a threading
synchronization tool than a general queue datastructure (though it
On 1/2/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> Additionally, base32 and base16 are not supported by codecs,
> according to the docs, and neither is the ability to specify
> alternate character mappings (I don't know how heavily used the
> last is, though).
We use the "urlsafe" version hea
On 1/1/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> * new
> + Just a rebinding of names from the 'types' module.
> + Can also call ``type`` built-in to get most types easily.
Perhaps 'types' should be deprecated instead?
obj.x = new.instancemethod(...
has a very pleasing ring to it (per
On 12/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Mike Klaas wrote:
>
> > Reducing the pyrex magic and adding more detailed errors to the code
> > generator should eliminate much of the "code-peering" that is
> > currently necessary (at least, by me) whe
On 12/2/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Regardless, one could take a Pyrex bent on this and having Python-like
> > method declarations but have C as the code body::
>
> (some days, I wonder if we shouldn't just include Pyrex and tell every-
> one to use that for *all* their extens
On 11/16/06, George Sakkis <[EMAIL PROTECTED]> wrote:
>
> I agree. For me, the bottom line and the main argument for dropping
> the proposal is "itertools is not as big as you think it is to
> introduce a builtin rich-iterator object".
<>
You should also consider that some people see that as a fal
On 11/14/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> On 11/14/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
> > I don't see the problem of importing important language functionality.
> > Most languages since c have required somthing similar.
>
> Most lan
On 11/14/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> And for those objecting to touching the existing iter() or bloating
> the builtin namespace with yet another builtin, let me mention that we
> can get rid of *two* existing functions which for some reason were
> promoted to builtin status, al
Terry Reedy wrote:
> Because you have to type it over and over.
hmm, With the right context manager:
import py
with py as py:
from gui import tkinker
import net
with net as net:
import httplib
import urllib
-Mike
___
Python
On 5/2/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Looks like we're converging on consensus about this issue. Perhaps
> someone can attempt an implementation in the p3yk (sic) branch? I'll
> add a line to PEP 3100; I don't see that a whole new PEP is necessary
> to summarize the discussion he
On 4/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> You did notice the ;-) in my post on that topic, right? That was meant to
> imply it wasn't a serious proposal.
Sure did . I'd be shocked if non-ascii punctuation was ever
seriously considered. But ascii phi-like things have been propo
On 4/27/06, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
> On Thursday 2006-04-27 11:42, Georg Brandl wrote:
> > Kay Schluehr wrote:
> ...
> > > Furthermore: what about notions of infinite sets?
> >
> > Can you elaborate on that?
>
> Seems to me that if you want infinite sets, you want some type
> o
46 matches
Mail list logo
