or in FreeBSD?
2.6rc1 and 3.0b3 both fail test_array on FreeBSD7 amd64
test_array passes in 2.5.2 on the same machine but fails test_list the
same as test_array...
*** Signal 9
Not sure if I should file this as a bug or not. I didn't see anything
on bugs.pyhton.org...
~ro
One of the things I like about Python is that
* it doesn't actually need an installation. *
It is sufficient to set up PATH (and, if you like, PYTHONPATH)
accordingly to start python. However, you need the DLLs somewhere
in the Python directory, too.
That way it is possible to install Python applications in a minimal-invasive
fashion: Just copy one directory to the hard-disk (or a network drive) and
create a shortcut to some start-app.cmd script
For example, this is a great advantage if you need to install a Python
application
on a client's application server,
since the client's IT departments in reponsibility for the server
absolutely don't like it when programs modify PATH or install DLLs in the
%WINDIR%\System32 directory - and they are right here!!!
Think of what happens if a program modifies PATH: The modification does not
affect running services, of course. But *after a reboot* (possibly a few
months later),
the old services will find another version of some program than before, and
then
someting is going to crash!
I have seen too much trouble of this kind after the installation of a
different Perl
version or a another Oracle product. The reason is then quite hard to find:
if the
installation of another software was 3 months ago, will anyone remember? And
will anyone even consider it could be the reason for the fault after the
reboot?
Well - I will, but most others probably won't.
I don't want this kind of trouble too happen with Python!
So, please try keeping the Python installation as minimal invasive as
possible.
Note: This could also be an option for the installation.
Henning
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We had a lot of discussion recently about changing the release
schedule and splitting Python 2.6 and 3.0. There was general
consensus that this was a good idea, in order to hit our October 1
deadline for Python 2.6 final at least.
There is only one open blocker for 2.6, issue 3657. Andrew, Fred, Tim
and I (via IRC) will be getting together tonight to do some Python
hacking, so we should resolve this issue and release 2.6rc1 tonight.
We'll have an abbreviated 2.6rc1, and I will release 2.6rc2 next
Wednesday the 17th as planned. The final planned release of 2.6 will
be Wednesday October 1st.
If 3.0 is looking better, I will release 3.0rc1 on Wednesday,
otherwise we'll re-evaluate the release schedule for 3.0 as
necessary. This means currently the schedule looks like this:
Fri 12-Sep 2.6rc1
Wed 17-Sep 2.6rc2, 3.0rc1
Wed 01-Oct 2.6 final, 3.0rc2
Wed 15-Oct 3.0 final
I've updated the Python Release Schedule gcal and will update the PEP
momentarily. We'll close the tree later tonight (UTC-4).
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSMpmfHEjvBPtnXfVAQJUiQP/eTXStyp9M0+Ja7iAFfYcpzfM19j9ddBr
ocMC+KTDSgci5/rmFw4KdMhqO9TBk2sXIdCd9GInnuMOKtndCKZ/PXaexnVvSVGb
P3CpkkMs/vG1itQIc/EXq6CUhzwuxEv9h8Wo8+zcmL05Cc1IrE5d2OYiO0+KQ8ei
lW+j/aNKMWY=
=w2oI
-----END PGP SIGNATURE-----
As far as I can see, the specification of the dbm interface is the
module docstring in dbm/__init__.py, which reads:
"""
[...]
It has the following interface (key and data are strings):
d[key] = data # store data at key (may override data at
# existing key)
data = d[key] # retrieve data at key (raise KeyError if no
# such key)
del d[key] # delete data stored at key (raises KeyError
# if no such key)
flag = key in d # true if the key exists
list = d.keys() # return a list of all existing keys (slow!)
"""
Now I thought that in Python 3.0, keys(), values() and friends should
return iterators. Can we change at least the specification of the dbm
module? We could then later in 3.1 change the implementations to return
iterators instead of lists, too.
I stumbled upon it cos I'm trying to help Skip with the SQLite-based
implementation.
-- Gerhard
SVN checkout over HTTPS protocol requires password. Is it intentional
or just temporary server issue? I am behind a proxy that doesn't
support PROPFIND requests and I can't test SVN+SSH, because 22 port is
closed.
Site docs keep silence about that HTTPS is used at all. Shouldn't
authentication be asked only on write access in normal SVN setup?
BTW, link to "current svn tree" is broken here -
http://www.python.org/dev/patches/
--
--anatoly t.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Trent, are you available to look at the ?spurious? timeout failures in
bsddb replication code in the Windows buildbot?.
Ten seconds timeout should be plenty enough. I can't debug any MS
Windows issue myself; this is a Microsoft-free environment.
- --
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSMFWXJlgi5GaxT1NAQK3BwQAlG532RIfCKRLRwQWYqUnL87F4ITxgu7W
6QgzIHoCvl/oA5G0MsaSJ6Qh3XdutH4RjovxH7Ky3rQ08lFa7iyg6mHuzkBTDbri
Pb7jgWHxQ/FImSD1rxqJHrLpKvRNoR0zjyDUVlEsgLElJ6wKGz4/eclJh0/0Wylv
QdTISCI4rR4=
=HBAA
-----END PGP SIGNATURE-----
I've been trying out the new ssl module, and I love it so far, except for
the way it accepts private keys and certificates. It accept them only as
paths to their location on the file system, which I believe means that a
server can only support SSL if it has read permission to its private key
file when client connections arrive. This is a problem for servers that
bind to their socket and drop privileges as soon as they start up, a
practice that is both common and recommended in the unix world.
IMHO, this severely limits the new ssl module's utility, and discourages
good security practices.
Wouldn't it be better if we could specify keys and certificates as bytes
or file-like objects? This would solve the security issue, give
applications more flexibility in key management, and might also improve
performance slightly (by avoiding file system operations at accept()
time).
Perhaps there's a workaround that I haven't noticed yet? A quick look at
the source code didn't reveal any obvious way to specify keys other than
as paths in the file system.
http://bugs.python.org/issue3823
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm not going to release rc1 tonight. There are too many open release
blockers that I don't want to defer, and I'd like the buildbots to
churn through the bsddb removal on all platforms. Let me first thank
Benjamin, Brett, Mark and Antoine for their help on IRC tonight.
Here are the issues I'm not comfortable with deferring:
3640 test_cpickle crash on AMD64 Windows build
874900 threading module can deadlock after fork
3574 compile() cannot decode Latin-1 source encodings
3657 pickle can pickle the wrong function
3187 os.listdir can return byte strings
3660 reference leaks in 3.0
3594 PyTokenizer_FindEncoding() never succeeds
3629 Py30b3 won't compile a regex that compiles with 2.5.2 and 30b2
In addition, Mark reported in IRC that there are some regressions in
the logging module.
I appreciate any feedback or fixes you can provide on these issues.
You might also want to look at the deferred blockers to see if there's
anything that really should be blocking rc1.
I'd like to try again on Friday and stick to rc2 on the 17th.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSL9Y53EjvBPtnXfVAQJGXwP+JZUa5EWlQh7yzt7aFdEM3qgiFZnKqWhz
TN4Cen0/eK8c4+t8a5WC+OLvc/P3PhMPhLSnE+g6IqQUO+pt+2LANgpAvCUrUahc
Nk2pt3gCclcmWlzVvCBspVPZjFPkHsW0uVhgK6x1C/2Re90yjeBqPGgT4LGlmaR3
bz6A3iiUnk0=
=Y5aN
-----END PGP SIGNATURE-----