I think that I will make a browser in Official Python (not MacPorts
Python).
What should I do in order to install Webkit for Official Python (not
MacPorts Python) ?
from tokyo Japan.
On Sat, May 26, 2012 at 5:14 PM, georg.brandl
<python-checkins(a)python.org> wrote:
> http://hg.python.org/peps/rev/cba34504163d
> changeset: 4441:cba34504163d
> user: Georg Brandl <georg(a)python.org>
> date: Sat May 26 09:15:01 2012 +0200
> summary:
> PEP 421 is implemented.
Did you mean to move 405 instead? 421 is accepted, but not implemented yet.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On Sat, 26 May 2012 04:48:49 +0200
vinay.sajip <python-checkins(a)python.org> wrote:
> +_sys_home = getattr(sys, '_home', None)
> +if _sys_home and os.name == 'nt' and _sys_home.lower().endswith('pcbuild'):
> + _sys_home = os.path.dirname(_sys_home)
What about pcbuild/amd64? Does this work on 64-bit builds?
> +_sys_home = getattr(sys, '_home', None)
> +if _sys_home and os.name == 'nt' and _sys_home.lower().endswith('pcbuild'):
> + _sys_home = os.path.dirname(_sys_home)
Same question here.
> +#!/usr/bin/env python
I don't think there should be a shebang line in a test file.
> +#
> +# Copyright 2011 by Vinay Sajip. All Rights Reserved.
> +#
> +# Permission to use, copy, modify, and distribute this software and its
> +# documentation for any purpose and without fee is hereby granted,
> +# provided that the above copyright notice appear in all copies and that
> +# both that copyright notice and this permission notice appear in
> +# supporting documentation, and that the name of Vinay Sajip
> +# not be used in advertising or publicity pertaining to distribution
> +# of the software without specific, written prior permission.
> +# VINAY SAJIP DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
> +# ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
> +# VINAY SAJIP BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
> +# ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
> +# IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
> +# OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Why the copyright boilerplate?
> +# Use with a Python executable built from the Python fork at
> +#
> +# https://bitbucket.org/vinay.sajip/pythonv/ as follows:
This needs to be updated.
> +# You'll need an Internet connection (needed to download distribute_setup.py).
> +#
> +# The script will change to the environment's binary directory and run
> +#
> +# ./python distribute_setup.py
[...]
> +# This class will not be included in Python core; it's here for now to
Well... either the comment should be fixed or the class removed.
> + # XXX This option will be removed.
> + # XXX This will be changed to EnvBuilder
Same here.
> diff --git a/Lib/venv/scripts/nt/pysetup3.exe b/Lib/venv/scripts/nt/pysetup3.exe
> new file mode 100644
> index 0000000000000000000000000000000000000000..3f3c09ebc8e55f4ac3379041753cb34daef71892
> GIT binary patch
What's this file and how was it compiled?
Regards
Antoine.
As the latest round of updates that Carl and Vinay pushed to the PEPs
repo have addressed my few remaining questions, I am accepting PEP 405
for inclusion in Python 3.3.
Thanks to all involved in working out the spec for what to model
directly on virtualenv, and areas where cleaner solutions could be
found given the power to tweak the behaviour of the core interpreter
and the standard library.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I'd like to make a slight doc change for weakref to state (more or less):
weakrefs are not invalidated when the strong refs
are gone, but rather when garbage collection
reclaims the object
Should this be accurate for all implementations, or should it be more
along the lines of:
weakrefs may be invalidated as soon as the strong refs
are gone, but may last until garbage collection reclaims
the object
~Ethan~
I've mentioned this in private to a few folks, with generally positive
feedback.
I am formally volunteering to be PEP czar for PEP 421, sys.implementation. If
there are no objections in the next few days, I'll make it official.
Cheers,
-Barry
As some have probably noticed: I updated the Rietveld version that we use to
the current code base. There have been a few incompatible changes (schema, GAE
API) which I hope I resolved. If you find new problems, please report them
to the meta tracker.
Regards,
Martin
Hello all. I seem to be encountering somewhat rare an infinite loop
in hash table probing while importing _socket, as triggered by
init_socket.c in Python 2.6, as seen/patched shipped with Ubuntu 10.04
LTS. The problem only reproduces on 32 bit machines, on both -O2 and
-O0 builds (which is how I have managed to retrieve the detailed stack
traces below). To cut to the chase, the bottom of the stack trace
invariably looks like this, in particular the "key" (and therefore
"hash") value is always the same:
#0 0x08088637 in lookdict_string (mp=0xa042714, key='SO_RCVTIMEO',
hash=612808203) at ../Objects/dictobject.c:421
#1 0x080886cd in insertdict (mp=0xa042714, key='SO_RCVTIMEO', hash=612808203,
value=20) at ../Objects/dictobject.c:450
#2 0x08088cac in PyDict_SetItem (op=<unknown at remote 0x37>, key=
'SO_RCVTIMEO', value=20) at ../Objects/dictobject.c:701
#3 0x0808b8d4 in PyDict_SetItemString (v=
{'AF_INET6': 10, 'SocketType': <type at remote 0x8275e00>,
'getaddrinfo': <built-in function getaddrinfo>,
'TIPC_MEDIUM_IMPORTANCE': 1, 'htonl': <built-in function htonl>,
'AF_UNSPEC': 0, 'TIPC_DEST_DROPPABLE': 129, 'TIPC_ADDR_ID': 3,
'PF_PACKET': 17, 'AF_WANPIPE': 25, 'PACKET_OTHERHOST': 3, 'AF_AX25':
3, 'PACKET_BROADCAST': 1, 'PACKET_FASTROUTE': 6, 'TIPC_NODE_SCOPE': 3,
'inet_pton': <built-in function inet_pton>, 'AF_ATMPVC': 8,
'NETLINK_IP6_FW': 13, 'NETLINK_ROUTE': 0, 'TIPC_PUBLISHED': 1,
'TIPC_WITHDRAWN': 2, 'AF_ECONET': 19, 'AF_LLC': 26, '__name__':
'_socket', 'AF_NETROM': 6, 'SOCK_RDM': 4, 'AF_IRDA': 23, 'htons':
<built-in function htons>, 'SOCK_RAW': 3, 'inet_ntoa': <built-in
function inet_ntoa>, 'AF_NETBEUI': 13, 'AF_NETLINK': 16,
'TIPC_WAIT_FOREVER': -1, 'AF_UNIX': 1, 'TIPC_SUB_PORTS': 1,
'HCI_TIME_STAMP': 3, 'gethostbyname_ex': <built-in function
gethostbyname_ex>, 'SO_RCVBUF': 8, 'AF_APPLETALK': 5,
'SOCK_SEQPACKET': 5, 'AF_DECnet': 12, 'PACKET_OUTGOING': 4,
'SO_SNDLOWAT': 19, 'TIPC_SRC_DROPPABLE':...(truncated), key=0x81ac5fb
"SO_RCVTIMEO", item=20) at ../Objects/dictobject.c:2301
#4 0x080f6c98 in PyModule_AddObject (m=<module at remote 0xb73cac8c>, name=
0x81ac5fb "SO_RCVTIMEO", o=20) at ../Python/modsupport.c:615
#5 0x080f6d0b in PyModule_AddIntConstant (m=<module at remote 0xb73cac8c>,
name=0x81ac5fb "SO_RCVTIMEO", value=20) at ../Python/modsupport.c:627
#6 0x081321fd in init_socket () at ../Modules/socketmodule.c:4708
Here, we never escape from lookdict_string. The key is not in the
dictionary, but at this stage Python is trying to figure out that is
the case, and cannot seem to exit because of the lack of a dummy
entry. Furthermore, every single reproduced case has a dictionary
with a suspicious looking violation of an invariant that I believe is
communicated by the source of dictobject.c, with emphasis on the
values of ma_fill, ma_used, and ma_mask, which never deviate in any
reproduced case. It seems like no hash table should ever get this
full, per the comments in the source:
$3 = {ob_refcnt = 1, ob_type = 0x81c3aa0, ma_fill = 128, ma_used = 128,
ma_mask = 127, ma_table = 0xa06b4a8, ma_lookup =
0x8088564 <lookdict_string>, ma_smalltable = {{me_hash = 0, me_key = 0x0,
me_value = 0x0}, {me_hash = 1023053529, me_key = '__name__', me_value =
'_socket'}, {me_hash = 1679430097, me_key = 'gethostbyname', me_value =
<built-in function gethostbyname>}, {me_hash = 0, me_key = 0x0, me_value =
0x0}, {me_hash = 779452068, me_key = 'gethostbyname_ex', me_value =
<built-in function gethostbyname_ex>}, {me_hash = -322108099, me_key =
'__doc__', me_value = None}, {me_hash = -1649837379, me_key =
'gethostbyaddr', me_value = <built-in function gethostbyaddr>}, {
me_hash = 1811348911, me_key = '__package__', me_value = None}}}
The Python program that is running afoul this bug is using gevent, but
the stack traces suggest that all gevent is doing at the time this
crashes is importing "socket", and this is done at the very, very
beginning of program execution.
Finally, what's especially strange is that I had gone a very long time
running this exact version of Python, libraries, and application quite
frequently: it suddenly started cropping up a little while ago (maybe
a few weeks). It could have been just coincidence, but if there are
code paths in init_socket.c that may somehow be sensitive to the
network somehow, this could have been related. I also have a limited
suspicion that particularly unlucky OOM (these systems are configured
in a way where malloc and friends will return NULL, i.e. no overcommit
on Linux) could be related.
Any guiding words, known bugs, or suspicions?
--
fdr