Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
On Thu, Jun 16, 2016 at 10:26:22AM -0700, Nick Coghlan wrote: > meta-guidance. However, there are multiple levels of improvement being > pursued here, since developer ignorance of security concerns and > problematic defaults at the language level is a chronic problem rather > than an acute one (and one that affects all languages, not just > Python). For a while Christian Heimes has speculated on Twitter about writing a Secure Programming HOWTO. At the last language summit in Montreal, I told him I'd be happy to do the actual writing and editing if given a detailed outline. (I miss not having an ongoing writing project since ceasing to write the "What's New", but have no ideas for anything to write about.) That offer is still open, if Christian or someone else wants to produce an outline. --amk ___ 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] Yearly PyPI breakage
On Thu, May 05, 2016 at 10:31:48PM -0400, Donald Stufft wrote: > I don't believe we've ever told someone that something can't happen because of > Warehouse, only that *I* won't implement something until after Warehouse. That > often times means that something won't happen until after Warehouse because of > the severe shortage of people with enough time and motivation to work on this > stuff but if someone did step up more things would get done. Could the PSF help with this, whether by paying for Donald's (or a consultant's) time to whatever do final implementation, polishing, testing, or sysadmin work is required? --amk ___ 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] Typo in PEP-0423
On Sat, Dec 19, 2015 at 08:55:26PM +1000, Nick Coghlan wrote: > Even once the new docs are in place, getting them to the top of search > of results ahead of archived material that may be years out of date is > likely to still be a challenge - for example, even considering just > the legacy distutils docs, the "3.1" and "2" docs appear ... We probably need to update https://docs.python.org/robots.txt, which currently contains: # Prevent development and old documentation from showing up in search results. User-agent: * # Disallow: /dev Disallow: /release The intent was to allow the latest version of the docs to be crawled. Unfortunately, with the current hierarchy we'd have to disallow each version, e.g. Disallow: /2.6/* Disallow: /3.0/* Disallow: /3.1/* And we'd need to update it for each new major release. --amk ___ 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] How far to go with user-friendliness
On Tue, Jul 14, 2015 at 09:53:33AM -0700, Ethan Furman wrote: Part of writing tests is making sure they fail (and for the right reason) -- proper testing of the tests would reveal such a typo. And there are other failure modes for writing tests that succeed but are not testing what you think. For example, you might re-use the same method name: def test_connection(self): # Never executed ... ... 200 lines and 10 other test methods later ... def test_connection(self): ... Or misuse assertRaises: with self.assertRaises(TypeError): 1 + a # Second statement never reached [] + 'b' I don't think unittest can protect its users from such things. --amk ___ 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] cpython (3.4): #23891: add a section to the Tutorial describing virtual environments and pip
#23891: add a section to the Tutorial describing virtual environments and pip This is very cool, thank you! Thanks! This suggestion came up at April's Language Summit as an improvement to make the tutorial better reflect current practice. Another suggestion was to suggest the 'requests' module in a few places in the docs (issue #23989); Van L. made that change soon after the Summit. --amk ___ 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] Tracker Stats
On Mon, Jun 23, 2014 at 04:12:24PM -0400, R. David Murray wrote: The stats graphs are based on the data generated for the weekly issue report. I have a patched version of that report that adds the bug/enhancement info. After PyCon, I started working on a scraper that would produce a bunch of different lists and charts. My ideas were: * pie charts of issues by status and type. * list or histogram of open library issues by module, perhaps limited to the top N modules * list of N oldest issues with no subsequent activity (the unreviewed ones) * list of N people with the most open issues assigned to them The idea is to provide charts that help us direct effort to particular subsets of bugs. --amk ___ 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] Language Summit notes
On Wed, Apr 09, 2014 at 09:08:04PM -0400, Guido van Rossum wrote: To anyone who took notes at the language summit at PyCon today, even if you took them just for yourself, would you mind posting them here? It would be good to have some kind of (informal!) as soon as possible, before we collectively forget. You won't be held responsible for correctness. From a 30-second check, the recordings I made on my laptop are listenable (though the audio levels in the morning were too low). We probably don't want to post them publicly, just because they haven't been listened to. I provided them to Kushal Das, who was taking notes; if other attendees want them for reference, please let me know. --amk ___ 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] pootle.python.org is down
I came across http://bugs.python.org/issue13663, which is about a pootle.python.org installation. http://pootle.python.org/ currently returns a 500. Are we still using Pootle, or should I just close #13663? (Maybe the installation got broken in the move to OSL and then forgotten?) --amk ___ 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 3 marketing document?
On Fri, Jan 24, 2014 at 10:37:12AM -0600, Jesse Noller wrote: fwiw, I'm offering the keys/account/etc for getpython3.com to whomever has the time to keep it fresh and up to date. I'd be interested. --amk ___ 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] Is pygettext.py deprecated?
I was looking at http://bugs.python.org/issue1098749, which adds extraction of multiple-line strings to pygettext.py, but on the ticket Mark Lawrence suggested that pygettext should be deprecated. Is it deprecated? (It's not listed in PEP 4, but it isn't a module.) Debian wrote a man page for pygettext that starts with: pygettext is deprecated. The current version of xgettext supports many languages, including Python. GNU xgettext didn't understand any languages other than C at one time, so pygettext.py was written to handle Python code but not C code. But now xgettext will parse Python code. I assume xgettext's parsing is just using regexes, not an actual parse tree, so it may work equally well for Python 2.x and 3.x. Do we want to deprecate pygettext.py? If so, we should rewrite http://docs.python.org/3/library/gettext.html, which encourages people to use pygettext, and add it to PEP4. --amk ___ 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: #1097797: Add CP273 codec, and exercise it in the test suite
On Sun, Nov 10, 2013 at 06:48:30PM -0500, Terry Reedy wrote: +def encode(self,input,errors='strict'): +return codecs.charmap_encode(input,errors,encoding_table) You left out the spaces after the call commas (PEP8) Thanks for noting this. This file is programmatically generated by the scripts in Tools/unicode/ . Many of the files in this directory also have similar PEP8 violations: grep -r 'def encode' Lib/encodings/ |grep ',inpu' |less ... Lib/encodings//koi8_r.py:def encode(self,input,errors='strict'): Lib/encodings//koi8_u.py:def encode(self,input,errors='strict'): Lib/encodings//mac_arabic.py:def encode(self,input,errors='strict'): Lib/encodings//mac_centeuro.py:def encode(self,input,errors='strict'): So I'll take a look at fixing the code generator to generate properly formatted code, but it probably isn't worth modifying all of the existing files in Lib/encodings. --amk ___ 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: Fiddled Thread.join() to be a little simpler. Kinda ; -)
On Sat, Oct 26, 2013 at 05:34:05AM +0200, tim.peters wrote: Fiddled Thread.join() to be a little simpler. Kinda ;-) -# else it's a negative timeout - precise behavior isn't documented -# then, but historically .join() returned in this case +else: +# the behavior of a negative timeout isn't documented, but +# historically .join() has acted as if timeout=0 then I think the final 'then' on the new comment is an editing error. Unless perhaps you meant to write a further sentence of comment? --amk ___ 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 (3.3): PythonCAD is now on PyQt, use Wing as a prominent PyGtk example.
On Mon, Oct 07, 2013 at 12:13:18AM +0100, Michael Foord wrote: Wing is only a good example of PyGtk until Wing 5 is out of beta. They too have switched to PyQt... Perhaps Gramps is a good example: http://www.gramps-project.org/ I just glanced at their code and it's still using PyGtk. --amk ___ 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: [issue19151] Fix issue number in Misc/NEWS entry.
On Thu, Oct 03, 2013 at 08:48:47PM +0200, eric.snow wrote: -- Issue #19951: Fix docstring and use of _get_suppported_file_loaders() to +- Issue #19151: Fix docstring and use of _get_suppported_file_loaders() to ^^^ likely a typo? --amk ___ 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] Issue 4199: combining assignment with global nonlocal
Issue 4199 begins with a self-explanatory comment: PEP 3104 says that the nonlocal and global statements should allow a shorthand. (global x; x = 3 == global x = 3) This patch implements that. Benjamin posted his patch on 2008-10-24. It got postponed to 3.2 because it was too late for 3.1, and then to 3.3 because 3.2 still fell under the language moratorium, and then was forgotten for 3.3. Georg Brandl and Jeremy Hylton raised some issues with the patch and with the PEP's specification: http://bugs.python.org/issue4199#msg100015 We've gone five years in 3.x without supporting this statement form. Is it still worth implementing it for 3.4? Or should the issue simply be closed (and maybe a note added to the PEP that we didn't do this after all)? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python wiki
On Sun, Sep 26, 2010 at 03:53:58PM +0200, Georg Brandl wrote: * redirect from wiki.python.org to wiki.python.org/moin I've added a meta http-equiv element to the top page of wiki.python.org, so browsers will now jump to the /moin/ page immediately. This won't help crawlers that don't parse the HTML, but that probably doesn't matter. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marking os.system() as deprecated in the docs
The current text is: The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function. See the Replacing Older Functions with the subprocess Module section in the subprocess documentation for some helpful recipes. We could soften using that module is preferable to say may be, or just delete that whole clause completely. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Sun, Jul 11, 2010 at 05:22:28PM +0300, Tal Einat wrote: Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see Is it maybe time for another idle-fork project to develop IDLE outside the stdlib for a while, and then the forked version could be swallowed wholesale by the Python 3.2 release? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mailbox module - timings and functionality changes
On Tue, Jun 29, 2010 at 07:56:22AM -0700, Guido van Rossum wrote: Since you have such a great reproducible test case, could you point the profiler at it? (Perhaps on a reduced dataset... The profiler multiples your run time by some number between 2 and 10 IIRC.) Let me underline Guido's suggestion. Steve, I've done a lot of mailbox.py stuff and can look at your problem, but off the top of my head, my suspicion would be that I/O is the culprit, and a profile could confirm that. My thought is that mailbox.py is opening the file in some reading mode that ends up doing a lot more processing on Windows than on Unix because of universal newlines or something like that. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mailbox module - timings and functionality changes
On Tue, Jun 29, 2010 at 11:40:50AM -0400, Steve Holden wrote:
I will leave the profiler output to speak for itself, since I can find
nothing much to say about it except that there's a hell of a lot of
decoding going on inside mailbox.iterkeys().
The problem is actually in _generate_toc(), which is reading through
the entire file to figure out where all the 'From' lines that start
messages are located. TextIOWrapper()'s tell() method seems to be
very slow, so one help is to only call tell() when necessary; patch:
- svn diff Lib/
Index: Lib/mailbox.py
===
--- Lib/mailbox.py (revision 82346)
+++ Lib/mailbox.py (working copy)
@@ -775,13 +775,14 @@
starts, stops = [], []
self._file.seek(0)
while True:
-line_pos = self._file.tell()
line = self._file.readline()
if line.startswith('From '):
+line_pos = self._file.tell()
if len(stops) len(starts):
stops.append(line_pos - len(os.linesep))
starts.append(line_pos)
elif not line:
+line_pos = self._file.tell()
stops.append(line_pos)
break
self._toc = dict(enumerate(zip(starts, stops)))
But should mailboxes really be opened in a UTF-8 encoding, or should
they be treated as 7-bit text? I'll have to think about this.
--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] email package status in 3.X
On Sun, Jun 20, 2010 at 10:57:05AM -0700, Guido van Rossum wrote: Education is needed. When you search Google (or Bing, for that matter :-) for python unicode the first hit is http://www.amk.ca/python/howto/unicode, which is highly detailed but probably too much information for the typical person faced with a UnicodeError exception traceback (that page is also focused on Python 2). What we need is a cookbook on how to deal with various common Eep! That should be directed to http://docs.python.org/howto/unicode.html, the copy that's actually incorporated in the Python docs. I'll fix that immediately. Regarding a smaller document for people who hit a UnicodeError exception: could we write a little Unicode FAQ for python.org? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's New text on future maintenance
On Fri, May 07, 2010 at 09:30:00AM +0200, Martin v. Löwis wrote: I agree with Terry: how did you arrive at the 4 years for 2.x releases? Bug fixes releases stopped after the next feature release being made, which gave (counting between initial release and last bug fix release): I used the initial release date of 2.4 and 2.5 and the dates of the last patchlevel releases. That may well be distorted by the recent spasm of activity that led to 2.5.4. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's New text on future maintenance
On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
3.x). I'll take a stab at a more accurate rationale:
Thanks! I've applied the scalpel and reduced it to:
* A policy decision was made to silence warnings only of interest to
developers by default. :exc:`DeprecationWarning` and its
descendants are now ignored unless otherwise requested, preventing
users from seeing warnings triggered by an application. (Carried
out in :issue:`7319`.)
In previous releases, :exc:`DeprecationWarning` messages were
enabled by default, providing Python developers with a clear
indication of where their code may break in a future major version
of Python.
However, there are increasingly many users of Python-based
applications who are not directly involved in the development of
those applications. :exc:`DeprecationWarning` messages are
irrelevant to such users, making them worry about an application
that's actually working correctly and burdening the developers of
these applications with responding to these concerns.
You can re-enable display of :exc:`DeprecationWarning` messages by
running Python with the :option:`-Wdefault` (short form:
:option:`-Wd`) switch, or you can add
``warnings.simplefilter('default')`` to your code.
Benjamin suggested being very definite about a 5-year maintenance
period, but I don't want to write any checks our butt can't cash, so
I've left the text as Maintenance releases for Python 2.7 will
probably be made for 5 years. An alternative formulation might say
it will be maintained for the next two 3.x releases, not the next one
as usual.
I thought about Ben Finney's suggestion to not give a timespan and
describe the conditions for 2.x maintenance continuing, but those
conditions are complicated to describe -- if 3.x doesn't catch on? if
the 3.x transition is slow? if there's a significant 2.x user base
that remains? if someone starts a 2.x maintenance team? -- and might
be a confusing tangle of what-if statements.
--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] What's New text on future maintenance
FYI: I've just added the text below to the What's New document for
2.7. I wanted to describe how 2.7 will probably be maintained, but
didn't want to write anything that sounded like an iron-clad guarantee
of a maintenance timespan. Does this text seem like a reasonable set
of statements?
--amk
Python 2.7 is intended to be the last major release in the 2.x series.
Though more major releases have not been absolutely ruled out, the
Python maintainers are planning to focus their efforts on Python 3.x.
This means that 2.7 will remain in place for a long time, running
production systems that have not been ported to Python 3.x.
Two consequences of the long-term significance of 2.7 are:
* It's very likely the 2.7 release will have a longer period of
maintenance compared to earlier 2.x versions. Python 2.7 will
continue to be maintained while the transition to 3.x is in
progress, and that transition will itself be lengthy. Most 2.x
versions are maintained for about 4 years, from the first to the
last bugfix release; patchlevel releases for Python 2.7 will
probably be made for at least 6 years.
* Because 2.7 will be running production applications, a policy
decision was made to silence warnings only of interest to developers
by default. Silencing :exc:`DeprecationWarning` and its descendants
prevents users from seeing warnings triggered by an application.
(Carried out in :issue:`7319`.)
You can re-enable display of :exc:`DeprecationWarning` messages by
running Python with the :option:`-Wdefault` (short form:
:option:`-Wd`) switch, or you can add
``warnings.simplefilter('default')`` to your code.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do?triage.
On Wed, Apr 28, 2010 at 10:46:37AM +1000, Steven D'Aprano wrote: their ability to gain recognition for their merit. It's not enough to be good at what you do, people have to know it. Ten high-quality patches for high-profile bugs in a week may get you enhanced privileges, while thirty high-quality patches for low-profile bugs in six years might not, simply because nobody notices you. True. This makes me wonder if we should be data-mining the tracker information to look for significant contributors that no one has noticed. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone can do patch reviews (was: Enhanced tracker privileges...)
On Tue, Apr 27, 2010 at 02:40:19PM -, exar...@twistedmatrix.com wrote: This list would make a good addition to one of the cpython development pages. If potential contributors could find this information, then they'd be much more likely to participate by doing reviews. If anyone wants to write the updated text, the following command will make an anonymous read-only checkout of the /dev/ pages: svn ls https://svn.python.org/www/trunk/beta.python.org/build/data/dev I can apply a patch. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enhanced tracker privileges for dangerjim to do triage.
On Mon, Apr 26, 2010 at 02:25:33AM -, exar...@twistedmatrix.com wrote: I think there should be a page on python.org that says all contributors are welcome, and one way to become a contributor is to wrangle the issue tracker, and explains what this involves (I don't really have any idea, actually; I assume it's things like setting Actually there already is such a page: http://www.python.org/dev/contributing/ . Excerpt: If you have helped out in the issue tracker for a little while or have been a good participant on python-dev you may ask for Developer privileges on the tracker which allow you to change any and all metadata on an issue. Please don't be shy about asking for the privilege! We are more liberal with giving out this ability than with commit privileges, so you don't need to have been contributing for a year to gain this ability. And with Developer privileges you can work more autonomously and be an even greater help by narrowing down what issues on the tracker deserve the most attention at any one time. Issue workflow is specified in http://www.python.org/dev/workflow/. Suggestions for text improvements/changes are welcomed. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker reviews workflow and flags
On Fri, Mar 19, 2010 at 10:22:05AM -0400, R. David Murray wrote: Real world example with issue8151. It is an issue with a trivial patch in it. Everything what is needed is to dispatch it to stable `commit queue` and port to trunk. It is not 'easy' - it is 'trivial', but I have no means to mark it as 'easy' either, so even this trivial fix lies in tracker for three days waiting for review. Three days? That's nothing :) I think Anatoly has a point, though; there are issues where the people discussing the fix have come to a consensus, but none of them are committers, or the committers involved are too busy. There's a patch ready to apply, but no committer knows about it. To avoid issues involving C coding, try restricting your search to 'Library' issues. There is C code in some library modules, but less so than in the core ;). It would be nice if you could search on more than Actually Library should pretty much always be pure-Python. Issues related to C modules such as socket are classified under the 'Extension modules' component. Of course, sometimes the ultimate cause will migrate (a bug in SocketServer.py is traced to a flaw in socket, for example). --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improved Traceback Module
cgitb can also produce text tracebacks:
import cgitb
cgitb.enable(format='text')
import urllib
f=urllib.urlopen('bogus://foo')
type 'exceptions.IOError'
Python 2.7a1+: /home/amk/source/p/python/python
Thu Jan 28 11:35:04 2010
A problem occurred in a Python script. Here is the sequence of
function calls leading up to the error, in the order they occurred.
/home/amk/source/p/python/stdin in module()
/home/amk/source/p/python/Lib/urllib.py in urlopen(url='bogus://foo',
data=None, proxies=None)
85 opener = _urlopener
86 if data is None:
87 return opener.open(url)
88 else:
89 return opener.open(url, data)
opener = urllib.FancyURLopener instance at 0x840052c
opener.open = bound method FancyURLopener.open of urllib.FancyURLopener
instance at 0x840052c
url = 'bogus://foo'
lots more deleted
--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
On Wed, Jan 20, 2010 at 10:54:11PM -0800, Gregory P. Smith wrote: I think having a run time flag (or environment variable for those who like that) to disable the use of JIT at python3 execution time would be a good idea. Another approach could be to compile two binaries, 'python' which is smaller and doesn't contain the JIT, and jit-python, which is much larger and contains LLVM. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Static analysis of CPython using coccinelle/spatch
On Mon, Nov 16, 2009 at 03:27:53PM -0500, David Malcolm wrote: Has anyone else looked at using Coccinelle/spatch[1] on CPython source code? For an excellent explanation of Coccinelle, see http://lwn.net/Articles/315686/. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
On Sat, Nov 14, 2009 at 08:43:25AM +1100, Ben Finney wrote: There's also no option to vote that decisions on how to manage Python infrastructure (like PyPI) shouldn't be made by popular vote. If the open source approach of 'the maintainer decides' is followed, well, both the maintainer of the code and the admin of the site is Martin. Comments stay, then. If 'BDFL decides' is followed, GvR thinks the idea is reasonable (http://mail.python.org/pipermail/python-dev/2009-November/094058.html), though the implementation might be improved. Again, comments stay. If popular vote is ruled out, I don't see who else could possibly make the decision to disable comments and/or ratings. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FYI: LWN article on 2.x, 3.x, and the moratorium
FYI: I've written an article for Linux Weekly News on the moratorium related issues. The article is subscribers-only for a week, but here's a free link: http://lwn.net/SubscriberLink/361266/ef88bdbed5369800/ If you find this sort of thing useful/interesting, please consider subscribing to LWN. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
On Thu, Nov 12, 2009 at 11:30:27AM -0800, Guido van Rossum wrote: etc.). Maybe there should be a standard social app that you can just customize for a specific purpose. Sounds like an interesting project, actually. For comments, haloscan and disqus are third-party comment-hosting services; http://redalt.com/blog/comment-services has a longer list. I don't know if any of them support rating of the posts or objects being commented on (as opposed to rating other comments, which is supported by some of them). Or if any of them can delegate moderation to the module authors, as opposed to the PyPI admins. PyPI's REST-style URLs also work nicely as keys or RDF identifiers, so it would be straightforward to use them for identifying ratings or comment threads. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
On Fri, Nov 13, 2009 at 11:44:42AM +1100, Ben Finney wrote: There's a problem with the poll's placement: on the front page of the PyPI website. I've posted a tweet to the ThePSF account about the poll. If the poll runs for a week or two, that would provide time for word of the poll to propagate through Twitter, blogs, etc. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3003 - Python Language Moratorium
On Sun, Nov 08, 2009 at 10:27:46PM +0100, Georg Brandl wrote: Good point, I'll make that change if AMK agrees. It's certainly fine with me. Do we want to only make that change to the 2.7 What's New, or should we also do it for the 2.6 one? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it
On Fri, Oct 30, 2009 at 09:37:36PM +0100, Georg Brandl wrote: I don't like this. It gives a set object a hidden state, something that AFAICS no other builtin has. Iterating over an iterable is what iterators are for. It also makes the object thread-unsafe; there's no way for two threads to iterate over it at the same time. It's a terrible idea to introduce new things that won't work under threaded usage. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Volunteer needed to organize summits
I'd like to turn over the organization of the VM and Python Language Summits at PyCon 2010 to someone else, one or two people. (The same person doesn't need to organize both of them.) Why: in November PyCon will be three months away, so the guest list needs to be finalized and the invitations need to be sent. Yet I can't pull together the motivation to work on them; I contemplate the task for two minutes and then go do something else. It's obviously better if the summit tasks are being actively worked on instead of just drifting, so I want to give it up now. What's required: chiefly it's just a matter of sending and replying to e-mail. Draw up a guest list (I can provide last year's lists); think of new people projects to be added, or e-mail someone to ask for suggestions; send out invitations and requests for agenda items; collect the responses so we know how many people are coming. You can also help moderate the summits on the day of the events, but if that's not feasible someone else could do it, or the groups could manage themselves. (Also sent to pycon-organizers, psf-members.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Thu, Sep 17, 2009 at 10:59:22AM -0700, Peter Moody wrote: currently have, or do you feel that simply adding 5 rfc's to the references section adds to the overall readability of the PEP? I would list them simply because it's not obvious which RFC specifies the format of IP addresses or how they're allocated. e.g. if I search for rfc ip address format, most of the hits are for RFC 3587, IPv6 Global Unicast Address Format, which doesn't actually explain IPv6 address syntax. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misc/maintainers.rst
On Thu, Sep 17, 2009 at 07:38:50PM +0200, Georg Brandl wrote: So the plan would be to consolidate these into another set of rst docs, having them in the repo, editable by every committer, as well as published somewhere on python.org (devdocs.python.org or somesuch). +1. Should we do something similar with the FAQs at http://www.python.org/doc/faq/ ? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misc/maintainers.rst
On Thu, Sep 17, 2009 at 11:32:25PM +0200, Georg Brandl wrote: Should we do something similar with the FAQs at http://www.python.org/doc/faq/ ? They would then go into the main docs, I guess? That would make sense. However, we already have seven different FAQs there, so I don't think they should all be added as peers of the Tutorial, Library Reference, etc. Maybe there should be a single 'FAQ' document, with the existing faqs as subsections. Another option might be to put them on an entirely new site such as faq.python.org, and then configure www.python.org/doc/faq/ to proxy for it. Should I look at implementing the python.org as an output style for Sphinx? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Language Summit #2 in February
PyCon 2010 will be February 19-21 2010 in Atlanta, Georgia (US). Van Lindberg, PyCon chair, has approved having another Python Language Summit on Thursday, February 18 2010. The web page for it is http://us.pycon.org/2010/about/summits/language/ The Python Language Summit is an invitation-only event for developers of Python implementations and the standard library, to discuss issues of common concern to all implementors. It will mostly be organized similarly to last year's event. I'm going to drop the initial open discussion, which wasn't very useful, and we'll just have three 1.5-hour discussion sessions. The fourth time slot will be left open for chatting, development, or whatever the attendees want to do. We therefore need to decide what those three sessions should be about. Please discuss on python-dev and hopefully we can arrive at some consensus on topics of reasonably wide current interest. (See http://us.pycon.org/2009/about/summits/language/ for a reminder of last year's topics.) Feel free to raise discussions on other lists such as jython-dev, catalog-sig, or wherever, but please summarize the results here on python-dev; I won't see discussions on other lists. Like last time, invitations will be sent to the committers for Python, Jython, IronPython, PyPy, Pynie, plus a few extra people and projects. If you want to suggest another project or person who should be invited, please send me a private e-mail. Andrew M. Kuchling a...@amk.ca ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] www/svn python.org status update
The following sites are up again on a new machine, but cannot be updated through SVN hooks or whatever mechanism: www.python.org docs.python.org www.jython.org planet.python.org planet.jython.org svn.python.org was deliberately not brought up again. The backups were a few hours behind and missing the ~10 most recent commits. Not disastrous, but it could probably mess up people's SVN trees, so after some IRC discussion, the decision was to wait until the original disks are available again. That will probably not occur until Monday, maybe Tuesday. I've disabled donations to the PSF through credit cards, which pointed to a CGI script that doesn't currently work; PayPal donations still work. Do we want to make any edits to the 3.1 or 3.0 pages about the I/O bug? I can do that manually if someone will provide the text and/or a patch to put up. Unfortunately without SVN we probably can't cut a new 3.1 release, unless Benjamin or someone has a really up-to-date copy of the Mercurial tree and wants to work from that. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] www, svn.python.org down
Both www.python.org and svn.python.org are down. They're hosted on the same machine, and it seems to have run into disk problems and hasn't rebooted even after power-cycling. Thomas Wouters will be visiting the machine physically tomorrow to try to diagnose the problem. (The machine also hosts planet.python.org and hg.python.org.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: pruning/reorganizing branches
On Mon, Aug 03, 2009 at 12:51:36PM +0200, Dirkjan Ochtman wrote: amk-mailbox: keep-clone? strip -- this branch was for working on a fix for http://bugs.python.org/issue1599254, but the actual work in the branch is available as the patches attached to that item. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Wave as a developer communication tool
On Thu, Jun 04, 2009 at 01:15:16PM -0400, Terry Reedy wrote: marked as having new content. At your leisure, you open it (or perhaps you have marked it 'download updates in background'). That that takes longer with a slow connection is no different than with other text streams. If you type in a comment, even 1200 baud upsteam is fast enough. Where do you get 'punitive' in this? I visited my parents at Christmas. They live in a rural area, don't have great phone lines, and my dad's computer ends up getting about a 21Kb modem connection (not even 38.4!). I discovered that great swaths of the Web 2.0 world were effectively unusable for me; after login, the Twitter home page took 3 minutes to display. Logging into my bank was a tortuous 10 minute process. I never succeeded in getting into Facebook at all. Many pages don't render until they're completely downloaded. The little AJAXy update that adds an extra second or two on a fast connection becomes shockingly painful on a slow connection. The JS files are organized Unless Google Wave is written with attention to such slow connections (which I doubt -- such users are pretty rare, after all), I would assume it will be unusable. The bandwidth is enough for a character by character stream, but web browser apps impose many overheads atop that stream. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote: Please see the large number of Zope and PEAK distributions on PyPI as minimal examples that disprove this being the common use case. I expect you will find a fair number of others, as well. ... In other words, the base package scenario is the exception these days, not the rule. I actually know specifically of only one other such package besides your mx.* case, the logilab ll.* package. Isn't that pretty even, then? zope.* and PEAK are two examples of one approach; and mx.* and ll.* are two examples that use the base package approach. Neither approach seems to be the more common one, and both are pretty rare. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] wait time [was: Ext4 data loss]
On Thu, Mar 12, 2009 at 08:25:59PM +, Antoine Pitrou wrote: However, I also think that any parameter to flush() or close() is a bad idea, since it can't be used when flushing and closing is implicit. For example when the file is used in a with statement. I think the existing os.fsync() and O_SYNC functionality is fine for new applications and packages to write data securely or not. We should just consider whether the stdlib APIs don't make it impossible to write data securely, e.g. dumbdbm's internal file object, and if so, is it worth fixing? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Regexp 2.7
On Tue, Mar 10, 2009 at 11:32:10AM -0700, Guido van Rossum wrote: Hm, what's wrong with the existing set of regex test cases? This is one of the most complete set of test cases in our test suite. There's never anything wrong with having more test cases! However, if you have a choice of which test suite to improve, I would choose another module to work on. The re module was once based on PCRE and a lot of its test suite was ported into the Python one, so there may not much relevant to add. But please do whatever you like... --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ext4 data loss
On Tue, Mar 10, 2009 at 09:11:38PM +0100, Christian Heimes wrote: Python's file type doesn't use fsync() and be the victim of the very same issue, too. Should we do anything about it? The mailbox module tries to be careful and always fsync() before closing files, because mail messages are pretty important. The various *dbm modules mostly have .sync() method. dumbdbm.py doesn't call fsync(), AFAICT; _commit() writes stuff and closes the file, but doesn't call fsync(). sqlite3 doesn't have a sync() or flush() call. Does SQLite handle this itself? The tarfile, zipfile, and gzip/bzip2 classes don't seem to use fsync() at all, either implicitly or by having methods for calling them. Should they? What about cookielib.CookieJar? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ext4 data loss
On Wed, Mar 11, 2009 at 11:31:52AM +1100, Cameron Simpson wrote: On 10Mar2009 18:09, A.M. Kuchling a...@amk.ca wrote: | The mailbox module tries to be careful and always fsync() before | closing files, because mail messages are pretty important. Can it be turned off? I hadn't realised this. No, there's no way to turn it off (well, you could delete 'fsync' from the os module). | The tarfile, zipfile, and gzip/bzip2 classes don't seem to use fsync() | at all, either implicitly or by having methods for calling them. | Should they? What about cookielib.CookieJar? I think they should not do this implicitly. By all means let a user issue policy. The problem is that in some cases the user can't issue policy. For example, look at dumbdbm._commit(). It renames a file to a backup, opens a new file object, writes to it, and closes it. A caller can't fsync() because the file object is created, used, and closed internally. With zipfile, you could at least access the .fp attribute to sync it (though is the .fp documented as part of the interface?). In other words, do we need to ensure that all the relevant library modules expose an interface to allow requesting a sync, or getting the file descriptor in order to sync it? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Googlebot and the mail.python.org python-dev?archive
On Sat, Feb 28, 2009 at 10:37:09AM +, Antoine Pitrou wrote: have the following HTML tag in them: META NAME=robots CONTENT=noindex,follow which explicitly instructs Web spiders *not* to index contents nor follow links. I believe this makes spiders not index this page, but does follow links. Individual messages have index,nofollow. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Googlebot and the mail.python.org python-dev archive
On Sat, Feb 28, 2009 at 09:53:10PM +1000, Nick Coghlan wrote: Is pydotorg-www still the place for website questions?* If so, I should probably take this over there... Just 'pydotorg' is the current list (http://mail.python.org/mailman/listinfo/pydotorg). Looking at the access logs, mail.python.org is being actively crawled: 66.249.71.119 - - [28/Feb/2009:18:32:51 +0100] GET /pipermail/python-list/2004-June/265194.html HTTP/1.1 304 - - Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 72.30.79.38 - - [28/Feb/2009:18:32:51 +0100] GET /pipermail/csv/2003-February/000368.html HTTP/1.0 200 3929 - Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 65.55.211.30 - - [28/Feb/2009:18:32:51 +0100] GET /pipermail/python-list/2006-May/382528.html HTTP/1.1 200 4028 - msnbot/1.1 (+http://search.msn.com/msnbot.htm) Is it maybe that the site is just too large, so the search engines index only 10,000 messages from it? One possible solution might be to block crawling of the python-list archive; it's enormous, and already available through Google's Usenet search. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding support to curses library
On Wed, Feb 25, 2009 at 01:52:29PM -0800, st...@integrityintegrators.net wrote: Are you up for helping a little more? Sure, but please open an issue on http://bugs.python.org for this; back-and-forth over a particular patch is done in the bug tracker, not the python-dev mailing list. http://www.python.org/dev/ discusses how development is done. We also don't send around modified copies of entire files; http://www.python.org/dev/faq/#patches discusses how to make patches. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding support to curses library
On Wed, Feb 25, 2009 at 06:30:06AM -0800, Heracles wrote: is commented back in it does fail. I am not sure exactly how a debugger will help in this case since the color_set call goes directly to the ncurses library. If in fact that the issue is the ncurses library then it seems that there is no feasible solution until that library is fixed, in which case this patch is sort of useless. ... erg = color_set(color_pair_number, NULL); // Debating on forcing null What is color_pair_number in the C code? If it's some incorrect value (-1? 255?), maybe ncurses is indexing off an array and crashing. This is why a debugger might help; you could run the test program until the crash and then print out the values of the relevant variables. e.g. is stdscr set to a non-NULL value? There might be a debugging version of ncurses that will let you look at the variables inside the ncurses code, which may make the problem clear. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Greg Ward email
On Mon, Feb 23, 2009 at 02:16:17PM +0100, Tarek Ziadé wrote: I am trying to reach Greg Ward to get a maintainer access to Distutils at PyPI, but his email address at python.net (and some other) doesn't work anymore. Greg's website at www.gerg.ca (not a typo!) has e-mail addresses. However, the package index entry at http://pypi.python.org/pypi/Distutils/1.0 lists Greg as the author, but it's not actually owned by him; it looks like some random person registered it. So we should probably just reassign the package to Tarek. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Daily documentation builds
On Tue, Feb 10, 2009 at 09:16:48PM -0800, Neal Norwitz wrote: I ran 2.6, 3.0, and 3.1 manually. 2.7 should get picked up on the next run. The problem is that regrtest.py -R hangs from time to time which caused the machine to run out of memory. Does anyone else have regrtest.py -R hang for them? Some tests were disabled to try to prevent the problem, but it still happens from time to time. It's also possible that tools/sphinx needs a manual 'svn update'. A recent change to sphinxext/pyspecific.py imports a new package, sphinx.builders. I had to do this to keep my source tree building the docs. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mark old distutils as deprecated
On Sun, Feb 08, 2009 at 11:15:46AM +0100, Tarek Ziadé wrote: To avoid confusion, as suggested by Akira who works on cleaning the Distutils pages on the python.org website, I would like to move http://svn.python.org/view/distutils/trunk into a branch and add a README.txt in an empty trunk to explain the current status of the package. That seems fine to me. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Holding a Python Language Summit at PyCon
On Sat, Dec 06, 2008 at 02:42:38PM -0800, Brett Cannon wrote: No, I am saying I had told AMK I was interested in championing the session. He chose you, and that's that. One less thing for me to worry about. =) Brett, I actually think you'd be a good champion for the 11AM transition-planning session. As a reminder, the topics came up with were: Transition plan for rest of 2.x series; goals for 2.7/3.1. - New features future plans? - Is 2.7 last of the 2.x releases? - Unicode issues - Stdlib plans? (Possibly this is too much material for one session, and something will have to be pruned.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Fri, Dec 05, 2008 at 05:40:46AM -, [EMAIL PROTECTED] wrote: For most users, especially new users who have yet to be impressed with Python's power, 2.x is much better. It's not like library support is one small check-box on the language's feature sheet: most of the attractive things about Python are libraries. Of course I am not free Here I agree, sort of. Newbies may not understand what they're giving up in terms of libraries. (The 'sort of' is because, having learned 3.0, learning the changes for 2.6 is certainly much easier than learning a first programming language is.) The third (albeit much less likely) option is that you're learning Python to learn to interact with a system that's scriptable in embedded Python, like Blender or Gimp. I don't think there's a single system of that variety which uses 3.0 yet, and these will likely be even slower to move than libraries. Let me note that if some application embeds Python for a specialized purpose, where the only modules imported are either user-written or part of the application, it seems much *easier* to move to Python 3 because the scripts don't use arbitrary third-party libraries. Python embedded in an e-mail MTA might use libraries for DNS or file I/O or databases and has to be cautious about versions; Python in Gimp probably doesn't, in practice. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Wed, Dec 03, 2008 at 08:51:33PM -0500, Barry Warsaw wrote: On behalf of the Python development team and the Python community, I am happy to announce the release of Python 3.0 final. Yay! We are confident that Python 3.0 is of the same high quality as our previous releases, such as the recently announced Python 2.6. We will continue to support and develop both Python 3 and Python 2 for the foreseeable future, and you can safely choose either version (or both) to use in your projects. Which you choose depends on your own needs and the availability of third-party packages that you depend on. Some other things to consider: I think we should also have a statement upon on python.org about future plans: e.g. * that there will be a Python 2.7 that will incorporate what we learn from people trying to port, * that 3.1 will rearrange the standard library in mostly-known ways, and * that we expect people to use 3.0 mostly for compatibility testing, not going into serious production use until 3.1 or maybe even 3.2. (The details are open to discussion, of course.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Holding a Python Language Summit at PyCon
On Thu, Dec 04, 2008 at 03:05:51PM -0500, Frank Wierzbicki wrote: Cross-implementation issues: I would like to champion this one. Thanks! You're now listed as the champion for it. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Thu, Dec 04, 2008 at 08:20:34PM +, Paul Moore wrote: Hmm, looking back, the quote Raymond is referring to is just a suggestion for additional text on the 3.0 page. I agree with him that it's a bit too negative. Actually I want it to be an entirely separate page so that we can point people to it. has really come across yet - in spite of the warnings being all about compatibility issues, no-one has stressed the simple point that if your code is new, it doesn't have compatibility concerns! Well, at least not until you decide you need some particular external library that hasn't been ported to 3.0 yet. For example, if you go to discussion threads such as http://www.reddit.com/r/programming/comments/7h7d7/python_3000_is_ready/, you can see people making statements like I've been holding off learning it until 3000 went gold. But I think starting with Python 3.0 is a bad idea for a newbie, because they'll be limited in what they can do until the libraries have been ported. They can do some tasks (command-line tools, Fibonacci functions, Tk GUIs), but can they use the fancy new web framework they've just read about? Write a game? Draw graphs with matplotlib? Use and extend an application such as Roundup? Bzzt, no, not yet! Starting with 3.0 is starting out on an island. While I expect the island will grow in territory over time, I'm worried that new learners will automatically go for the highest version number, find their available tools are highly restricted, and get frustrated. Perhaps the statement could say something like we do not expect most Python packages will be ported to the 3.x series until around the time 3.1 is released in X months. (where X=12? 6?) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0 final
On Thu, Dec 04, 2008 at 05:29:31PM -0800, Raymond Hettinger wrote: Here's a bright idea. On the 3.0 release page, include a box listing which major third-party apps have been converted. Update it once every couple of weeks. That way, we're not explicitly That's an excellent idea. We could have a webpage, or start a topic-specific weblog for posting announcements. I've started a draft of a 3.0 FAQ in the wiki at http://wiki.python.org/moin/Python3000/FAQ. Once it's finished we can move it into the 3.0 release pages. Everyone please edit and improve it! --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My patches
On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. True, your code will still not be able to land in the official branch without core developer intervention, but you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. (What a DVCS might enable is making it easier to do larger experiments, like the recent Vmgen work, and publish them in a form that people can download. We could create SVN branches now, but that means people would then have commit access to all of the Python source.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My patches
On Thu, Oct 30, 2008 at 03:55:38PM +, Paul Moore wrote: 2. Some patches marked as documentation are doc fixes, others seem to be issues where it has been decided that the behaviour is correct as is, but needs to be documented. Fair enough, but it's much harder to assess the latter, and there's no way of just grabbing the former (for example, to spend a spare 30 minutes reviewing simple stuff). Perhaps the documentation category could be split into 'Documentation' and 'Documentation Needed'; the latter means the issue entails writing new text as opposed to rewriting. But I think on average documentation issues get processed pretty quickly: Georg is responsive to them, and patches are easy to apply because you don't need to worry about breaking anything. In general Python development is much less freewheeling and fun than it used to be. You could come up with new features and modules, add lots of new capabilities to a module. Today we're making much smaller changes, discuss them at far great length, and have to worry about breaking all the existing Python code out there, It's a sign of Python's maturity, of course, and I'm not saying that the design effort and the compatibility requirements should be dropped, but they certainly act as a damper. On some of my issues (esp. ones relating to curses and mailbox.py), I feel paralyzed because problems are occurring on platforms I don't have access to (e.g. FreeBSD). The buildbots will report problems, but then you have to debug them by committing changes, triggering a build, and observing the results. And all of these actions will send e-mail to python-checkins. (Imagine if every 'print reached here!' you added while debugging was e-mailed to everyone...) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Has python-dev collapsed?
On Wed, Oct 29, 2008 at 12:26:48AM +0100, Christian Heimes wrote: Maybe we should select an assistant release manager for the next releases. It's lots of work to handle two releases at the same time. A Will 3.1 and 2.7 also be parallel releases? (I ask, not having read the 3xxx PEPS at all.) If yes, why? While I can see a case for 2.6/3.0 being in sync -- new features in 2.6 ease the transition to 3.0 -- I'd imagine that 3.1 would be better with a shorter cycle (6-9 months) because there are more possible rough edges to clean up. 3.1 would likely include bugfixes from the eventual 2.7, so 3.1 might also trigger 2.6.1, but I don't think there's any harm if 3.1 contains features or incompatible fixes that are unavailable to 2.x users. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN] VPython 0.1
On Sat, Oct 25, 2008 at 04:33:23PM +1300, Greg Ewing wrote: Maybe not, but at least you can follow what it's doing just by knowing C. Introducing vmgen would introduce another layer for the reader to learn about. A stray thought: does using a generator for the VM make life easier for the Stackless Python developers in any way? Does it make it possible for stock CPython to become stackless? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN] VPython 0.1
On Thu, Oct 23, 2008 at 01:31:48AM -0600, Adam Olsen wrote: To clarify: This is *NOT* actually a form of threading, is it? It merely breaks the giant dispatch table into a series of small ones, while also grouping instructions into larger superinstructions? OS threads are not touched at any point? I haven't looked at Vmgen or VPython at all, but that's probably correct. From: http://foldoc.org/foldoc.cgi?query=threaded+code threaded code: A technique for implementing virtual machine interpreters, introduced by J.R. Bell in 1973, where each op-code in the virtual machine instruction set is the address of some (lower level) code to perform the required operation. This kind of virtual machine can be implemented efficiently in machine code on most processors by simply performing an indirect jump to the address which is the next instruction. Many Forth implementations use threaded code and nowadays some use the term threading for almost any technique used to implement Forth's virtual machine. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c
On Fri, Oct 10, 2008 at 08:44:38AM +0200, Martin v. Löwis wrote: So 2.6.0 will contain a lot of tests that have never been tested in a wide variety of systems. Some are incorrect, and get fixed in 2.6.1, and stay fixed afterwards. This is completely different from somebody introducing a new test in 2.6.4. It means that there are more failures in a maintenance release, not less as in the first case. Indeed. Looking at the commit logs, I had to split out all the test-only commits into a separate list, and tests often took several attempts to get working on all platforms. I think backporting should be prioritized into 1) bug fixes, 2) documentation improvements, 3) tests. For 2.5.3, we should just ignore 2) and 3); documentation patches will require rewriting from reST into LaTeX, which is too much effort for the return, and tests are even less useful to the end users, being primarily useful for Python's developers. (2.5.3 reminder: there are lists of commits in sandbox/py2.5.3 to be considered. I've seen no reactions on python-dev or modifications to those files, so I don't think anyone else is looking at them. Is everyone waiting for the weekend, maybe?) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion access down?
On Thu, Oct 09, 2008 at 10:50:24AM +0200, Ulrich Eckhardt wrote: Is it only me or does it fail for other people, too? I'm getting | Server sent unexpected return value (503 Service | Unavailable) in response to OPTIONS request | for 'http://svn.python.org/projects/python/trunk' svn.python.org is working again now. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Subversion access down?
On Thu, Oct 09, 2008 at 10:50:24AM +0200, Ulrich Eckhardt wrote: Is it only me or does it fail for other people, too? I'm getting | Server sent unexpected return value (503 Service | Unavailable) in response to OPTIONS request | for 'http://svn.python.org/projects/python/trunk' python.org seems to be having some network weirdness right now. I'm looking into it. (SVN access over SSH seems to be fine.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Distutils/packaging sprint this weekend
Tarek Zidae' is organizing a sprint on general distutils/setuptools/packaging this weekend. Physically it's in Arlington VA, but participants will be hanging out in #distutils on freenode's IRC. More information at http://www.openplans.org/projects/plone-conference-2008-dc/distribute. --amIf you're in Fairfax County and need a lift, let me knowk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.3: assessing commits
On Tue, Oct 07, 2008 at 08:44:09PM -0400, A.M. Kuchling wrote: At this point I still have 1191 files left. Many of these commits are still irrelevant, but this is a lot for me to look through. A tarball with the remaining commits is at http://www.amk.ca/files/python/2.6-changes.tgz On the metro this morning, I worked on this some more and now have only 858 files for consideration. At this point I think we have to look at commits individually. I'll turn the lists of commits into a set of wiki page that we can examine and edit down in parallel. (I've updated the above tarball in the meantime.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.3: assessing commits
On Wed, Oct 08, 2008 at 08:06:09AM -0400, A.M. Kuchling wrote: look at commits individually. I'll turn the lists of commits into a set of wiki pages that we can examine and edit down in parallel. I decided to put them in SVN instead, in sandbox/py2.5.3/ . How do we want to assess these commits for possible inclusion in 2.5.3? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.3: call for patches
On Tue, Oct 07, 2008 at 09:27:24AM +0200, Martin v. Löwis wrote: Within a few weeks, we will release Python 2.5.3. This will be the last bug fix release of Python 2.5, afterwards, future releases of 2.5 will only include security fixes, and no binaries (for Windows or OSX) will be provided anymore (from python.org). I'm going to the library this evening, and can make my task looking through the 2.5-2.6 log for candidates. I won't do anything in Roundup just yet, but I'll put the list in the wiki or post it here, and then we can cut the list down further before creating any new issues (or re-opening old ones) in Roundup. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5.3: assessing commits
I've begun the task of assessing the 2.6 commits, but the job is unexpectedly large. What I did: * Took the output of 'svn log -r60999:66717'. (2.5.2 was branched from rev. 60999, so I'm ignoring commits to the trunk before 2.5.2 was branch, which may miss some things.) * Wrote a little script to explode the log into a separate file for each commit. This resulted in about 2200 files. * Did a long series of 'grep' and 'rm' commands to remove irrelevant files. For example, if the commit touches abc.py, bytesobject.c, bytearrayobject.c, etc. it was removed. * Wrote a little script to find commits that only touch the docs, and moved them aside. At this point I still have 1191 files left. Many of these commits are still irrelevant, but this is a lot for me to look through. A tarball with the remaining commits is at http://www.amk.ca/files/python/2.6-changes.tgz Can we parallelize the job? One person could take commits starting with '01', another with '02', etc. Or each person could assess the commits they made. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of 2.5
On Mon, Oct 06, 2008 at 12:53:01PM -0700, Raymond Hettinger wrote: The 2.6/3.0 development process was so disruptive that I doubt that 2.5 received adequate attention for bug fixes. Why not wait two or three months for the dust to settle? Can you please clarify your meaning? Do you mean that * we haven't been backporting fixes to 2.5? * we should wait to see if any horrible problems are reported in 2.6? * we need to look at the logs for commits that should be applied to 2.5? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
On Sat, Oct 04, 2008 at 09:45:27AM +0200, Georg Brandl wrote: Barry Warsaw schrieb: two problems: The libraries they depend on aren't ported, and the KLOC of code they care about are hard and tedious work to port, not to mention that it typically isn't viewed as productive work by those who pay them. PyPI should also be enhanced to indicate which libraries are 3.x-compatible, to make it easier for 3.x users to find packages they can use. This may be more complicated than it sounds, because you'd probably add a very general requirement-indicating feature to PyPI, not merely a 'supports 3.0' Boolean on each record, and requirements are actually pretty complicated: alternative packages, specific version numbers... --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python-checkins seems broken
On Sat, Oct 04, 2008 at 12:14:43AM +0200, Amaury Forgeot d'Arc wrote: Do other subscribed people receive these commit messages? Is there a problem with the mailer, or some SVN trigger? It looks like mail from dinsdale.python.org to mail.python.org isn't working due to a DNS issue: rcpt to: [EMAIL PROTECTED] 550 5.7.1 Client host rejected: cannot find your reverse hostname, [82.94.164.164] data I know there's a transition to new IP addresses going on for the python.org machines, but Thomas or Sean probably needs to do something with the DNS for this. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.6 rc1 performance results
Three weeks ago, Antoine Pitrou posted the pybench results for 2.6 trunk: http://mail.python.org/pipermail/python-dev/2008-August/081951.html The big discovery in those results were TryExcept being 48% slower, but there was a patch in the bug tracker to improve things. I've re-run the tests to check the results. Disclaimer: these results are probably not directly comparable. Antoine was using a 32-bit Linux installation on an Athlon 3600+ X2; I'm on a Macbook. Good news: TryExcept is now only 10% slower than 2.5, not 48%. Bad news: the big slowdowns are: CompareFloats: 117ms98ms +19.2% 118ms99ms +19.0% CompareIntegers: 110ms 104ms +5.6% 110ms 105ms +4.9% DictWithStringKeys: 118ms 105ms +12.8% 133ms 108ms +22.7% NestedForLoops: 125ms 116ms +7.7% 127ms 118ms +8.0% Recursion: 193ms 159ms +21.5% 197ms 163ms +20.8% SecondImport: 139ms 129ms +8.4% 143ms 130ms +9.9% SecondPackageImport: 150ms 139ms +8.6% 152ms 140ms +8.1% SecondSubmoduleImport: 211ms 191ms +10.5% 214ms 195ms +9.4% SimpleComplexArithmetic: 130ms 119ms +9.4% 131ms 120ms +9.2% Antoine, your Recursion results were actually about the same (+2.2%) from 2.5 to 2.6, so this big slowdown is novel. I wonder if these tests are simply slower on MacOS for some reason (compiler, CPU cache size, etc.). Does anyone see similar results? Any idea what might have made DictForStringKeys and Recursion slow down? Complete results: Test minimum run-timeaverage run-time thisother diffthisother diff --- BuiltinFunctionCalls: 140ms 148ms -5.4% 142ms 153ms -7.5% BuiltinMethodLookup: 120ms 135ms -11.2% 122ms 137ms -11.0% CompareFloats: 117ms98ms +19.2% 118ms99ms +19.0% CompareFloatsIntegers: 109ms 119ms -8.9% 109ms 121ms -9.3% CompareIntegers: 110ms 104ms +5.6% 110ms 105ms +4.9% CompareInternedStrings: 128ms 153ms -16.3% 131ms 158ms -16.8% CompareLongs: 102ms99ms +3.5% 105ms 101ms +3.9% CompareStrings: 164ms 161ms +2.0% 166ms 165ms +0.7% CompareUnicode: 141ms 158ms -10.5% 143ms 164ms -12.6% ComplexPythonFunctionCalls: 159ms 272ms -41.3% 164ms 277ms -40.6% ConcatStrings: 173ms 168ms +3.2% 177ms 172ms +3.1% ConcatUnicode: 108ms 121ms -10.8% 111ms 124ms -10.4% CreateInstances: 168ms 180ms -6.4% 176ms 182ms -3.7% CreateNewInstances: 129ms 153ms -15.6% 132ms 158ms -16.0% CreateStringsWithConcat: 156ms 157ms -0.7% 158ms 161ms -1.9% CreateUnicodeWithConcat: 112ms 114ms -1.8% 114ms 117ms -2.2% DictCreation: 104ms 112ms -7.1% 106ms 114ms -7.2% DictWithFloatKeys: 149ms 162ms -7.7% 153ms 168ms -8.7% DictWithIntegerKeys: 123ms 148ms -16.8% 127ms 151ms -15.9% DictWithStringKeys: 118ms 105ms +12.8% 133ms 108ms +22.7% ForLoops:91ms88ms +3.6%91ms88ms +3.0% IfThenElse: 108ms 102ms +5.2% 109ms 103ms +5.5% ListSlicing: 155ms 239ms -35.0% 157ms 241ms -34.6% NestedForLoops: 125ms 116ms +7.7% 127ms 118ms +8.0% NormalClassAttribute: 135ms 140ms -3.8% 139ms 146ms -4.7% NormalInstanceAttribute: 123ms 126ms -2.4% 125ms 130ms -4.4% PythonFunctionCalls: 126ms 126ms +0.0% 129ms 128ms +0.9% PythonMethodCalls: 165ms 165ms -0.1% 168ms 170ms -1.1% Recursion: 193ms 159ms +21.5% 197ms 163ms +20.8% SecondImport: 139ms 129ms +8.4% 143ms 130ms +9.9% SecondPackageImport: 150ms 139ms +8.6% 152ms 140ms +8.1% SecondSubmoduleImport: 211ms 191ms +10.5% 214ms 195ms +9.4% SimpleComplexArithmetic: 130ms 119ms +9.4% 131ms 120ms +9.2% SimpleDictManipulation: 124ms 146ms -14.6% 128ms 150ms -14.8% SimpleFloatArithmetic: 127ms 132ms -3.6% 131ms 144ms -9.3% SimpleIntFloatArithmetic:93ms 100ms -6.5%94ms 100ms -5.6% SimpleIntegerArithmetic:94ms91ms +2.8%95ms92ms +3.1% SimpleListManipulation: 108ms 110ms -1.1% 110ms 111ms -1.2% SimpleLongArithmetic: 141ms 136ms +3.8% 143ms 139ms +2.8%
Re: [Python-Dev] Not releasing rc1 tonight
On Sun, Sep 07, 2008 at 12:02:06PM -0400, Barry Warsaw wrote: There are 8 open release blockers, a few of which have patches that need review. So I think we are still not ready to release rc1. But it worries me because I think this is going to push the final release beyond our October 1st goal. Should we try to schedule a bug evening some time this week? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)
On Thu, Sep 04, 2008 at 09:25:43AM -0700, Bill Janssen wrote: Yeah, but bsddb is one of those exploding batteries. I've used it for years, and have had lots and lots of problems with it. Having SQLite in there is great; now we need implementations of anydbm and shelve which use it. What sort of problems? When I've used BerkleyDB in the past, it always took a fair bit of experimenting searching to figure out the right combination of flags to use (and the BerkeleyDB docs were very low-level), but once that was done it seemed to work OK. Incorporating Jesus's docs will help users with that issue; I'm willing to work on that before 2.6final. I think the primary annoyance is the instability of the bsddb tests, and the resulting bad effect on buildbot's usefulness (as we all just get accustomed to having a patchwork of red randomly mixed in). So why not just strip down the test cases we run to avoid the problematic tests? That won't help Jesus debug on platforms he can't access, but we could re-enable those tests after 2.7 or provide a different buildbot target that runs the entire suite. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On Fri, Aug 22, 2008 at 07:59:46AM -0700, Guido van Rossum wrote: That's up to us. I don't know what the reason was for keeping the 3.2.0 database around -- does anyone here recall ever using it? For what? RFC 3491, one of the internationalized domain name RFCs, explicitly requires Unicode 3.2.0, so Lib/stringprep.py needs to use the old database and we have to keep 3.2.0 available. Maybe no specs depend on 4.1.0, so it could simply be replaced by 5.1.0. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for the email addresses of some committers
On Thu, Jul 31, 2008 at 07:20:15PM -0700, Brett Cannon wrote: * Jackilyn Hoxworth She was a Google SoC person in 2006; since she hasn't done anything subsequently, her commit privs can be revoked. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fuzzing bugs: most bugs are closed
On Sun, Jul 20, 2008 at 10:45:39PM +0200, Victor Stinner wrote: Hum... how can I say it? It's trivial to crash _sre :-) So I blacklisted _sre.compile() in my fuzzer. We should certainly try to fix those issues, then; people usually assume the re module is safe for use inside a sandbox and probably aren't careful enough to block importing of the _sre module. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fuzzing bugs: most bugs are closed
yOn Mon, Jul 21, 2008 at 03:53:18PM +, Antoine Pitrou wrote: The underscore at the beginning of _sre clearly indicates that the module is not recommended for direct consumption, IMO. Even the functions that don't themselves start with an underscore... Sure, but if someone is trying to break in or DoS your application server, they don't care if the module starts with an underscore or not. To answer Victor's original question: the parser compiler that turn a regex into bytecode is written in Python. I can't think of a way to prevent other Python modules from importing _sre or accessing the compile() function; if nothing else, code could always do 'import re ; re.sre_compile._sre.compile(...)'. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] git repositories for trunk and py3k
On Fri, Jul 18, 2008 at 11:12:41AM -0700, Brett Cannon wrote: And those two periods are significant for people who think they are line noise. Damn is Git quirky. Oh my, yes. We use git at work; there's a reason I now use Bazaar for personal projects. I assume the ^ operator means just before this commit. Correct; HEAD^^ is two commits ago, and you can do HEAD~35 for 35 commits ago. There's a git-rev-parse man page describing these. Does the abbreviation have to be exactly six characters? No, it has to be long enough to be unambiguous. 6cadb9c1b7 would also work, and 6cadb might, depending on the other commits in your repository. I tried that, but but format-patch didn't show me anything since I had just committed. And when I run ``git format-patch HEAD^`` it spits out what looks like a file name, but I don't see it anywhere. I think it writes the file to the current working directory, so I don't know why you're not seeing it. (The file is something like 0001-commit-message.patch.) --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r64407 - python/trunk/Doc/library/multiprocessing.rst
On Thu, Jun 19, 2008 at 05:16:38PM -0400, Jesse Noller wrote: Where would that chapter end up (source-wise) I think a few of us might have additional things to add ;) This would be Doc/library/ipc.rst. The chapter is 'Interprocess Communication and Networking'. Is anyone else finding it increasingly odd that subprocess, signal, socket/ssl, and syncore are in the same chapter? I'm tempted to move socket, ssl, asyncore+asynchat into a 'networking' chapter, and then also move SocketServer from the 'Internet Protocols' chapter into this new chapter. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r64407 - python/trunk/Doc/library/multiprocessing.rst
On Fri, Jun 20, 2008 at 08:55:13AM -0700, Bill Janssen wrote: Is anyone else finding it increasingly odd that subprocess, signal, socket/ssl, and syncore are in the same chapter? I'm tempted to move socket, ssl, asyncore+asynchat into a 'networking' chapter, and then also move SocketServer from the 'Internet Protocols' chapter into this new chapter. Sounds like you mean, 'Non-HTTP Networking'. I don't think so -- SMTP, FTP, NNTP, and telnet have nothing to do with HTTP, but they're certainly Internet protocols. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r64407 - python/trunk/Doc/library/multiprocessing.rst
On Thu, Jun 19, 2008 at 03:04:11PM -0500, Benjamin Peterson wrote: I don't think the whole introduction had to go. I think it helped give some idea of how multiprocessing works before jumping straight to the API reference. I don't think overview material like that should be buried inside the documentation for one particular module; it should go in a chapter introduction. My plan is to move multiprocessing from the 'Optional OS Services' chapter to the 'Interprocess Communication' chapter, and then expand the introduction of the chapter to discuss the GIL and related issues. Presumably it was put in the 'Optional OS Services' chapter because that's where the threading and thread modules are. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] sum() in math module not duplicated?
In the comments before the implementation of sum() in mathmodule.c, note 4 says: Note 4: A similar implementation is in Modules/cmathmodule.c. Be sure to update both when making changes. I can't find a sum implementation or similar code in cmathmodule.c. Did someone intend to port the sum function to cmath, or was it copied and then taken out? I'm wondering if this note should simply be removed. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
On Mon, May 19, 2008 at 06:13:11PM -0700, Bill Janssen wrote: And these are all SYSV derivatives, aren't they? So perhaps it's some common fix for all three? This reminds of a Tim-ism: == Just for the record, on AIX, the following C program: Oh no you don't! I followed AIX threads for the first year it came out, but eventually decided there was no future in investing time in baffling discussions that usually ended with oh, never mind -- turns out it's a bug 0.9 wink. Vladimir Marangozov and Tim Peters, 23 Jun 1998 == 10 years later, things don't seem to be much different. For ctypes it looks like libffi often fails to compile when not using GCC; http://bugs.python.org/issue1637120 is an AIX bug report. For the curses module, I've noticed that HP-UX seems to require including additional header files or defining _XOPEN_SOURCE to make curses.h work. So I don't think there's a common problem with all these minority platforms, and we really would need developers on all of them. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
On Mon, May 12, 2008 at 12:21:00PM +1200, Greg Ewing wrote: Parsing a file and wanting to be able to print error messages with line numbers would seem to be a fairly likely use. Couldn't people be using the fileinput module for this, though? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] [Python-3000] r62848 - python/trunk/Objects/setobject.c
On Thu, May 08, 2008 at 11:23:11PM +1000, Nick Coghlan wrote: It's actually the time zone issues that get me in relation to code freezes... so I just try to avoid committing anything for a day or two :) Subscribers to the python-dev digests may also not see a posting immediately, waiting until the next digest is sent. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sock.close() not closing?
On Wed, May 07, 2008 at 10:29:02AM -0700, Bill Janssen wrote: This particular nasty pattern is deeply entwined in all the code that touches the HTTP library in any way, so it will be a big job to get rid of it -- basically re-writing HTTP support and all the services which use it. I didn't want to get into that :-). This would be a good chance for Py3K to dump httplib/urllib/urllib2 and use some more modern library. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sock.close() not closing?
On Wed, May 07, 2008 at 03:29:33PM -0300, Facundo Batista wrote: This would be a good chance for Py3K to dump httplib/urllib/urllib2 and use some more modern library. Which modern library do you propose? I have no idea -- presumably we'd need to compare a bunch of them (curl, libwget, and whatever else is out there) and decide upon one. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Global Python Sprint Weekends: May 10th-11th and June 21st-22nd.
On Wed, Apr 16, 2008 at 10:51:53AM -0700, Trent Nelson wrote: Following on from the success of previous sprint/bugfix weekends and sprinting efforts at PyCon 2008, I'd like to propose the next two Global Python Sprint Weekends take place on the following dates: A great idea; thanks for organizing this! I've updated the wiki page at http://wiki.python.org/moin/PythonBugDay, so people can link to it, and added a news item on www.python.org. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] very bad network performance
On Mon, Apr 14, 2008 at 11:10:12AM -0700, Curt Hagenlocher wrote: while True: left = size - buf_len ! recv_size = max(self._rbufsize, left) data = self._sock.recv(recv_size) What version is this patch against? (The last 2.5 release, maybe?) The max() in the above line should be min(), because you want to use the *smaller* number of the buffer size and the # of remaining bytes to read, not the *larger*. This code is using min() in both 25-maint and trunk. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
On Mon, Mar 24, 2008 at 10:04:20PM +0100, Thomas Wouters wrote: I remember only a couple of dissenting voices, and only a small number of participants. Of the dissenting voices, I do not recall any actual arguments Weren't some of those dissenting voices the Twisted developers, though? --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
