RE: Populating a dictionary, fast [SOLVED SOLVED]

Discussion in 'Python' started by Michael Bacarella, Nov 12, 2007.

  1. > > You can download the list of keys from here, it's 43M gzipped:
    > > http://www.sendspace.com/file/9530i7
    > >
    > > and see it take about 45 minutes with this:
    > >
    > > $ cat cache-keys.py
    > > #!/usr/bin/python
    > > v = {}
    > > for line in open('keys.txt'):
    > > v[long(line.strip())] = True
    > >
    > >

    > It takes about 20 seconds for me. It's possible it's related to
    > int/long
    > unification - try using Python 2.5. If you can't switch to 2.5, try
    > using string keys instead of longs.


    Yes, this was it. It ran *very* fast on Python v2.5.

    Terribly on v2.4, v2.3.

    (I thought I had already evaluated v2.5 but I see now that the server
    With 2.5 on it invokes 2.3 for 'python'.)

    Thanks!
     
    Michael Bacarella, Nov 12, 2007
    #1
    1. Advertising

  2. On Nov 12, 12:46 pm, "Michael Bacarella" <> wrote:
    >
    > > It takes about 20 seconds for me. It's possible it's related to
    > > int/long
    > > unification - try using Python 2.5. If you can't switch to 2.5, try
    > > using string keys instead of longs.

    >
    > Yes, this was it. It ran *very* fast on Python v2.5.


    Um. Is this the take away from this thread? Longs as dictionary
    keys are bad? Only for older versions of Python?

    This could be a problem for people like me who build
    lots of structures using seek values, which are longs, as done in
    http://nucular.sourceforge.net and http://bplusdotnet.sourceforge.net
    and elsewhere. Someone please summarize.

    -- Aaron Watters
    ===
    http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=white trash
     
    Aaron Watters, Nov 14, 2007
    #2
    1. Advertising

  3. Aaron Watters <> writes:

    > On Nov 12, 12:46 pm, "Michael Bacarella" <> wrote:
    >>
    >> > It takes about 20 seconds for me. It's possible it's related to
    >> > int/long
    >> > unification - try using Python 2.5. If you can't switch to 2.5, try
    >> > using string keys instead of longs.

    >>
    >> Yes, this was it. It ran *very* fast on Python v2.5.

    >
    > Um. Is this the take away from this thread? Longs as dictionary
    > keys are bad? Only for older versions of Python?


    It sounds like Python 2.4 (and previous versions) had a bug when
    populating large dicts on 64-bit architectures.

    > Someone please summarize.


    Yes, that would be good.
     
    Hrvoje Niksic, Nov 14, 2007
    #3
  4. On Wed, 14 Nov 2007 18:16:25 +0100, Hrvoje Niksic wrote:

    > Aaron Watters <> writes:
    >
    >> On Nov 12, 12:46 pm, "Michael Bacarella" <> wrote:
    >>>
    >>> > It takes about 20 seconds for me. It's possible it's related to
    >>> > int/long
    >>> > unification - try using Python 2.5. If you can't switch to 2.5, try
    >>> > using string keys instead of longs.
    >>>
    >>> Yes, this was it. It ran *very* fast on Python v2.5.

    >>
    >> Um. Is this the take away from this thread? Longs as dictionary keys
    >> are bad? Only for older versions of Python?

    >
    > It sounds like Python 2.4 (and previous versions) had a bug when
    > populating large dicts on 64-bit architectures.


    No, I found very similar behaviour with Python 2.5.


    >> Someone please summarize.

    >
    > Yes, that would be good.



    On systems with multiple CPUs or 64-bit systems, or both, creating and/or
    deleting a multi-megabyte dictionary in recent versions of Python (2.3,
    2.4, 2.5 at least) takes a LONG time, of the order of 30+ minutes,
    compared to seconds if the system only has a single CPU. Turning garbage
    collection off doesn't help.


    --
    Steven.
     
    Steven D'Aprano, Nov 14, 2007
    #4
  5. On Nov 14, 6:26 pm, Steven D'Aprano <st...@REMOVE-THIS-
    cybersource.com.au> wrote:
    > >> Someone please summarize.

    >
    > > Yes, that would be good.

    >
    > On systems with multiple CPUs or 64-bit systems, or both, creating and/or
    > deleting a multi-megabyte dictionary in recent versions of Python (2.3,
    > 2.4, 2.5 at least) takes a LONG time, of the order of 30+ minutes,
    > compared to seconds if the system only has a single CPU. Turning garbage
    > collection off doesn't help.
    >
    > --
    > Steven.


    criminy... Any root cause? patch?

    btw, I think I've seen this, but I think you need
    to get into 10s of megs or more before it becomes
    critical.

    Note: I know someone will say "don't scare off the newbies"
    but in my experience most Python programmers are highly
    experienced professionals who need to know this sort of thing.
    The bulk of the newbies are either off in VB land
    or struggling with java.

    -- Aaron Watters

    ===
    http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=silly walk
     
    Aaron Watters, Nov 15, 2007
    #5
  6. On Nov 14, 6:26 pm, Steven D'Aprano <st...@REMOVE-THIS-
    cybersource.com.au> wrote:

    > On systems with multiple CPUs or 64-bit systems, or both, creating and/or
    > deleting a multi-megabyte dictionary in recent versions of Python (2.3,
    > 2.4, 2.5 at least) takes a LONG time, of the order of 30+ minutes,
    > compared to seconds if the system only has a single CPU. Turning garbage
    > collection off doesn't help.


    Fwiw, Testing on a 2 cpu 64 bit machine with 1gb real memory I
    consistently
    run out of real memory before I see this effect, so I guess it kicks
    in for dicts
    that consume beyond that. That's better than I feared at any
    rate...

    -- Aaron Watters

    ===
    http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=especially nasty windows
     
    Aaron Watters, Nov 15, 2007
    #6
  7. Michael Bacarella

    Chris Mellon Guest

    On Nov 14, 2007 5:26 PM, Steven D'Aprano
    <> wrote:
    > On Wed, 14 Nov 2007 18:16:25 +0100, Hrvoje Niksic wrote:
    >
    > > Aaron Watters <> writes:
    > >
    > >> On Nov 12, 12:46 pm, "Michael Bacarella" <> wrote:
    > >>>
    > >>> > It takes about 20 seconds for me. It's possible it's related to
    > >>> > int/long
    > >>> > unification - try using Python 2.5. If you can't switch to 2.5, try
    > >>> > using string keys instead of longs.
    > >>>
    > >>> Yes, this was it. It ran *very* fast on Python v2.5.
    > >>
    > >> Um. Is this the take away from this thread? Longs as dictionary keys
    > >> are bad? Only for older versions of Python?

    > >
    > > It sounds like Python 2.4 (and previous versions) had a bug when
    > > populating large dicts on 64-bit architectures.

    >
    > No, I found very similar behaviour with Python 2.5.
    >
    >
    > >> Someone please summarize.

    > >
    > > Yes, that would be good.

    >
    >
    > On systems with multiple CPUs or 64-bit systems, or both, creating and/or
    > deleting a multi-megabyte dictionary in recent versions of Python (2.3,
    > 2.4, 2.5 at least) takes a LONG time, of the order of 30+ minutes,
    > compared to seconds if the system only has a single CPU. Turning garbage
    > collection off doesn't help.
    >
    >


    I can't duplicate this in a dual CPU (64 bit, but running in 32 bit
    mode with a 32 bit OS) system. I added keys to a dict until I ran out
    of memory (a bit over 22 million keys) and deleting the dict took
    about 8 seconds (with a stopwatch, so not very precise, but obviously
    less than 30 minutes).

    >>> d = {}
    >>> idx = 0
    >>> while idx < 1e10:

    .... d[idx] = idx
    .... idx += 1
    ....
    Traceback (most recent call last):
    File "<stdin>", line 2, in <module>
    MemoryError
    >>> len(d)

    22369622
    >>> del d
     
    Chris Mellon, Nov 15, 2007
    #7
  8. On Nov 14, 6:26 pm, Steven D'Aprano <st...@REMOVE-THIS-
    cybersource.com.au> wrote:

    > On systems with multiple CPUs or 64-bit systems, or both, creating and/or
    > deleting a multi-megabyte dictionary in recent versions of Python (2.3,
    > 2.4, 2.5 at least) takes a LONG time, of the order of 30+ minutes,
    > compared to seconds if the system only has a single CPU.


    Please don't propagate this nonsense. If you see this then the problem
    exists between the chair and monitor.

    There is nothing wrong with neither creating nor deleting
    dictionaries.

    i.
     
    Istvan Albert, Nov 15, 2007
    #8
  9. On Nov 15, 2:11 pm, Istvan Albert <> wrote:
    > There is nothing wrong with neither creating nor deleting
    > dictionaries.


    I suspect what happened is this: on 64 bit
    machines the data structures for creating dictionaries
    are larger (because pointers take twice as much space),
    so you run into memory contention issues sooner than
    on 32 bit machines, for similar memory sizes.
    If there is something deeper going
    on please correct me, I would very much like to know.

    -- Aaron Watters

    ===
    http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=alien friend
     
    Aaron Watters, Nov 15, 2007
    #9
  10. Steven D'Aprano <> writes:

    >>> Someone please summarize.

    >>
    >> Yes, that would be good.

    >
    > On systems with multiple CPUs or 64-bit systems, or both, creating and/or
    > deleting a multi-megabyte dictionary in recent versions of Python (2.3,
    > 2.4, 2.5 at least) takes a LONG time, of the order of 30+ minutes,
    > compared to seconds if the system only has a single CPU.


    Can you post minimal code that exhibits this behavior on Python 2.5.1?
    The OP posted a lot of different versions, most of which worked just
    fine for most people.
     
    Hrvoje Niksic, Nov 15, 2007
    #10
  11. > On Nov 15, 2:11 pm, Istvan Albert <> wrote:
    > > There is nothing wrong with neither creating nor deleting
    > > dictionaries.

    >
    > I suspect what happened is this: on 64 bit
    > machines the data structures for creating dictionaries
    > are larger (because pointers take twice as much space),
    > so you run into memory contention issues sooner than
    > on 32 bit machines, for similar memory sizes.
    > If there is something deeper going
    > on please correct me, I would very much like to know.


    Since some people missed the EUREKA!, here's the executive summary:

    Python2.3: about 45 minutes
    Python2.4: about 45 minutes
    Python2.5: about _30 seconds_

    The cut/paste of the EUREKA MOMENT from earlier in this thread:

    > > You can download the list of keys from here, it's 43M gzipped:
    > > http://www.sendspace.com/file/9530i7
    > >
    > > and see it take about 45 minutes with this:
    > >
    > > $ cat cache-keys.py
    > > #!/usr/bin/python
    > > v = {}
    > > for line in open('keys.txt'):
    > > v[long(line.strip())] = True
    > >
    > >
    > It takes about 20 seconds for me. It's possible it's related to
    > int/long
    > unification - try using Python 2.5. If you can't switch to 2.5,
    try
    > using string keys instead of longs.

    Yes, this was it. It ran *very* fast on Python v2.5.

    Terribly on v2.4, v2.3.

    (I thought I had already evaluated v2.5 but I see now that the
    server
    With 2.5 on it invokes 2.3 for 'python'.)

    Thanks!
     
    Michael Bacarella, Nov 15, 2007
    #11
  12. On Thu, 15 Nov 2007 10:51:08 -0600, Chris Mellon wrote:

    > I can't duplicate this in a dual CPU (64 bit, but running in 32 bit mode
    > with a 32 bit OS) system.


    Can you try it running in 64-bit mode?

    What Python version are you running?

    --
    Steven.
     
    Steven D'Aprano, Nov 15, 2007
    #12
  13. On Thu, 15 Nov 2007 11:11:57 -0800, Istvan Albert wrote:

    > On Nov 14, 6:26 pm, Steven D'Aprano <st...@REMOVE-THIS-
    > cybersource.com.au> wrote:
    >
    >> On systems with multiple CPUs or 64-bit systems, or both, creating
    >> and/or deleting a multi-megabyte dictionary in recent versions of
    >> Python (2.3, 2.4, 2.5 at least) takes a LONG time, of the order of 30+
    >> minutes, compared to seconds if the system only has a single CPU.

    >
    > Please don't propagate this nonsense. If you see this then the problem
    > exists between the chair and monitor.
    >
    > There is nothing wrong with neither creating nor deleting dictionaries.


    Please read the whole thread before making unsupported statements like
    that. You should consider that this behaviour has been observed by
    multiple people, before making insulting statements.

    Both myself and the original poster have given code that demonstrates
    this problem. We've given concrete evidence of a problem which is
    replicable across different versions of Python and different versions of
    the Linux operating system.

    Unless you're accusing both myself and the original poster of outright
    lying, of faking our results, what's your explanation? Have you tried
    running our code on a 64-bit or multi-CPU system to see for yourself, or
    are you just being closed-minded and arrogant?


    --
    Steven.
     
    Steven D'Aprano, Nov 15, 2007
    #13
  14. Michael Bacarella

    Chris Mellon Guest

    On Nov 15, 2007 2:57 PM, Steven D'Aprano
    <> wrote:
    > On Thu, 15 Nov 2007 10:51:08 -0600, Chris Mellon wrote:
    >
    > > I can't duplicate this in a dual CPU (64 bit, but running in 32 bit mode
    > > with a 32 bit OS) system.

    >
    > Can you try it running in 64-bit mode?
    >
    > What Python version are you running?
    >


    C:\>python
    Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
    win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>>


    I can't switch to 64 bit right now. This is a dual Core 2 Duo machine
    (2 CPUs, 2 cores each).

    I've looked at the deallocation code for dict objects and I can't see
    anything that should be affected by 64 bitness, at least not nearly
    the degree described - it DECREFs all the keys and values in the dict,
    calls PyMem_Free on its memory pool (if it was large enough to be
    malloced, which this certainly was, and either adds itself back to the
    dict object pool or deallocs itself (if its a subclass of dict).
     
    Chris Mellon, Nov 15, 2007
    #14
  15. On Thu, 15 Nov 2007 15:51:25 -0500, Michael Bacarella wrote:

    > Since some people missed the EUREKA!, here's the executive summary:
    >
    > Python2.3: about 45 minutes
    > Python2.4: about 45 minutes
    > Python2.5: about _30 seconds_


    I'm really happy that upgrading to 2.5 solved the issue for you, but I
    get similar behaviour and I'm running 2.5, so it isn't as simple as that.



    --
    Steven.
     
    Steven D'Aprano, Nov 15, 2007
    #15
  16. > On Thu, 15 Nov 2007 15:51:25 -0500, Michael Bacarella wrote:
    >
    > > Since some people missed the EUREKA!, here's the executive summary:
    > >
    > > Python2.3: about 45 minutes
    > > Python2.4: about 45 minutes
    > > Python2.5: about _30 seconds_

    >
    > I'm really happy that upgrading to 2.5 solved the issue for you, but I
    > get similar behaviour and I'm running 2.5, so it isn't as simple as
    > that.


    Maybe some more details about my environment will help.

    Our fast Python is 2.5, built from source. Our slow Python is 2.3,
    default installed with the OS, from rpm.

    # python
    Python 2.5.1 (r251:54863, May 11 2007, 14:17:21)
    [GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.

    # which python
    /usr/local/bin/python

    # ls -la /usr/local/bin/python
    -rwxr-xr-x 2 root root 5312572 Nov 12 12:54 /usr/local/bin/python

    # md5sum /usr/local/bin/python
    5c24e54a6cf5a556e9371325d18bc1fb /usr/local/bin/python

    # ls -la /usr/bin/python*
    lrwxrwxrwx 1 root root 9 Nov 12 12:57 /usr/bin/python -> python2
    lrwxrwxrwx 1 root root 6 Nov 12 12:57 /usr/bin/python2 -> python2.5
    -rwxr-xr-x 1 root root 8344 May 2 2007 /usr/bin/python2.3
    lrwxrwxrwx 1 root root 21 Nov 12 12:57 /usr/bin/python2.5 ->
    /usr/local/bin/python

    # ls -la /usr/local/src/ | grep Python
    drwxr-xr-x 19 1000 1000 4096 Nov 12 12:54 Python-2.5.1
    -rw-r--r-- 1 root root 9383651 Nov 12 12:51 Python-2.5.1.tar.bz2

    # gcc -v
    Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/specs
    Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
    --infodir=/usr/share/info --enable-shared --enable-threads=posix
    --disable-checking --with-system-zlib --enable-__cxa_atexit
    --disable-libunwind-exceptions --enable-java-awt=gtk
    --host=x86_64-redhat-linux
    Thread model: posix
    gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

    # cat /etc/redhat-release
    CentOS release 4.2 (Final)

    # uname -a
    Linux xxx 2.6.9-22.ELsmp #1 SMP Sat Oct 8 21:32:36 BST 2005 x86_64 x86_64
    x86_64 GNU/Linux

    # free
    total used free shared buffers cached
    Mem: 7390244 6961440 428804 0 15520 2549732
    -/+ buffers/cache: 4396188 2994056
    Swap: 2096472 10280 2086192

    # cat /proc/cpuinfo
    processor : 0
    vendor_id : AuthenticAMD
    cpu family : 15
    model : 5
    model name : AMD Opteron(tm) Processor 246
    stepping : 10
    cpu MHz : 2009.305
    cache size : 1024 KB
    fpu : yes
    fpu_exception : yes
    cpuid level : 1
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
    cmov
    pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
    bogomips : 3981.31
    TLB size : 1088 4K pages
    clflush size : 64
    cache_alignment : 64
    address sizes : 40 bits physical, 48 bits virtual
    power management: ts fid vid ttp

    processor : 1
    vendor_id : AuthenticAMD
    cpu family : 15
    model : 5
    model name : AMD Opteron(tm) Processor 246
    stepping : 10
    cpu MHz : 2009.305
    cache size : 1024 KB
    fpu : yes
    fpu_exception : yes
    cpuid level : 1
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
    cmov
    pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
    bogomips : 4014.08
    TLB size : 1088 4K pages
    clflush size : 64
    cache_alignment : 64
    address sizes : 40 bits physical, 48 bits virtual
    power management: ts fid vid ttp


    ***** information about Python 2.3 *****

    # rpm -qi python
    Name : python Relocations: (not relocatable)
    Version : 2.3.4 Vendor: CentOS
    Release : 14.4 Build Date: Wed 02 May 2007
    07:20:29 PM EDT
    Install Date: Mon 04 Jun 2007 05:48:29 PM EDT Build Host: builder6
    Group : Development/Languages Source RPM:
    python-2.3.4-14.4.src.rpm
    Size : 21137194 License: PSF - see LICENSE
    Signature : DSA/SHA1, Sat 05 May 2007 09:33:49 AM EDT, Key ID
    a53d0bab443e1821
    URL : http://www.python.org/
    Summary : An interpreted, interactive, object-oriented programming
    language.
    Description :
    Python is an interpreted, interactive, object-oriented programming
    language often compared to Tcl, Perl, Scheme or Java. Python includes
    modules, classes, exceptions, very high level dynamic data types and
    dynamic typing. Python supports interfaces to many system calls and
    libraries, as well as to various windowing systems (X11, Motif, Tk,
    Mac and MFC).

    Programmers can write new built-in modules for Python in C or C++.
    Python can be used as an extension language for applications that need
    a programmable interface. This package contains most of the standard
    Python modules, as well as modules for interfacing to the Tix widget
    set for Tk and RPM.

    Note that documentation for Python is provided in the python-docs
    package.
     
    Michael Bacarella, Nov 15, 2007
    #16
  17. On Thu, 15 Nov 2007 21:51:21 +0100, Hrvoje Niksic wrote:

    > Steven D'Aprano <> writes:
    >
    >>>> Someone please summarize.
    >>>
    >>> Yes, that would be good.

    >>
    >> On systems with multiple CPUs or 64-bit systems, or both, creating
    >> and/or deleting a multi-megabyte dictionary in recent versions of
    >> Python (2.3, 2.4, 2.5 at least) takes a LONG time, of the order of 30+
    >> minutes, compared to seconds if the system only has a single CPU.

    >
    > Can you post minimal code that exhibits this behavior on Python 2.5.1?
    > The OP posted a lot of different versions, most of which worked just
    > fine for most people.


    Who were testing it on single-CPU, 32 bit systems.

    The plot thickens... I wrote another version of my test code, reading the
    data into a list of tuples rather than a dict:

    $ python slurp_dict4.py # actually slurp a list, despite the name
    Starting at Fri Nov 16 08:55:26 2007
    Line 0
    Line 1000000
    Line 2000000
    Line 3000000
    Line 4000000
    Line 5000000
    Line 6000000
    Line 7000000
    Line 8000000
    Items in list: 8191180
    Completed import at Fri Nov 16 08:56:26 2007
    Starting to delete list...
    Completed deletion at Fri Nov 16 08:57:04 2007
    Finishing at Fri Nov 16 08:57:04 2007

    Quite a reasonable speed, considering my limited memory.

    What do we know so far?

    (1) The problem occurs whether or not gc is enabled.

    (2) It only occurs on some architectures. 64 bit CPU seems to be common
    factor.

    (3) I don't think we've seen it demonstrated under Windows, but we've
    seen it under at least two different Linux distros.

    (4) It affects very large dicts, but not very large lists.

    (5) I've done tests where instead of one really big dict, the data is put
    into lots of smaller dicts. The problem still occurs.

    (6) It was suggested the problem is related to long/int unification, but
    I've done tests that kept the dict keys as strings, and the problem still
    occurs.

    (7) It occurs in Python 2.3, 2.4 and 2.5, but not 2.5.1.

    Do we treat this as a solved problem and move on?



    --
    Steven.
     
    Steven D'Aprano, Nov 15, 2007
    #17
  18. Michael Bacarella

    Paul Rubin Guest

    Steven D'Aprano <> writes:
    > (7) It occurs in Python 2.3, 2.4 and 2.5, but not 2.5.1.
    > Do we treat this as a solved problem and move on?


    I'm not comfortable with this. Better to identify the cause for
    certain. I'll look at it sometime if I get a chance. I have some
    64-bit multi-cpu machines I can try it on.
     
    Paul Rubin, Nov 15, 2007
    #18
  19. Michael Bacarella

    Terry Reedy Guest

    "Steven D'Aprano" <> wrote in message
    news:...
    | (7) It occurs in Python 2.3, 2.4 and 2.5, but not 2.5.1.
    |
    | Do we treat this as a solved problem and move on?

    If the problem was fixed accidentally as an undocumented by product of a
    patch aimed at something else, it might get similarly unfixed without
    triggering a test failure. So if someone pins down the problem source well
    enough to warn future maintainers in a comment or commit note, all the
    better. Otherwise, wait until a reversion happens, if ever.
     
    Terry Reedy, Nov 15, 2007
    #19
  20. On Nov 15, 4:11 pm, Steven D'Aprano <st...@REMOVE-THIS-
    cybersource.com.au> wrote:

    > Unless you're accusing both myself and the original poster of outright
    > lying, of faking our results, what's your explanation?


    I don't attribute it to malice, I think you're simply measuring
    something else. You both must be having some some system setting that
    forces your application to swap disk.

    Do you really believe that you cannot create or delete a large
    dictionary with python versions less than 2.5 (on a 64 bit or multi-
    cpu system)? That a bug of this magnitude has not been noticed until
    someone posted on clp?

    > Have you tried
    > running our code on a 64-bit or multi-CPU system to see for yourself,


    the answer is: yes and yes, I see nothing out of the ordinary.

    i.
     
    Istvan Albert, Nov 16, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Bacarella

    Populating a dictionary, fast

    Michael Bacarella, Nov 10, 2007, in forum: Python
    Replies:
    4
    Views:
    526
    Istvan Albert
    Nov 11, 2007
  2. Michael Bacarella

    Re: Populating a dictionary, fast

    Michael Bacarella, Nov 11, 2007, in forum: Python
    Replies:
    6
    Views:
    543
    Hrvoje Niksic
    Nov 12, 2007
  3. Michael Bacarella

    Re: Populating a dictionary, fast

    Michael Bacarella, Nov 11, 2007, in forum: Python
    Replies:
    3
    Views:
    277
    Ben Finney
    Nov 11, 2007
  4. Michael Bacarella

    Re: Populating a dictionary, fast

    Michael Bacarella, Nov 11, 2007, in forum: Python
    Replies:
    2
    Views:
    466
    Jeffrey Froman
    Nov 12, 2007
  5. Michael Bacarella

    Re: Populating a dictionary, fast

    Michael Bacarella, Nov 11, 2007, in forum: Python
    Replies:
    16
    Views:
    709
    Francesc Altet
    Nov 21, 2007
Loading...

Share This Page