Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On 11/4/2013 1:09 AM, Zachary Ware wrote: On Sun, Nov 3, 2013 at 10:54 PM, Terry Reedy wrote: On 11/3/2013 11:48 PM, terry.reedy wrote: http://hg.python.org/cpython/rev/cced7981ec4d changeset: 86908:cced7981ec4d branch: 2.7 user:Terry Jan Reedy date:Sun Nov 03 23:37:54 2013 -0500 summary: Issue #X: Fix test_idle so that idlelib test cases are actually run under test.regrtest on 2.7. This message is the one included with the patch by Ned Daily. Because a message *was* included (not normal), hg import committed the patch immediately, without giving me a chance to edit the patch or message. As far as I know, there is no way I could have edited the message after the commit. If there was, let me know. hg commit has an "--amend" option that allows you to change the last (un-pushed) commit. Even if there aren't actually any changes to be committed, it will pop up a text editor with the commit message of the last commit already filled in, allowing you to change the message. Any time you `hg commit --amend`, it saves the original commit locally as a bundle in the .hg dir, so you can restore it if need be. I haven't tested it, but from a quick look at TortoiseHg Workbench's Commit screen, it looks like --amend can be done from the down arrow on the commit button, "Amend current revision". Thank you. I tried that in a local test repository, changed the message, even added an untracked file, hit Amend, and it worked. Editing a file, hitting refresh, and then Amend also worked. The one thing I tried but could not do was to directly change status 'A' back to '?'. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem installing matplotlib 1.3.1 with Python 2.7.6 and 3.3.3 (release candidate 1)
In article , Georg Brandl wrote: > Am 04.11.2013 01:59, schrieb Ned Deily: > > In article <21110.62791.44734.656...@cochabamba.vanoostrum.org>, > > Piet van Oostrum wrote: > >> I tried to install matplotlib 1.3.1 on the release candidates of Python > >> 2.7.6 > >> and 3.3.3. > > > > [...] > > > > Please open an issue on the Python bug tracker for the Python component of > > this. > > > > http://bugs.python.org > And please mark as release blocker, I think this should go into 3.3.3rc2. http://bugs.python.org/issue19490 -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
Hi! On Mon, Nov 04, 2013 at 03:56:25AM -0500, Terry Reedy wrote: > The one > thing I tried but could not do was to directly change status 'A' > back to '?'. hg forget file Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
Hi, bugs.python.org is still not responding on IPv6. Can someone please remove the record from python.org DNS, or fix the IPv6 configuration? It's an issue on my PC because my PC has IPv6 address and so it cannot reach bugs.python.org. wget is really slow because it tries first IPv6, but then falls back to IPv4. Firefox tries first IPv4 and so doesn't have the issue. Victor 2013/10/12 Antoine Pitrou : > > Opened issue at http://psf.upfronthosting.co.za/roundup/meta/issue528 > > Regards > > Antoine. > > > > Le samedi 12 octobre 2013 à 14:40 +0200, Victor Stinner a écrit : >> Hi, >> >> The DNS server of python.org announce the IP address 2a01:4f8:131:2480::3: >> >> $ host -t bugs.python.org >> bugs.python.org has IPv6 address 2a01:4f8:131:2480::3 >> >> >> The problem is that I cannot connect to this IP address: >> >> $ ping6 -c 4 2a01:4f8:131:2480::3 >> PING 2a01:4f8:131:2480::3(2a01:4f8:131:2480::3) 56 data bytes >> >> --- 2a01:4f8:131:2480::3 ping statistics --- >> 4 packets transmitted, 0 received, 100% packet loss, time 2999ms >> >> >> Do you have a the same issue, or is it just me? >> >> Victor >> >> Infrastructure mailing list >> infrastruct...@python.org >> https://mail.python.org/mailman/listinfo/infrastructure >> Unsubscribe: >> https://mail.python.org/mailman/options/infrastructure/solipsis%40pitrou.net >> > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] urllib2.HTTPBasicAuthHandler doesn't work with GitHub API
Hi,
GitHub API v3 is intentionally broken (see
http://developer.github.com/v3/auth/):
> The main difference is that the RFC requires unauthenticated requests
> to be answered with 401 Unauthorized responses. In many places, this
> would disclose the existence of user data. Instead, the GitHub API
> responds with 404 Not Found. This may cause problems for HTTP
> libraries that assume a 401 Unauthorized response. The solution is to
> manually craft the Authorization header.
Unfortunately, urllib2.HTTPBasicAuthHandler relies on the
standard-conformant behavior. So a naive programmer (like me) who wants
to program against GitHub API using urllib2 (and foolishly ignores this
comment about the API non-conformance, because he thinks GitHub wouldn't
be that stupid and break all Python applications) writes something like
the attached script, spends couple of hours hitting this issue, until he
tries python-requests (which work) and his (mistaken) conclusion is that
urllib2 is a piece of crap which should never be used again.
I am not sure how widespread is this breaking of RFC, but it seems to me
that quite a lot (e.g., http://stackoverflow.com/a/9698319/164233 which
just en passant expects urllib2 authentication stuff to be useless), and
the question is whether it shouldn't be documented somehow and/or
urllib2.HTTPBasicAuthHandler shouldn't be modified to try add
Authenticate header first.
Any suggestions?
Best,
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled.
-- R. P. Feynman's concluding sentence
in his appendix to the Challenger Report
import urllib.request
import base64
import json
import os
import logging
from configparser import SafeConfigParser
logging.basicConfig(format='%(levelname)s:%(funcName)s:%(message)s',
level=logging.DEBUG)
class HTTPBrokenBasicAuthHandler(urllib.request.AbstractHTTPHandler,
urllib.request.AbstractBasicAuthHandler):
auth_header = 'Authorization'
def __init__(self, *args, **kwargs):
urllib.request.AbstractHTTPHandler.__init__(self,
*args, **kwargs)
self.set_http_debuglevel(2)
def do_open(self, http_class, req, **http_conn_args):
user, password = self.passwd.find_user_password(None, req.full_url)
b64str = base64.standard_b64encode(
'{}:{}'.format(user, password)).decode('ascii')
req.add_header(self.auth_header, 'Basic {}'.format(b64str))
urllib.request.AbstractHTTPHandler(self,
http_class, req, http_conn_args)
def http_error_401(self, req, fp, code, msg, headers):
url = req.full_url
response = self.http_error_auth_reqed('www-authenticate',
url, req, headers)
self.reset_retry_count()
return response
cp = SafeConfigParser()
cp.read(os.path.expanduser('~/.githubrc'))
# That configuration file should look something like
# [github]
# user=mylogin
# password=myveryverysecretpassword
gh_user = cp.get('github', 'user')
gh_passw = cp.get('github', 'password')
repo = 'odt2rst'
pwd_manager = urllib.request.HTTPPasswordMgrWithDefaultRealm()
pwd_manager.add_password(None, uri='https://api.github.com', user=gh_user,
passwd=gh_passw)
auth_handler = HTTPBrokenBasicAuthHandler(pwd_manager)
opener = urllib.request.build_opener(auth_handler)
urllib.request.install_opener(opener)
API_URL = "https://api.github.com/repos/{0}/{1}/issues/";
gh_url = API_URL.format(gh_user, repo, 1)
logging.debug("gh_url = {0}".format(gh_url))
req = urllib.request.Request(gh_url)
create_data = {
'title': 'Testing bug summary',
'body': '''This is a testing bug. I am writing here this stuff,
just to have some text for body.''',
'labels': ['BEbug']
}
handler = urllib.request.urlopen(req,
json.dumps(create_data).encode('utf8'))
print(handler.getcode())
print(handler)
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib2.HTTPBasicAuthHandler doesn't work with GitHub API
On Mon, Nov 4, 2013 at 6:11 AM, Matěj Cepl wrote: > I am not sure how widespread is this breaking of RFC, but it seems to me > that quite a lot (e.g., http://stackoverflow.com/a/9698319/164233 which > just en passant expects urllib2 authentication stuff to be useless), and > the question is whether it shouldn't be documented somehow and/or > urllib2.HTTPBasicAuthHandler shouldn't be modified to try add > Authenticate header first. > > Any suggestions? > Please file a bug report at bugs.python.org stating this. urllib2 tries to follow the RFC as much as possible, but ofcourse consider's de-facto standards and adopts to it. This can be documented for 2.x and can be 'fixed in 3.4. HTH, Senthil ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
2013/11/4 M.-A. Lemburg : > On 04.11.2013 11:01, Victor Stinner wrote: >> Hi, >> >> bugs.python.org is still not responding on IPv6. Can someone please >> remove the record from python.org DNS, or fix the IPv6 >> configuration? >> >> It's an issue on my PC because my PC has IPv6 address and so it cannot >> reach bugs.python.org. wget is really slow because it tries first >> IPv6, but then falls back to IPv4. Firefox tries first IPv4 and so >> doesn't have the issue. > > The infrastructure team cannot do anything about this, since > the tracker is hosted by Upfront Systems. But the PSF controls the DNS, no? ;; AUTHORITY SECTION: python.org. 2396IN NS ns2.p11.dynect.net. python.org. 2396IN NS ns3.p11.dynect.net. python.org. 2396IN NS ns1.p11.dynect.net. python.org. 2396IN NS ns4.p11.dynect.net. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
On 04.11.2013 16:10, Benjamin Peterson wrote: > 2013/11/4 M.-A. Lemburg : >> On 04.11.2013 11:01, Victor Stinner wrote: >>> Hi, >>> >>> bugs.python.org is still not responding on IPv6. Can someone please >>> remove the record from python.org DNS, or fix the IPv6 >>> configuration? >>> >>> It's an issue on my PC because my PC has IPv6 address and so it cannot >>> reach bugs.python.org. wget is really slow because it tries first >>> IPv6, but then falls back to IPv4. Firefox tries first IPv4 and so >>> doesn't have the issue. >> >> The infrastructure team cannot do anything about this, since >> the tracker is hosted by Upfront Systems. > > But the PSF controls the DNS, no? > > ;; AUTHORITY SECTION: > python.org. 2396IN NS ns2.p11.dynect.net. > python.org. 2396IN NS ns3.p11.dynect.net. > python.org. 2396IN NS ns1.p11.dynect.net. > python.org. 2396IN NS ns4.p11.dynect.net. Yes, but only Upfront Systems knows about the correct IPv6 address :-) Simply removing it would be short term work-around, though. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2013-11-19: Python Meeting Duesseldorf ... 15 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
On 04.11.2013 11:01, Victor Stinner wrote: > Hi, > > bugs.python.org is still not responding on IPv6. Can someone please > remove the record from python.org DNS, or fix the IPv6 > configuration? > > It's an issue on my PC because my PC has IPv6 address and so it cannot > reach bugs.python.org. wget is really slow because it tries first > IPv6, but then falls back to IPv4. Firefox tries first IPv4 and so > doesn't have the issue. The infrastructure team cannot do anything about this, since the tracker is hosted by Upfront Systems. They are hosting the instance at Hetzner in Germany, which does support IPv6. Do we have someone with login permission for the server running RoundUp ? If not, we should probably find someone at Upfront Systems to check the configuration. > Victor > > 2013/10/12 Antoine Pitrou : >> >> Opened issue at http://psf.upfronthosting.co.za/roundup/meta/issue528 >> >> Regards >> >> Antoine. >> >> >> >> Le samedi 12 octobre 2013 à 14:40 +0200, Victor Stinner a écrit : >>> Hi, >>> >>> The DNS server of python.org announce the IP address 2a01:4f8:131:2480::3: >>> >>> $ host -t bugs.python.org >>> bugs.python.org has IPv6 address 2a01:4f8:131:2480::3 >>> >>> >>> The problem is that I cannot connect to this IP address: >>> >>> $ ping6 -c 4 2a01:4f8:131:2480::3 >>> PING 2a01:4f8:131:2480::3(2a01:4f8:131:2480::3) 56 data bytes >>> >>> --- 2a01:4f8:131:2480::3 ping statistics --- >>> 4 packets transmitted, 0 received, 100% packet loss, time 2999ms >>> >>> >>> Do you have a the same issue, or is it just me? >>> >>> Victor >>> >>> Infrastructure mailing list >>> infrastruct...@python.org >>> https://mail.python.org/mailman/listinfo/infrastructure >>> Unsubscribe: >>> https://mail.python.org/mailman/options/infrastructure/solipsis%40pitrou.net >>> >> >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > > Infrastructure mailing list > infrastruct...@python.org > https://mail.python.org/mailman/listinfo/infrastructure > Unsubscribe: > https://mail.python.org/mailman/options/infrastructure/mal%40egenix.com > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2013-11-19: Python Meeting Duesseldorf ... 15 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
On lun., 2013-11-04 at 16:09 +0100, M.-A. Lemburg wrote: > On 04.11.2013 11:01, Victor Stinner wrote: > > Hi, > > > > bugs.python.org is still not responding on IPv6. Can someone please > > remove the record from python.org DNS, or fix the IPv6 > > configuration? > > > > It's an issue on my PC because my PC has IPv6 address and so it cannot > > reach bugs.python.org. wget is really slow because it tries first > > IPv6, but then falls back to IPv4. Firefox tries first IPv4 and so > > doesn't have the issue. > > The infrastructure team cannot do anything about this, since > the tracker is hosted by Upfront Systems. > > They are hosting the instance at Hetzner in Germany, which does > support IPv6. > > Do we have someone with login permission for the server running > RoundUp ? I think Ezio and Martin have access to the machine, but not necessarily root access; and, furthermore, the problem might be somewhere else on the network. I think the best short-term measure is to disable the IPv6 resolution for bugs.python.org. Otherwise people will run in the same issue over and over again. Regards Antoine. > > If not, we should probably find someone at Upfront Systems to check > the configuration. > > > Victor > > > > 2013/10/12 Antoine Pitrou : > >> > >> Opened issue at http://psf.upfronthosting.co.za/roundup/meta/issue528 > >> > >> Regards > >> > >> Antoine. > >> > >> > >> > >> Le samedi 12 octobre 2013 à 14:40 +0200, Victor Stinner a écrit : > >>> Hi, > >>> > >>> The DNS server of python.org announce the IP address 2a01:4f8:131:2480::3: > >>> > >>> $ host -t bugs.python.org > >>> bugs.python.org has IPv6 address 2a01:4f8:131:2480::3 > >>> > >>> > >>> The problem is that I cannot connect to this IP address: > >>> > >>> $ ping6 -c 4 2a01:4f8:131:2480::3 > >>> PING 2a01:4f8:131:2480::3(2a01:4f8:131:2480::3) 56 data bytes > >>> > >>> --- 2a01:4f8:131:2480::3 ping statistics --- > >>> 4 packets transmitted, 0 received, 100% packet loss, time 2999ms > >>> > >>> > >>> Do you have a the same issue, or is it just me? > >>> > >>> Victor > >>> > >>> Infrastructure mailing list > >>> infrastruct...@python.org > >>> https://mail.python.org/mailman/listinfo/infrastructure > >>> Unsubscribe: > >>> https://mail.python.org/mailman/options/infrastructure/solipsis%40pitrou.net > >>> > >> > >> > >> ___ > >> Python-Dev mailing list > >> Python-Dev@python.org > >> https://mail.python.org/mailman/listinfo/python-dev > >> Unsubscribe: > >> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > > > > Infrastructure mailing list > > infrastruct...@python.org > > https://mail.python.org/mailman/listinfo/infrastructure > > Unsubscribe: > > https://mail.python.org/mailman/options/infrastructure/mal%40egenix.com > > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib2.HTTPBasicAuthHandler doesn't work with GitHub API
Hi there, Thanks for letting us know, however you'll need to report this bug at: http://bugs.python.org/ I'd recommend using one of the Python libraries listed here if that's possible in your case: http://developer.github.com/v3/libraries/#python I know that the following library is well maintained: https://github.com/sigmavirus24/github3.py Cheers, James ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
Two more approaches that can help when you haven't pushed yet: - hg rollback undoes the most recent local commit while leaving the local workspace unchanged so the files are now patched but not committed - hg strip deletes a revision and all its descendents (requires some extension to be configured); it also rolls back your workspace so you'd have to repatch using hg import --no-commit. (BTW everybody here knows you can give hg import a URL straight from Rietveld's "raw diff download" right?) On Mon, Nov 4, 2013 at 1:04 AM, Oleg Broytman wrote: > Hi! > > On Mon, Nov 04, 2013 at 03:56:25AM -0500, Terry Reedy > wrote: > > The one > > thing I tried but could not do was to directly change status 'A' > > back to '?'. > > hg forget file > > Oleg. > -- > Oleg Broytmanhttp://phdru.name/p...@phdru.name >Programmers don't die, they just GOSUB without RETURN. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
On Mon, 04 Nov 2013 16:34:46 +0100, Antoine Pitrou wrote: > On lun., 2013-11-04 at 16:09 +0100, M.-A. Lemburg wrote: > > On 04.11.2013 11:01, Victor Stinner wrote: > > > Hi, > > > > > > bugs.python.org is still not responding on IPv6. Can someone please > > > remove the record from python.org DNS, or fix the IPv6 > > > configuration? > > > > > > It's an issue on my PC because my PC has IPv6 address and so it cannot > > > reach bugs.python.org. wget is really slow because it tries first > > > IPv6, but then falls back to IPv4. Firefox tries first IPv4 and so > > > doesn't have the issue. > > > > The infrastructure team cannot do anything about this, since > > the tracker is hosted by Upfront Systems. > > > > They are hosting the instance at Hetzner in Germany, which does > > support IPv6. > > > > Do we have someone with login permission for the server running > > RoundUp ? > > I think Ezio and Martin have access to the machine, but not necessarily > root access; and, furthermore, the problem might be somewhere else on > the network. > > I think the best short-term measure is to disable the IPv6 resolution > for bugs.python.org. Otherwise people will run in the same issue over > and over again. We have root, but I don't think that helps. I currently see this: eth0 Link encap:Ethernet HWaddr 6c:62:6d:85:bb:7b inet addr:46.4.197.70 Bcast:46.4.197.71 Mask:255.255.255.248 inet6 addr: 2a01:4f8:131:2480::3/64 Scope:Global so the problem appears to be a network issue (as far as I can see, there's no firewall running on the box itself). Disabling the AAA name record until we get a response from upfront sounds like a good idea. (I've added the upfront folks as nosy on the ticket Antoine opened on the meta-tracker.) --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
On 04.11.2013 17:05, R. David Murray wrote: > On Mon, 04 Nov 2013 16:34:46 +0100, Antoine Pitrou wrote: >> On lun., 2013-11-04 at 16:09 +0100, M.-A. Lemburg wrote: >>> On 04.11.2013 11:01, Victor Stinner wrote: Hi, bugs.python.org is still not responding on IPv6. Can someone please remove the record from python.org DNS, or fix the IPv6 configuration? It's an issue on my PC because my PC has IPv6 address and so it cannot reach bugs.python.org. wget is really slow because it tries first IPv6, but then falls back to IPv4. Firefox tries first IPv4 and so doesn't have the issue. >>> >>> The infrastructure team cannot do anything about this, since >>> the tracker is hosted by Upfront Systems. >>> >>> They are hosting the instance at Hetzner in Germany, which does >>> support IPv6. >>> >>> Do we have someone with login permission for the server running >>> RoundUp ? >> >> I think Ezio and Martin have access to the machine, but not necessarily >> root access; and, furthermore, the problem might be somewhere else on >> the network. >> >> I think the best short-term measure is to disable the IPv6 resolution >> for bugs.python.org. Otherwise people will run in the same issue over >> and over again. > > We have root, but I don't think that helps. > > I currently see this: > > eth0 Link encap:Ethernet HWaddr 6c:62:6d:85:bb:7b > inet addr:46.4.197.70 Bcast:46.4.197.71 Mask:255.255.255.248 > inet6 addr: 2a01:4f8:131:2480::3/64 Scope:Global > > so the problem appears to be a network issue (as far as I can see, > there's no firewall running on the box itself). Disabling the AAA name > record until we get a response from upfront sounds like a good idea. > (I've added the upfront folks as nosy on the ticket Antoine opened > on the meta-tracker.) Some things to try on the box: * ping6 2001:888:2000:d::a2 (that's python.org) * check whether the web server is actually listening on the IPv6 address * check whether a IPv6 default route is set up If the first doesn't work, there's likely a router problem with the server, which only Upfront can resolve (via a support request to Hetzner or by checking their server IPv6 settings). Here's the configuration page for the IPv6 setup: http://wiki.hetzner.de/index.php/Netzkonfiguration_Debian/en -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2013-11-19: Python Meeting Duesseldorf ... 15 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
2013/11/4 M.-A. Lemburg : > Some things to try on the box: > > * ping6 2001:888:2000:d::a2 (that's python.org) $ ping6 -c 4 2001:888:2000:d::a2 PING 2001:888:2000:d::a2(2001:888:2000:d::a2) 56 data bytes 64 bytes from 2001:888:2000:d::a2: icmp_seq=1 ttl=56 time=53.0 ms 64 bytes from 2001:888:2000:d::a2: icmp_seq=2 ttl=56 time=53.0 ms 64 bytes from 2001:888:2000:d::a2: icmp_seq=3 ttl=56 time=58.4 ms 64 bytes from 2001:888:2000:d::a2: icmp_seq=4 ttl=56 time=122 ms --- 2001:888:2000:d::a2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 53.024/71.841/122.817/29.514 ms => OK > * check whether the web server is actually listening on the > IPv6 address smithers$ wget -O python.html 'http://[2001:888:2000:d::a2]/' --2013-11-04 20:53:27-- http://[2001:888:2000:d::a2]/ Connecting to [2001:888:2000:d::a2]:80... connecté. requête HTTP transmise, en attente de la réponse...302 Found Emplacement: http://www.python.org [suivant] --2013-11-04 20:53:27-- http://www.python.org/ Résolution de www.python.org (www.python.org)... 2001:888:2000:d::a2, 82.94.164.162 Reusing existing connection to [2001:888:2000:d::a2]:80. requête HTTP transmise, en attente de la réponse...200 OK Longueur: 20423 (20K) [text/html] Sauvegarde en : «python.html» 100%[=>] 20 423 113KB/s ds 0,2s 2013-11-04 20:53:28 (113 KB/s) - «python.html» sauvegardé [20423/20423] => OK > * check whether a IPv6 default route is set up I don't know how to check that. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The new SHA-3 is the old SHA-3
Good news everybody! A while ago John Kelsey has presented NIST's plans to change SHA-3 [1] in order to make it faster but also weaker. Last Friday he posted a mail on NIST's internal hash-forum mailing list. NIST is planing to drop these plans and to move forward with the SHA-3 draft in its original state. I can keep the sha3 module in Python 3.4 and don't have to remove it. Maybe I'm going to add the new SHAKE functions to hashlib, too. But first let me explain the background. NIST is going to standardize four replacements for SHA2: SHA3-224, SHA3-256, SHA3-384 and SHA3-512. (The number after the hyphen is the output size in bits.) These are going to be standardized variants of the Keccak-f[1600] sponge construction. [2] Similar to a real sponge Keccak has a capacity, can absorb data at some rate and can be squeezed to output data. The rate parameter affects performance of the Keccak construction (higher rate == faster). A higher capacity results in better collision resistance. Keccak-f[1600] rate + capacity = 1600 bits with capacity/2 collision and pre-image resistance. Contrary to a real sponge the squeeze function can return arbitrarily amounts of data. The old and new parameters for the SHA-3 are SHA3-224: capacity=448, output=224 SHA3-256: capacity=512, output=256 SHA3-384: capacity=768, output=384 SHA3-512: capacity=1024, output=512 NIST was about to standardize SHA3-224/SHA3-256 with capacity=256 and SHA3-384 /SHA3-512 with capacity=512. That's (most like) off the stove. However NIST is going to standardize two additional functions: SHAKE128 and SHAKE256. These functions support arbitrary length output with a collision resistance of 128/256 bits with a capacity of 256/512. The SHAKE functions can be easily implemented on top of the current code and PEP 247 API with mandatory length arguments for digst() and hexdigest(). Christian [1] http://bristolcrypto.blogspot.de/2013/08/ches-invited-talk-future-of-sha-3.html [2] http://keccak.noekeon.org/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
On lun., 2013-11-04 at 20:54 +0100, Victor Stinner wrote: > 2013/11/4 M.-A. Lemburg : > > Some things to try on the box: > > > > * ping6 2001:888:2000:d::a2 (that's python.org) > > $ ping6 -c 4 2001:888:2000:d::a2 [...] On the box, not on your home machine! Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Infrastructure] bugs.python.org not reachable in IPv6?
On 04.11.2013 20:54, Victor Stinner wrote: > 2013/11/4 M.-A. Lemburg : >> Some things to try on the box: >> >> * ping6 2001:888:2000:d::a2 (that's python.org) > > $ ping6 -c 4 2001:888:2000:d::a2 > PING 2001:888:2000:d::a2(2001:888:2000:d::a2) 56 data bytes > 64 bytes from 2001:888:2000:d::a2: icmp_seq=1 ttl=56 time=53.0 ms > 64 bytes from 2001:888:2000:d::a2: icmp_seq=2 ttl=56 time=53.0 ms > 64 bytes from 2001:888:2000:d::a2: icmp_seq=3 ttl=56 time=58.4 ms > 64 bytes from 2001:888:2000:d::a2: icmp_seq=4 ttl=56 time=122 ms > > --- 2001:888:2000:d::a2 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 3003ms > rtt min/avg/max/mdev = 53.024/71.841/122.817/29.514 ms > > => OK > >> * check whether the web server is actually listening on the >> IPv6 address > > smithers$ wget -O python.html 'http://[2001:888:2000:d::a2]/' > --2013-11-04 20:53:27-- http://[2001:888:2000:d::a2]/ > Connecting to [2001:888:2000:d::a2]:80... connecté. > requête HTTP transmise, en attente de la réponse...302 Found > Emplacement: http://www.python.org [suivant] > --2013-11-04 20:53:27-- http://www.python.org/ > Résolution de www.python.org (www.python.org)... 2001:888:2000:d::a2, > 82.94.164.162 > Reusing existing connection to [2001:888:2000:d::a2]:80. > requête HTTP transmise, en attente de la réponse...200 OK > Longueur: 20423 (20K) [text/html] > Sauvegarde en : «python.html» > > 100%[=>] > 20 423 113KB/s ds 0,2s > > 2013-11-04 20:53:28 (113 KB/s) - «python.html» sauvegardé [20423/20423] > > => OK > >> * check whether a IPv6 default route is set up > > I don't know how to check that. route -n -A inet6 should print the default route setup for IPv6. This has to list a working and ping6'able gateway. BTW: The above was meant to be run on the bugs.python.org box, not your box :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2013-11-19: Python Meeting Duesseldorf ... 15 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On 11/04/2013 07:52 AM, Guido van Rossum wrote: Two more approaches that can help when you haven't pushed yet: - hg rollback undoes the most recent local commit while leaving the local workspace unchanged so the files are now patched but not committed - hg strip deletes a revision and all its descendents (requires some extension to be configured); it also rolls back your workspace so you'd have to repatch using hg import --no-commit. (BTW everybody here knows you can give hg import a URL straight from Rietveld's "raw diff download" right?) Oh, cool! Thanks for the hint! :) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] VAX NaN evaluations
Hi,
The nice Python folks who were at SCALE in Los Angeles last year gave me a
Python t-shirt for showing Python working on m68k and for suggesting that
I'd get it working on VAX. With libffi support for VAX from Miod Vallat,
this is now possible.
However, when compiling Python, it seems that attempts to evaluate NaN are
made in test_complex.py, test_complex_args.py, test_float.py and
test_math.py (at least in 2.7.5 - I'm working on compiling 3.3.2 now).
The short answer is to skip those tests on VAXen. The better answer is to
patch any isnan functions to always return false on VAXen and patch any
code which tries to parse, for instance, float("NaN") to use something
uncommon, such as the largest representable number (const union __double_u
__infinity = { { 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff } };) or
something else equally rare. While code which depends on the ability to
evaluate NaNs in some meaninful way will likely break on VAXen, I think
this is better than raising an exception.
Being completely new to Python, I'm not sure what's best to do here. What
would be the best way to find code which handles evaluation of "NaN"? Does
anyone have any recommendations?
Thanks,
John Klos
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
> The nice Python folks who were at SCALE in Los Angeles last year gave me a
> Python t-shirt for showing Python working on m68k and for suggesting that
> I'd get it working on VAX. With libffi support for VAX from Miod Vallat,
> this is now possible.
>
> However, when compiling Python, it seems that attempts to evaluate NaN are
> made in test_complex.py, test_complex_args.py, test_float.py and
> test_math.py (at least in 2.7.5 - I'm working on compiling 3.3.2 now).
>
> The short answer is to skip those tests on VAXen. The better answer is to
> patch any isnan functions to always return false on VAXen and patch any code
> which tries to parse, for instance, float("NaN") to use something uncommon,
> such as the largest representable number (const union __double_u __infinity
> = { { 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff } };) or something else
> equally rare.
I think you are asking for trouble here. As VAX floating point does
not appear to have hardware support for NaN, attempts to "emulate"
such could be potentially dangerous. If such software were running
life-support systems, for example, your decision to emulate it would
put you at fault for criminal negligence, whereas a failure simply due
to lack of implementation would be more benign incompetence. Probably
better for an exception to be thrown or other hard error.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
I think I spoke to soon on my earlier reply. If you have control over the whole system, you could *set* policy on behalf of a whole platform (like VAX) so you can "safely" use an otherwise non-normal set of bits to designate divide by zero (a negative sign bit with the rest all zeros, for example) or other NaNs. But then you should be on IEEE floating point committee and make these *universal* for the particular platform in question. Despite the debate from another thread, there's probably no wisdom in using other magical bit patterns (xDEADBEEF). -- MarkJ Tacoma, Washington ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On 5 Nov 2013 02:03, "Guido van Rossum" wrote: > > Two more approaches that can help when you haven't pushed yet: > > - hg rollback undoes the most recent local commit while leaving the local workspace unchanged so the files are now patched but not committed > > - hg strip deletes a revision and all its descendents (requires some extension to be configured); it also rolls back your workspace so you'd have to repatch using hg import --no-commit. A couple more tips: - I actually have "--no-commit" configured as a standard option for hg import in my .hgrc file so I never forget - "hg pull --rebase" avoids having a merge in the history for push races that involve only default branch changes - hg histedit is a quite useful extension for adjusting commit history prior to publication. (most of the history editing mercurial features require enabling the appropriate extensions, but it's well worth taking the time to do so - git users in particular may find that appropriate use of extensions enables a more familiar local user experience) Cheers, Nick. > > (BTW everybody here knows you can give hg import a URL straight from Rietveld's "raw diff download" right?) > > > On Mon, Nov 4, 2013 at 1:04 AM, Oleg Broytman wrote: >> >> Hi! >> >> On Mon, Nov 04, 2013 at 03:56:25AM -0500, Terry Reedy wrote: >> > The one >> > thing I tried but could not do was to directly change status 'A' >> > back to '?'. >> >> hg forget file >> >> Oleg. >> -- >> Oleg Broytmanhttp://phdru.name/ p...@phdru.name >>Programmers don't die, they just GOSUB without RETURN. >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
The short answer is to skip those tests on VAXen. The better answer is to
patch any isnan functions to always return false on VAXen and patch any code
which tries to parse, for instance, float("NaN") to use something uncommon,
such as the largest representable number (const union __double_u __infinity
= { { 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff } };) or something else
equally rare.
I think you are asking for trouble here. As VAX floating point does
not appear to have hardware support for NaN, attempts to "emulate"
such could be potentially dangerous. If such software were running
life-support systems, for example, your decision to emulate it would
put you at fault for criminal negligence, whereas a failure simply due
to lack of implementation would be more benign incompetence. Probably
better for an exception to be thrown or other hard error.
We'd have to have one uncommor and two extremely unlikely events all
happen simultaneously for your example to be of concern:
One, someone would have to care that NaN representations are done using an
arbitrary value rather than an actual NaN representation in IEEE 754. I
can imagine instances where this could cause an issue, but people who
write proper math code would tend to write correct code anyway.
Two, someone would have to decide to use Python with NaN testing /
comparison code to run some sort of life-support system. I can't imagine
anyone who isn't already horribly incompetent doing anything like this.
Three, that someone would have to want to run that code and that
life-support system on a VAX (or other system which doesn't handle NaNs.
While you make a point worth making, nobody is ever going to be at fault
for criminal negligence for having implementation side-cases. If that were
even possible, open source software would be litigated out of existence
and everyone would be suing Microsoft for their monumental failures.
So you indirectly say that you think it'd be best to just skip the tests
and leave it so tha any attempts to handle NaNs would dump core. Is that
right?
Thanks,
John
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
On Mon, Nov 4, 2013 at 3:47 PM, John Klos wrote: > What would be the best way to find code which handles evaluation of "NaN"? I would be surprised to find NaN handling outside of math module, float object and their complex counterparts (cmath and complex object). Other areas that deal with NaNs such as decimal module should just call float methods and/or math functions. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
> We'd have to have one uncommor and two extremely unlikely events all happen
> simultaneously for your example to be of concern:
Understood. But when things run millions of times a second,
"extremely unlikely" things can happen more often that you wanted.
> Two, someone would have to decide to use Python with NaN testing /
> comparison code to run some sort of life-support system. I can't imagine
> anyone who isn't already horribly incompetent doing anything like this.
People incorporate third-party software, often unknowingly, trusting
the process and "system" even though it is almost always *completely*
informal and simply a community of good-hearted individuals.
> Three, that someone would have to want to run that code and that
> life-support system on a VAX (or other system which doesn't handle NaNs.
>
> While you make a point worth making, nobody is ever going to be at fault for
> criminal negligence for having implementation side-cases.
You *could* be right. I'm just saying what would be safe, legally and
morally speaking.
> If that were even
> possible, open source software would be litigated out of existence and
> everyone would be suing Microsoft for their monumental failures.
End-to-end open source software doesn't (generally) make any
guarantees ("without warrantees of any kind"), so there's little basis
to sue. As for MSFT, people have been suing Microsoft. Apparently,
they have good lawyers, and people are smart enough not to use their
software too much in mission-critical applications (although
apparently this has changed over the years).
> So you indirectly say that you think it'd be best to just skip the tests and
> leave it so tha any attempts to handle NaNs would dump core. Is that right?
That keeps your hands most safe, but again, I suggest you research the
IEEE standard to see if there's already a standard for VAX rather than
spinning your own home-brewed version, or join the IEEE committee and
make one.
--
MarkJ
Tacoma, Washington
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "PyObject *module" for module-level functions?
When Clinic generates a function, it knows what kind of callable it
represents, and it names the first argument (the "PyObject *") accordingly:
* module-level function ("self"),
* method ("self"),
* class method ("cls"), or
* class static ("null").
I now boldly propose that for the first one, the module-level function,
the PyObject * parameter should be named "module". The object passed in
is the module object, it's not a "self" in any conventional sense of the
word.
This would enhance readability, as I assert the name "self" there is
confusing. The argument is rarely used on module-level functions, and
very little code is converted right now using Clinic anyway. I
therefore assert this change would break very little code, and the code
that did get broken by this change could be fixed as part of the process
of converting it to Clinic.
But now would be the time to make this change, before doing the big push
to convert to Clinic. (A couple of weeks ago would have been even
better...!)
+1? -1?
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "PyObject *module" for module-level functions?
On 5 Nov 2013 08:49, "Larry Hastings" wrote:
>
>
>
> When Clinic generates a function, it knows what kind of callable it
represents, and it names the first argument (the "PyObject *") accordingly:
> module-level function ("self"),
> method ("self"),
> class method ("cls"), or
> class static ("null").
> I now boldly propose that for the first one, the module-level function,
the PyObject * parameter should be named "module". The object passed in is
the module object, it's not a "self" in any conventional sense of the word.
>
> This would enhance readability, as I assert the name "self" there is
confusing. The argument is rarely used on module-level functions, and very
little code is converted right now using Clinic anyway. I therefore assert
this change would break very little code, and the code that did get broken
by this change could be fixed as part of the process of converting it to
Clinic.
>
> But now would be the time to make this change, before doing the big push
to convert to Clinic. (A couple of weeks ago would have been even
better...!)
>
> +1? -1?
+1 from me, as they're not really methods of the module instance (i.e.
dynamically bound when retrieved from the module), even though they behave
a little like they are.
Instead of relying on the descriptor protocol (which doesn't trigger
because module level functions are stored in an instance namespace), we
play games when creating the Python level callables during module creation
in order to prebind the module object.
Cheers,
Nick.
>
>
> /arry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On 11/4/2013 5:15 PM, Nick Coghlan wrote: - I actually have "--no-commit" configured as a standard option for hg import in my .hgrc file so I never forget On Windows, hg uses .ini files. Do you have any idea what the [section] option = value would look like? There is gui dialog for managing the .ini files, but it does not have a page for import options. - "hg pull --rebase" avoids having a merge in the history for push races that involve only default branch changes Can this be done routinely for all pulls? Does it hurt if here are working directory changes in 2 or 3 branches? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "PyObject *module" for module-level functions?
On Mon, Nov 4, 2013 at 3:36 PM, Nick Coghlan wrote:
> On 5 Nov 2013 08:49, "Larry Hastings" wrote:
> > When Clinic generates a function, it knows what kind of callable it
> represents, and it names the first argument (the "PyObject *") accordingly:
> > module-level function ("self"),
> > method ("self"),
> > class method ("cls"), or
> > class static ("null").
> > I now boldly propose that for the first one, the module-level function,
> the PyObject * parameter should be named "module". The object passed in is
> the module object, it's not a "self" in any conventional sense of the word.
> >
> > This would enhance readability, as I assert the name "self" there is
> confusing. The argument is rarely used on module-level functions, and very
> little code is converted right now using Clinic anyway. I therefore assert
> this change would break very little code, and the code that did get broken
> by this change could be fixed as part of the process of converting it to
> Clinic.
> >
> > But now would be the time to make this change, before doing the big push
> to convert to Clinic. (A couple of weeks ago would have been even
> better...!)
> >
> > +1? -1?
>
> +1 from me, as they're not really methods of the module instance (i.e.
> dynamically bound when retrieved from the module), even though they behave
> a little like they are.
>
> Instead of relying on the descriptor protocol (which doesn't trigger
> because module level functions are stored in an instance namespace), we
> play games when creating the Python level callables during module creation
> in order to prebind the module object
>
+1 from me too. This finally fixes a silly mistake I made well over two
decades ago!
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
Quoting John Klos : The nice Python folks who were at SCALE in Los Angeles last year gave me a Python t-shirt for showing Python working on m68k and for suggesting that I'd get it working on VAX. With libffi support for VAX from Miod Vallat, this is now possible. I'm sorry to hear that - you might have been wasting your time (but then, perhaps not). We decided a while ago that the regular Python releases will not support VAX/VMS any longer. So any code you write has zero chance of being integrated into Python (the same holds for m68k code, BTW). That said, you are free to maintain your own branch of Python. In that branch, you can make whatever changes you consider necessary, but you will be on your own. Kind regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "PyObject *module" for module-level functions?
On Mon, Nov 4, 2013 at 3:47 PM, Larry Hastings wrote:
> When Clinic generates a function, it knows what kind of callable it
> represents, and it names the first argument (the "PyObject *") accordingly:
>
> module-level function ("self"),
> method ("self"),
> class method ("cls"), or
> class static ("null").
>
> I now boldly propose that for the first one, the module-level function, the
> PyObject * parameter should be named "module". The object passed in is the
> module object, it's not a "self" in any conventional sense of the word.
>
> This would enhance readability, as I assert the name "self" there is
> confusing. The argument is rarely used on module-level functions, and very
> little code is converted right now using Clinic anyway. I therefore assert
> this change would break very little code, and the code that did get broken
> by this change could be fixed as part of the process of converting it to
> Clinic.
>
> But now would be the time to make this change, before doing the big push to
> convert to Clinic. (A couple of weeks ago would have been even better...!)
>
> +1? -1?
+1
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
On Mon, Nov 04, 2013 at 08:47:53PM +, John Klos wrote:
[...]
> The short answer is to skip those tests on VAXen. The better answer is to
> patch any isnan functions to always return false on VAXen and patch any
> code which tries to parse, for instance, float("NaN") to use something
> uncommon, such as the largest representable number (const union __double_u
> __infinity = { { 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff } };) or
> something else equally rare. While code which depends on the ability to
> evaluate NaNs in some meaninful way will likely break on VAXen, I think
> this is better than raising an exception.
(I take it that emulating NANs at the object level isn't an option?
That's what the Decimal class does.)
I write code that uses NANs, and if running it on a VAX would break my
code, I'd rather it broke it nice and cleanly with an exception rather
than by just giving the wrong result.
With an exception, I can see straight away that something is wrong, and
decide the best way to deal with the lack of NANs for my application. If
you helpfully "fix" it for me by returning a non-NAN number, or even an
infinity, at best I'll get a failure somewhere else in the application,
far from where the break actually occurred; at worst, I may never know
that my application is actually generating garbage results.
I'm reminded about a quote from Chris Smith:
"I find it amusing when novice programmers believe their main job is
preventing programs from crashing. ... More experienced programmers
realize that correct code is great, code that crashes could use
improvement, but incorrect code that doesn’t crash is a horrible
nightmare."
Not to imply that you're a novice programmer (sorry for the implication)
but please don't do that to your users. The Zen of Python talks about
this:
py> import this
The Zen of Python, by Tim Peters
[...]
Errors should never pass silently.
Just to be clear, rather than dump core (which you suggested in a later
email), if you cannot support NANs on VAXen, you should modify float to
raise a ValueError exception. Pure Python code like float('nan') should
never dump core, it should raise:
ValueError: could not convert string to float: 'nan'
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
Am 05.11.2013 00:43, schrieb Terry Reedy: > On 11/4/2013 5:15 PM, Nick Coghlan wrote: > >> - I actually have "--no-commit" configured as a standard option for hg >> import in my .hgrc file so I never forget > > On Windows, hg uses .ini files. Do you have any idea what the > [section] > option = value > would look like? There is gui dialog for managing the .ini files, but it > does not have a page for import options. It'll look like this: [defaults] import = --no-commit >> - "hg pull --rebase" avoids having a merge in the history for push races >> that involve only default branch changes > > Can this be done routinely for all pulls? Does it hurt if here are > working directory changes in 2 or 3 branches? It won't work with merge commits, so if you locally commit to 3.3 and merge to default, pull --rebase will error out if there are remote changes. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "PyObject *module" for module-level functions?
Larry Hastings, 04.11.2013 23:47:
> When Clinic generates a function, it knows what kind of callable it
> represents, and it names the first argument (the "PyObject *") accordingly:
>
> * module-level function ("self"),
> * method ("self"),
> * class method ("cls"), or
> * class static ("null").
>
> I now boldly propose that for the first one, the module-level function, the
> PyObject * parameter should be named "module". The object passed in is the
> module object, it's not a "self" in any conventional sense of the word.
>
> This would enhance readability, as I assert the name "self" there is
> confusing. The argument is rarely used on module-level functions
Since this only relates to the argument clinic, I assume this change
doesn't get in the way of making module level functions real methods of the
module, does it?
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On 11/5/2013 12:50 AM, Georg Brandl wrote: [defaults] import = --no-commit Thank you. A message in a patch is now ignored rather than auto-committed. I still have to click away the edit box that would allow me to enter a message and override 'no-commit', but I have always managed to do that without accidentally hitting a key ;-). -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
Am 05.11.2013 08:31, schrieb Terry Reedy: > On 11/5/2013 12:50 AM, Georg Brandl wrote: > >> [defaults] >> import = --no-commit > > Thank you. A message in a patch is now ignored rather than > auto-committed. Yes; that's why I'd prefer the commit-and-then-amend way. Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
