On Tue, Dec 12, 2000 at 05:02:49PM -0800, Tim Peters wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv31776/python/dist/src/objects
>
> Modified Files:
> dictobject.c
> Log Message:
> Bring comments up to date (e.g., they still said the table had to be
> a prime size, which is in fact never true anymore ...).
>...
> --- 55,78 ----
>
> /*
> ! There are three kinds of slots in the table:
> !
> ! 1. Unused. me_key == me_value == NULL
> ! Does not hold an active (key, value) pair now and never did. Unused can
> ! transition to Active upon key insertion. This is the only case in which
> ! me_key is NULL, and is each slot's initial state.
> !
> ! 2. Active. me_key != NULL and me_key != dummy and me_value != NULL
> ! Holds an active (key, value) pair. Active can transition to Dummy upon
> ! key deletion. This is the only case in which me_value != NULL.
> !
> ! 3. Dummy. me_key == dummy && me_value == NULL
> ! Previously held an active (key, value) pair, but that was deleted and an
> ! active pair has not yet overwritten the slot. Dummy can transition to
> ! Active upon key insertion. Dummy slots cannot be made Unused again
> ! (cannot have me_key set to NULL), else the probe sequence in case of
> ! collision would have no way to know they were once active.
4. The popitem finger.
:-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
FYI, looks like SourceForge is scheduled to be unusable in a span covering
late Friday thru early Saturday (OTT -- One True Time, defined by the clocks
in Guido's house).
-----Original Message-----
From: python-dev-admin(a)python.org [mailto:python-dev-admin@python.org]On
Behalf Of Guido van Rossum
Sent: Tuesday, December 12, 2000 3:46 PM
To: python-dev(a)python.org
Subject: [Python-Dev] SourceForge: PROJECT DOWNTIME NOTICE
------- Forwarded Message
Date: Tue, 12 Dec 2000 12:38:20 -0800
From: noreply(a)sourceforge.net
To: noreply(a)sourceforge.net
Subject: SourceForge: PROJECT DOWNTIME NOTICE
ATTENTION SOURCEFORGE PROJECT ADMINISTRATORS
This update is being sent to project administrators only and contains
important information regarding your project. Please read it in its
entirety.
INFRASTRUCTURE UPGRADE, EXPANSION AND RELOCATION
As noted in the sitewide email sent this week, the SourceForge.net
infrastructure is being upgraded (and relocated). As part of this
projects, plans are underway to further increase capacity and
responsiveness.
We are scheduling the relocation of the systems serving project
subdomain web pages.
IMPORTANT:
This move will affect you in the following ways:
1. Service and availability of SourceForge.net and the development
tools provided will continue uninterupted.
2. Project page webservers hosting subdomains
(yourprojectname.sourceforge.net) will be down Friday December 15 from
9PM PST (12AM EST) until 3AM PST.
3. CVS will be unavailable (read only part of the time) from 7PM
until 3AM PST
4. Mailing lists and mail aliases will be unavailable until 3AM PST
---------------------
This email was sent from sourceforge.net. To change your email receipt
preferences, please visit the site and edit your account via the
"Account Maintenance" link.
Direct any questions to admin(a)sourceforge.net, or reply to this email.
------- End of Forwarded Message
_______________________________________________
Python-Dev mailing list
Python-Dev(a)python.org
http://www.python.org/mailman/listinfo/python-dev
On Mon, 11 Dec 2000 15:22:55 -0500, "Tim Peters" <tim.one(a)home.com> wrote:
> Well, anyone can play. When keys collide, what we need is a function f(i)
> such that repeating
> i = f(i)
> visits every int in (0, 2**N) exactly once before setting i back to its
> initial value, for a fixed N and where the first i is in (0, 2**N).
OK, maybe this is me being *real* stupid, but why? Why not [0, 2**n)?
Did 0 harm you in your childhood, and you're trying to get back? <0 wink>.
If we had an affine operation, instead of a linear one, we could have
[0, 2**n). I won't repeat the proof here but changing
> def f(i):
> i <<= 1
i^=1 # This is the line I added
> if i >= 2**N:
> i ^= MAGIC_CONSTANT_DEPENDING_ON_N
> return i
Makes you waltz all over [0, 2**n) if the original made you comple
(0, 2**n).
if-i'm-wrong-then-someone-should-shoot-me-to-save-me-the-embarrasment-ly y'rs,
Z.
--
Moshe Zadka <sig(a)zadka.site.co.il>
This is a signature anti-virus.
Please stop the spread of signature viruses!
------- Forwarded Message
Date: Tue, 12 Dec 2000 12:38:20 -0800
From: noreply(a)sourceforge.net
To: noreply(a)sourceforge.net
Subject: SourceForge: PROJECT DOWNTIME NOTICE
ATTENTION SOURCEFORGE PROJECT ADMINISTRATORS
This update is being sent to project administrators only and contains
important information regarding your project. Please read it in its
entirety.
INFRASTRUCTURE UPGRADE, EXPANSION AND RELOCATION
As noted in the sitewide email sent this week, the SourceForge.net
infrastructure is being upgraded (and relocated). As part of this
projects, plans are underway to further increase capacity and
responsiveness.
We are scheduling the relocation of the systems serving project
subdomain web pages.
IMPORTANT:
This move will affect you in the following ways:
1. Service and availability of SourceForge.net and the development
tools provided will continue uninterupted.
2. Project page webservers hosting subdomains
(yourprojectname.sourceforge.net) will be down Friday December 15 from
9PM PST (12AM EST) until 3AM PST.
3. CVS will be unavailable (read only part of the time) from 7PM
until 3AM PST
4. Mailing lists and mail aliases will be unavailable until 3AM PST
- ---------------------
This email was sent from sourceforge.net. To change your email receipt
preferences, please visit the site and edit your account via the
"Account Maintenance" link.
Direct any questions to admin(a)sourceforge.net, or reply to this email.
------- End of Forwarded Message
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.
The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup
behaviour.
I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs.
I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.
The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.
Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
source code
* you no longer need to drop new codecs into the Python
standard lib
Perhaps someone could add a note about this possibility
to the codec docs ?!
If noone objects, I'll apply the patch for the enhanced alias
support later today.
Thanks,
--
Marc-Andre Lemburg
______________________________________________________________________
Company: http://www.egenix.com/
Consulting: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
I'm asking for a review of the patch to gdbm at
http://sourceforge.net/patch/?func=detailpatch&patch_id=102638&group_id=5470
I asked the author for clarification and this is what I got.
Can anybody suggest what to do? His mail doesn't give me much
confidence in the patch. :-(
--Guido van Rossum (home page: http://www.python.org/~guido/)
------- Forwarded Message
Date: Tue, 12 Dec 2000 13:24:13 +0100
From: Damjan <arhiv(a)freemail.org.mk>
To: Guido van Rossum <guido(a)python.org>
Subject: Re: your gdbm patch for Python
On Mon, Dec 11, 2000 at 03:51:03PM -0500, Guido van Rossum wrote:
> I'm looking at your patch at SourceForge:
First, I'm sorry it was such a mess of a patch, but I could't figure it out how
to send a more elaborate comment. (But then again, I would't have an email from
Guido van Rossum in my mail-box, to show of my friends :)
> and wondering two things:
>
> (1) what does the patch do?
>
> (2) why does the patch remove the 'f' / GDBM_FAST option?
From the gdbm info page:
...The following may also be
logically or'd into the database flags: GDBM_SYNC, which causes
all database operations to be synchronized to the disk, and
GDBM_NOLOCK, which prevents the library from performing any
locking on the database file. The option GDBM_FAST is now
obsolete, since `gdbm' defaults to no-sync mode...
^^^^^^^^
(1) My patch adds two options to the gdbm.open(..) function. These are 'u' for
GDBM_NOLOCK, and 's' for GDBM_SYNC.
(2) GDBM_FAST is obsolete because gdbm defaults to GDBM_FAST, so it's removed.
I'm also thinking about adding a lock and unlock methods to the gdbm object,
but it seems that a gdbm database can only be locked and not unlocked.
- --
Damjan Georgievski | Дамјан Георгиевски
Skopje, Macedonia | Скопје, Македонија
------- End of Forwarded Message
While we're talking about pluggable CLIs, I share this fellow's confusion
over IDLE's CLI variant: block code doesn't "look right" under IDLE because
sys.ps2 doesn't exist under IDLE. Some days you can't make *anybody* happy
<wink>.
-----Original Message-----
...
Subject: [Python-Help] indentation
Sent: Sunday, December 10, 2000 7:32 AM
...
My Problem has to do with identation:
I put the following to idle:
>>> if not 1:
print 'Hallo'
else:
SyntaxError: invalid syntax
I get the Message above.
I know that else must be 4 spaces to the left, but idle doesn't let me do
this.
I have only the alternative to put to most left point. But than I
disturb the block structure and I get again the error message.
I want to have it like this:
>>> if not 1:
print 'Hallo'
else:
Can you help me?
...
Moshe proposes to add an overridable function sys.displayhook(obj)
which will be called by the interpreter for the PRINT_EXPR opcode,
instead of hardcoding the behavior. The default implementation will
of course have the current behavior, but this makes it much simpler to
experiment with alternatives, e.g. using str() instead of repr() (or
to choose between str() and repr() based on the type).
Moshe has asked me to pronounce on this PEP. I've thought about it,
and I'm now all for it. Moshe (or anyone else), please submit a patch
to SF that shows the complete implementation!
--Guido van Rossum (home page: http://www.python.org/~guido/)
Hi, folks. Jon Erickson (Doctor Dobb's Journal), Frank Willison (O'Reilly),
and I (professional loose cannon) are doing a workshop at IPC on writing
books
and magazine articles about Python. It would be great to have a few
articles
(in various stages of their lives) and/or book proposals from people on this
list to use as examples. So, if you think the world oughta know about the
things you're doing, and would like to use this to help get yourself
motivated
to start writing, please drop me a line. I'm particularly interested in:
- the real-world issues involved in moving to Unicode
- non-trivial XML processing using SAX and DOM (where "non-trivial" means
"including namespaces, entity references, error handling, and all that")
- the theory and practice of stackless, generators, and continuations
- the real-world tradeoffs between the various memory management schemes
that are now available for Python
- feature comparisons of various Foobars that can be used with Python (where
"Foobar" could be "GUI toolkit", "IDE", "web scripting toolkit", or just
about anything else)
- performance analysis and tuning of Python itself (as an example of how you
speed up real applications --- this is something that matters a lot in the
real world, but tends to get forgotten in school)
- just about anything else that you wish someone had written for you before
you started your last big project
Thanks,
Greg
