[Python-Dev] Python development tools (Was: Goodbye)

2010-09-25 Thread anatoly techtonik
On Wed, Sep 22, 2010 at 1:47 PM, Antoine Pitrou solip...@pitrou.net wrote:

 Simply, situations like the above (Mark closing a bug just because
 nobody would answer his message on a short delay) have happened
 multiple times - despite people opposing, obviously -,

I must say that the same attitude is present in meta tracker proposals
as well. People, who need a closure quite often tend to mark issues
(enhancement proposals) as won't fix just because they can't (or don't
want) to see solution or just because they think that solution is too
complicated to implement. They judge it from the point of annoyed
developer even though the feature can actually be handy for users of
the tracker.

The reason here could be that developers are lost in the amount of
issues and can't filter them and see who does what. For example, I
could triage issues for some modules I am interested in, but I can't.
So, to overcome the complexity of global bug space developers are
tempted to squash confusing issues. There can be only one solution -
concentrate on the tools. Add an omnibox to tracker that will use
autocompletion and labels (Google Code). Useful ticket query interface
(Trac). Favorite issues (Google stars). Personal tags, issue sets,
message filters (Slashdot).

I've already brought the issue about necessity to enhance Python tools
some six months ago. At that time Richard Leland promised to do a
research of Python process to further work on proposal to improve it.
This was due to June, but still no result. I should blame myself for
waiting, because I had some plans to propose, but at that time it was
impossible to get going, because everybody had big hopes for that
research.

 There was a whole python-dev thread some time (weeks? months?) ago where
 several of us already tried to suggest more fruitful ways of
 contributing, suggestions which weren't received very welcomingly AFAIR.

This will never give any results if you did not collecting the
outcomes, summaries and links for the future. My vision is that other
fruitful ways of contributing are not fun. The most modern tool with
more or less sane gameplay here is tracker. But it suxx in many ways.
Mostly because it is too old and too few are able to patch it due to
either lack of information or experience (or time to get one or
another). Mercurial is insane, and there isn't really anything else
(except Sphinx). Well, there are lists, but there is nothing you can
really do about them (except prevent Mailman from dropping archives
from time to time or setup a Google Groups mirror).
-- 
anatoly t.
___
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

2010-09-25 Thread anatoly techtonik
On Fri, Sep 24, 2010 at 1:27 AM, Nick Coghlan ncogh...@gmail.com wrote:

    Antoine Given that few or none of us seem to (want to) actively
    Antoine contribute to the wiki, I'm afraid python-dev is not the place
    Antoine to ask.  Perhaps a call should be issued on c.l.py ...

 It would be nice if you could actually send messages to the people who do
 actually update wiki content.  Unfortunately, without donning my cape and
 blue tights, then digging into the users files on the wiki there's no real
 way to do that.

That's bad. I'd really like to see the amount of my contributions so
far. How about recording a session on MoinMoin hacking and drafting an
upgrade plan? Who's gonna be the driver?

 That's a good point actually... why *isn't* there a pydotorg-wiki-sig?
 (Aside from the obvious point of nobody ever asking for one).

Because Yet Another Mailing List doesn't solve the problem.
If you need one - go Google Groups like packaging folks did.
Python ML are:
1. require dedicated admin to update, who is not a member of the group
2. don't have search
3. don't have optional thread subscription
That's already enough to seek better platform for collaboration.

 I must admit, that the various things I've thrown on there myself have
 been pretty much fire-and-forget. Without anyone that feels like they
 collectively own the wiki, the much needed pruning never happens.

Community can perfectly manage the stuff without dedicated admins if
there is a gameplay in it. I am doing the wiki works when I am
redirected to outdated wiki pages from search. But I do it only if it
doesn't take me more than 5 minutes, and if I can remember the
password (and I know where an edit button is).

My advice - subscribe people editing page by default (a checkbox near
submit button). This way more people will receive notifications when a
page is changed and will be more interested to contribute themselves.
Of course, there must be a setting to opt out.

 With an admin team behind it, you can also make more use of ACLs to
 flag certain parts of the wiki as official by making them only
 editable by certain people (e.g. only devs, only the triage team, only
 the wiki admins). But keeping those user lists up to date is itself
 something that requires a strong wiki admin team.

That's a dead way. Wiki should be open for everyone. Just need more
people subscribed to revert unwelcome changes. That is to make
timeline more visible, because on wiki.python.org it is _not_
intuitive. It may worth to see how Mercurial wiki is managed - I've
picked up the bookmarks monitoring habit from it. Maybe a design
change will help, but again - there is no entrypoint for people with
design skills to start.

A lot of problems. All on the surface. Mailing list won't help. What's next?
-- 
anatoly t.
___
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] os.path.normcase rationale?

2010-09-25 Thread Paul Moore
On 24 September 2010 23:43, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 Hmm.  There is no need for the function on a case sensitive file system,
 because the name had better be spelled with matching case: that is, if it is
 spelled with non-matching case it is an attempt to reference a non-existent
 file (or at least a different file).

On Linux, I don't believe there's a way to ask is this filesystem
case insensitive?

In fact, with userfs, I believe it's possible to do massively
pathological things like having a filesystem which treats anagrams as
the same file (foo is the same file as oof or ofo). (More
realistically, MacOS does Unicode normalisation).

Windows has (I believe) user definable filesystems, too, but the OS
has get me the real filename style calls, which the filesystem
should support, so no matter how nasty a filesystem implementer gets,
he has to deal with his own mess :-)

Paul.
___
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] Summary of Python tracker Issues

2010-09-25 Thread Georg Brandl
Am 25.09.2010 03:45, schrieb Brett Cannon:
 On Fri, Sep 24, 2010 at 13:04, Georg Brandl g.bra...@gmx.net wrote:
 So by opening and closing a bug 5 times within a week, the open and
 close counters both go up by 5?  That would be stupid.
 
 No, as in a bug was re-opened last week and then closed again this week.
 

 Issues can't be open and closed at the same time.  There is a count of
 open issues at the start of the week, and one at the end of the week.
 There's a difference between those two counts which in total must sum
 up to the total difference in issues.

 If I understand correctly how the counters work, they at least need to
 be renamed -- they do *not* count open/closed issues, they count
 openings/closings.
 
 Guess the only way to settle this is look at the code, but I don't
 care enough to bother. =)

I'll bother Ezio when he's back.  It just feels strange to me that the bit
of statistic I feel is most interesting -- whether there are less open bugs
at the end of the week than at the start -- is not obvious from the report.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Summary of Python tracker Issues

2010-09-25 Thread Martin v. Löwis
 Guess the only way to settle this is look at the code, but I don't
 care enough to bother. =)
 
 I'll bother Ezio when he's back.  It just feels strange to me that the bit
 of statistic I feel is most interesting -- whether there are less open bugs
 at the end of the week than at the start -- is not obvious from the report.

The total numbers reported are really the totals. Also, the delta
reported for the totals is the difference to the last report.

The number reported with +/- for open/closed are *not* deltas, but the
number of issues opened since last week. As some open issues were closed
and some closed issues were opened, they don't sum up the way you
expect. An example:

old:
  open:   #1 #2
  closed: #3 #4
new:
  open:   #1 #3 #5
  closed: #2 #4

The report would be

  open: 3 (+2, namely #3 and #5); delta would be +1
  closed: 2 (+1, namely #4); delta would be 0

IOW, the numbers after +/- match the counts in the lists shown below,
not the delta since last week.

HTH,
Martin
___
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

2010-09-25 Thread anatoly techtonik
On Fri, Sep 24, 2010 at 1:31 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:

 More wiki and website maintainers needed!

That's the consequence. You need to seek the reason why there are no
maintainers or active members on pydotorg-www lists. I've expressed my
thoughts earlier.


On Fri, Sep 24, 2010 at 6:40 AM, Steven D'Aprano st...@pearwood.info wrote:

 For me, the number one roadblock is unfamiliarity -- I always forget
 that there is a Python wiki.

For me a major annoyance is the empty page with two links on wiki.python.org
While it allows to tell new people that there is also a Jython wiki,
my vision that it should be instead be oriented on existing
contributors immediately providing instruments to work with Python
wiki. So if smb. need Jython wiki - it should be moved to
wiki.jython.org

I'd start from there.
Who can do this?

--
anatoly t.
___
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] Summary of Python tracker Issues

2010-09-25 Thread Georg Brandl
Am 25.09.2010 14:10, schrieb Martin v. Löwis:
 Guess the only way to settle this is look at the code, but I don't
 care enough to bother. =)
 
 I'll bother Ezio when he's back.  It just feels strange to me that the bit
 of statistic I feel is most interesting -- whether there are less open bugs
 at the end of the week than at the start -- is not obvious from the report.
 
 The total numbers reported are really the totals. Also, the delta
 reported for the totals is the difference to the last report.
 
 The number reported with +/- for open/closed are *not* deltas, but the
 number of issues opened since last week. As some open issues were closed
 and some closed issues were opened, they don't sum up the way you
 expect. An example:
 
 old:
   open:   #1 #2
   closed: #3 #4
 new:
   open:   #1 #3 #5
   closed: #2 #4
 
 The report would be
 
   open: 3 (+2, namely #3 and #5); delta would be +1
   closed: 2 (+1, namely #4); delta would be 0
 
 IOW, the numbers after +/- match the counts in the lists shown below,
 not the delta since last week.

Yes, and that's what I complained about. However, your example doesn't
demonstrate my problem, since its deltas *are* real deltas, and
+1 + +0 == +1.

I guess a better example would be

old:
  open #1 #2
  closed #3
new:
  open #1
  closed #2 #3 #4 #5

which results in +2 for open (since #4 and #5 were opened) and +3 for closed
(since #2, #4 and #5 were closed), however the total issue delta is +2.  This
is why I think these numbers should be labeled openings and closings.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Relative imports in Py3k

2010-09-25 Thread anatoly techtonik
Hi,

I wonder if situation with relative imports in packages is improved in
Python 3k or
we are still doomed to a chain of hacks?

My user story:
I am currently debugging project, which consists of many modules in one package.
Each module has tests or other useful stuff for debug in its main
section, but it is a
disaster to use it, because I can't just execute the module file and
expect it to find
relatives. All imports are like:

from spyderlib.config import get_icon
from spyderlib.utils.qthelpers import translate, add_actions, create_action

PEP 328 http://www.python.org/dev/peps/pep-0328/  proposes:

from ... import config
from ..utils.qthelpers import translate, add_actions, create_action

But this doesn't work, and I couldn't find any short user level
explanation why it is
not possible to make this work at least in Py3k without additional magic.

--
anatoly t.
___
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

2010-09-25 Thread David Stanek
On Sat, Sep 25, 2010 at 8:22 AM, anatoly techtonik techto...@gmail.com wrote:

 For me a major annoyance is the empty page with two links on wiki.python.org
 While it allows to tell new people that there is also a Jython wiki,
 my vision that it should be instead be oriented on existing
 contributors immediately providing instruments to work with Python
 wiki. So if smb. need Jython wiki - it should be moved to
 wiki.jython.org


That's funny, I've never seen that page before. Does it get linked to
from somewhere?

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
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] Relative imports in Py3k

2010-09-25 Thread Georg Brandl
Am 25.09.2010 15:15, schrieb anatoly techtonik:
 Hi,
 
 I wonder if situation with relative imports in packages is improved in
 Python 3k or we are still doomed to a chain of hacks?

 My user story:
 I am currently debugging project, which consists of many modules in one 
 package.
 Each module has tests or other useful stuff for debug in its main
 section, but it is a
 disaster to use it, because I can't just execute the module file and
 expect it to find
 relatives. All imports are like:
 
 from spyderlib.config import get_icon
 from spyderlib.utils.qthelpers import translate, add_actions, create_action
 
 PEP 328 http://www.python.org/dev/peps/pep-0328/  proposes:
 
 from ... import config
 from ..utils.qthelpers import translate, add_actions, create_action
 
 But this doesn't work, and I couldn't find any short user level
 explanation why it is
 not possible to make this work at least in Py3k without additional magic.

Uh, this doesn't work is a report that every developer loves.  I suppose
Python does raise an exception with a message?

For diagnosing this, you should also at least include from which module
you're trying to executing these import statements.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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

2010-09-25 Thread Georg Brandl
Am 25.09.2010 15:15, schrieb David Stanek:
 On Sat, Sep 25, 2010 at 8:22 AM, anatoly techtonik techto...@gmail.com 
 wrote:

 For me a major annoyance is the empty page with two links on wiki.python.org
 While it allows to tell new people that there is also a Jython wiki,
 my vision that it should be instead be oriented on existing
 contributors immediately providing instruments to work with Python
 wiki. So if smb. need Jython wiki - it should be moved to
 wiki.jython.org

 
 That's funny, I've never seen that page before. Does it get linked to
 from somewhere?

It's at http://wiki.python.org/, and FTR, it has annoyed me as well.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Relative imports in Py3k

2010-09-25 Thread Eric Smith

On 9/25/2010 9:15 AM, anatoly techtonik wrote:

from ... import config
from ..utils.qthelpers import translate, add_actions, create_action

But this doesn't work, and I couldn't find any short user level
explanation why it is
not possible to make this work at least in Py3k without additional magic.


This doesn't belong on python-dev, as it's not about developing python.

Also, it's a horrible bug report, if that's what it is. I'd suggest 
trying python-list and reading something like 
http://itscommonsensestupid.blogspot.com/2008/07/tips-to-write-good-bug-report.html


Eric.
___
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] Goodbye

2010-09-25 Thread Stephen J. Turnbull
Éric Araujo writes:
  How about revamping the type/versions fields?
  
  Issue type () Feature request (blocked by moratorium: () yes () no)

I think the information about blocked by moratorium is not something
that users or devs will care about much.  The users can be informed
about the fact of the moratorium (There is currently a feature
moratorium in effect.  If this feature is determined to be a change in
the language, it will not appear until Python 3.4 or later.  Changes
to the standard library functions are acceptable.  If no progress is
made on the issue in a reasonable time, you may request discussion on
python-...@python.org.) in the reply page that confirms receipt of
the issue.

However, devs already know about the moratorium, and if there's a
question of interpretation it will be discussed on python-dev.  Users
only care that their request is (not) being addressed; the moratorium
is only one of many reasons why action is delayed.
___
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] os.path.normcase rationale?

2010-09-25 Thread Stephen J. Turnbull
Paul Moore writes:

  In fact, with userfs, I believe it's possible to do massively
  pathological things like having a filesystem which treats anagrams
  as the same file (foo is the same file as oof or ofo). (More
  realistically, MacOS does Unicode normalisation).

Nitpick: Mac OS X doesn't do Unicode normalization.  The default
filesystem implementation does.


___
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] os.path.normcase rationale?

2010-09-25 Thread Guido van Rossum
On Fri, Sep 24, 2010 at 8:25 PM, Steven D'Aprano st...@pearwood.info wrote:
 On Sat, 25 Sep 2010 09:22:47 am Guido van Rossum wrote:

 I think that, like os.path.realpath(), it should not fail if the file
 does not exist.

 Maybe the API could be called os.path.unnormpath(), since it is in a
 sense the opposite of normpath() (which removes case) ? But I would
 want to write it so that even on Unix it scans the filesystem, in
 case the filesystem is case-preserving (like the default fs on OS X).

 It is not entirely clear to me what this function is meant to actually
 do? Should it:

 1. Return the case of a filename in some canonical form which depends
   on the file system?
 2. Return the case of a filename as it is actually stored on disk?

This one. This is actually useful (on case-preserving filesystems).
There is no doubt in my mind that this is the requested and needed
functionality.

 3. Something else?

 and just for completeness:

 4. Return the case of a filename in some arbitrarily-chosen canonical
   form which does not depend on the file system?

 These are not the same, either conceptually or in practice.

 If you want #4, you already have it in os.path.normcase.

 I think that the OP, Chris, wants #1, but it isn't entirely clear to me.

I don't think this is where the issue lies.

 It's possible that he wants #2.

 Various people have posted links to recipes that solve case #2. Note
 though that this necessarily demands that if the file doesn't exist, it
 should raise an exception.

No it needn't; realpath() uses the filesystem but leaves non-existing
parts alone. Also some of the path may exist (e.g. a parent
directory).

 In the case of #1, if the file system doesn't exist, we can't predict
 what the canonical form should be.

 The very concept of canonical form for file names is troublesome. If the
 file system is case-preserving, the file system doesn't define a
 canonical form: the case of the file name will depend on how the file
 is initially named. If the file system is case-destructive the
 behaviour will depend on the file system itself: e.g. FAT12 and ISO
 9660 both uppercase file names, but other file systems may make other
 choices. For some arbitrary path, where we don't know what file system
 it is, or if the path doesn't actually exist, we have no way of telling
 what the file system's canonical form will be, or even whether it will
 have one.

 Note that I've been talking about case preservation, not case
 sensitivity. That's because case preservation is orthogonal to
 sensitivity. You can see three of the four combinations, e.g.:

 Preserving + insensitive:  fat32, NTFS under Win32, normally HFS+
 Preserving + sensitive:  ext3, NTFS under POSIX, optionally HFS+
 Destructive + insensitive:  fat12, fat16 without long file name support

 To the best of my knowledge, destructive + sensitive doesn't exist. It
 could, in principle, but it would be silly to do so.

 Note that just knowing the file system type is not enough to tell what
 its behaviour will be. Given an arbitrary file system, there's no
 obvious way to determine what it will do to file names short of trying
 to create a file and see what happens.

This operation should not do any writes.

The solution may well be OS specific. Solutions for Windows and OS X
have already been pointed out. If it can't be done for other Unix
versions, I think returning the input unchanged on those platform is a
fine fallback (as it is for non-existent filenames).

-- 
--Guido van Rossum (python.org/~guido)
___
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] r85000 - python/branches/py3k/Lib/test/test_trace.py

2010-09-25 Thread Antoine Pitrou
On Sat, 25 Sep 2010 00:04:23 +0200 (CEST)
alexander.belopolsky python-check...@python.org wrote:
 Author: alexander.belopolsky
 Date: Sat Sep 25 00:04:22 2010
 New Revision: 85000
 
 Log:
 This should fix buildbot failure introduced by r84994

Can you also backport it to 2.7?

Thanks

Antoine.


___
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] Summary of Python tracker Issues

2010-09-25 Thread Terry Reedy

On 9/25/2010 7:11 AM, Georg Brandl wrote:


I'll bother Ezio when he's back.  It just feels strange to me that the bit
of statistic I feel is most interesting -- whether there are less open bugs
at the end of the week than at the start -- is not obvious from the report.


As of just now, the default search for all open issues returns 2475. 
That is down steadily over the last 8 or so weeks from a peak of about 
2750 in early June. About 30 people have closed at least one issue in 
this period.


The current figure is up from about 1200 a few years ago. Part of the 
increase is due to the 2.x to 3.x transition and the bulge from 2 to 4 
active issues. I would roughly guess that there are perhap a couple 
hundred 2.7-only issue. You just closed one today.


--
Terry Jan Reedy

___
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] Summary of Python tracker Issues

2010-09-25 Thread Georg Brandl
Am 25.09.2010 18:53, schrieb Terry Reedy:
 On 9/25/2010 7:11 AM, Georg Brandl wrote:
 
 I'll bother Ezio when he's back.  It just feels strange to me that the bit
 of statistic I feel is most interesting -- whether there are less open bugs
 at the end of the week than at the start -- is not obvious from the report.
 
 As of just now, the default search for all open issues returns 2475. 
 That is down steadily over the last 8 or so weeks from a peak of about 
 2750 in early June. About 30 people have closed at least one issue in 
 this period.

That's really promising.  (And that's also why I want to see a negative delta
for the open count.)  Thanks for these numbers!

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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

2010-09-25 Thread Paul Boddie
Hello,

I've been following this thread all week at work, but I thought it might be 
time to respond to the different remarks in a single response, given that I 
am involved in editing and maintaining the Wiki on python.org, and I had a 
strong enough opinion about such things to give a talk about it at EuroPython 
that some of you attended:

http://wiki.europython.eu/Talks/Web_Collaboration_And_Python/Talk

Guido van Rossum wrote:
 On Thu, Sep 23, 2010 at 3:35 PM, Martin v. Löwis martin at v.loewis.de 
wrote:
  There actually is an admin team, and they actually do set ACLs.

 Who are they?

  IIUC, this is primarily for spam protection, though.

 So would they object against additions to the team?

The administrators are generally the people on the following page:

http://wiki.python.org/moin/AdminGroup

Someone may have special powers, particularly if they have shell access to the 
machine running the Wiki, but there's no secret brotherhood. In fact, I 
recall advocating that Carl Trachte get admin powers given his continuing 
high-quality contributions, so we can say that people aren't denying others 
administrative privileges if that person is clearly doing good work and would 
benefit from being able to have those privileges.

[Later on...]

Guido van Rossum wrote:
 On Fri, Sep 24, 2010 at 3:31 AM, Michael Foord

 fuzzyman at voidspace.org.uk wrote:
  Wiki maintenance is discussed, along with other python.org maintenance
  topics, on the pydotorg-www mailing list:
 
  http://mail.python.org/mailman/listinfo/pydotorg-www

 Which has hidden its membership (even to members). Does it really need
 to appear that secretive? At least the message archive is open and has
 all the usual suspects.

As we're now seeing, people don't feel that it's acceptable to publish the 
subscribers list, and I think that it's a complete distraction to seek to do 
so, anyway. It's not as if everyone on that list has special privileges and 
is preventing newcomers from joining it.

  More wiki and website maintainers needed!

 Maybe a prominent wiki page with info about how to join the list and
 the responsibilities / needs would help?

 Also, I gotta say that the wiki login process is awkward.

MoinMoin supports OpenID, although I did find and report issues with Moin 1.9 
in this regard. Something on my now-huge list of things to do is to make Moin 
authentication better, especially where there might be a choice of 
authentication methods.

Georg Brandl wrote:
 Am 23.09.2010 22:25, schrieb anatoly techtonik:
  On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw barry at python.org wrote:
  I certainly agree with that.  So, how can we solve those problems? 
  Radomir has shell access now so perhaps we can ask him to make the
  Python wiki theme more visually appealing.  What roadblocks do people
  encounter when they want to help garden or reorganize the wiki?
 
  First of all Wiki is outdated. Correct me, but python.org specific
  customizations are not modules, but patches that makes it hard to
  update the Wiki to latest version or add new customizations.

 That's why we have a Moin core developer on the team.  ISTM that Moin 1.x
 is notoriously hard to extend -- once you go beyond plugins adding new wiki
 macros -- which is part of what the team wants to fix in 2.x.

Although I understand the sentiments about specific customizations, 
python.org should only have its theme as something that isn't a generic 
extension to MoinMoin, and that theme should be actively maintained. When 
python.org switched its architecture a while ago, the special theme 
presumably came with the deal, but it's been so out of date for so long that 
I switched to one of the standard themes years ago. Fortunately, Radomir's 
EuroPython theme is actively maintained, works with recent MoinMoin releases, 
looks a lot better than the old theme, and is used elsewhere.

As for Moin 1.x being notoriously hard to extend beyond macros, you can get 
a long way with macros and actions, although I agree that sometimes it's 
possible to hit architectural constraints.

  Second - ugly Creole syntax. I am for inter-cooperation between wikis,
  and I understand that for non-developer communities [] symbols
  imposing problems, but as an open source developer I am addicted to
  Trac and Google Code syntax and never had problems with those.

 This isn't Creole syntax, it's Moin wiki syntax.  And face it, it's not
 going to change.  It's also not so much different from Trac wiki syntax.

I never agreed with this complaint, anyway. When discussing this previously 
with Anatoly, I went as far as to ask on #moin where Radomir actually posted 
a good summary of the syntax differences:

http://wiki.python.org/moin/SiteImprovements/WikiSyntaxComparison

I invite anyone to justify claims that the old style (which Trac adopted) was 
better. Complaints about double bracketing are specious: MediaWiki has 
different bracketing levels and it's really confusing.

  Fourth. GPL license. 

Re: [Python-Dev] Python wiki

2010-09-25 Thread Michael Foord

 On 25/09/2010 20:12, Paul Boddie wrote:

[snip...]
Guido van Rossum wrote:

On Fri, Sep 24, 2010 at 3:31 AM, Michael Foord

fuzzyman at voidspace.org.uk  wrote:

Wiki maintenance is discussed, along with other python.org maintenance
topics, on the pydotorg-www mailing list:

http://mail.python.org/mailman/listinfo/pydotorg-www

Which has hidden its membership (even to members). Does it really need
to appear that secretive? At least the message archive is open and has
all the usual suspects.

As we're now seeing, people don't feel that it's acceptable to publish the
subscribers list,


To be fair, quite a few people said they thought it was fine / a good 
thing. A couple (maybe 3?) said that as the list was originally 
advertised with the member list hidden it would be unfair to change. So 
based on responses, more people think it *is* acceptable.


So long as we give notice for the change, so that anyone who doesn't 
want their name associated with the list can unsubscribe, I don't see 
why there should be a problem.


All the best,

Michael


and I think that it's a complete distraction to seek to do
so, anyway. It's not as if everyone on that list has special privileges and
is preventing newcomers from joining it.



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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

2010-09-25 Thread Georg Brandl
Am 25.09.2010 21:12, schrieb Paul Boddie:

 Georg Brandl wrote:
 Am 23.09.2010 22:25, schrieb anatoly techtonik:
  On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw barry at python.org wrote:
  I certainly agree with that.  So, how can we solve those problems? 
  Radomir has shell access now so perhaps we can ask him to make the
  Python wiki theme more visually appealing.  What roadblocks do people
  encounter when they want to help garden or reorganize the wiki?
 
  First of all Wiki is outdated. Correct me, but python.org specific
  customizations are not modules, but patches that makes it hard to
  update the Wiki to latest version or add new customizations.

 That's why we have a Moin core developer on the team.  ISTM that Moin 1.x
 is notoriously hard to extend -- once you go beyond plugins adding new wiki
 macros -- which is part of what the team wants to fix in 2.x.
 
 Although I understand the sentiments about specific customizations, 
 python.org should only have its theme as something that isn't a generic 
 extension to MoinMoin, and that theme should be actively maintained. When 
 python.org switched its architecture a while ago, the special theme 
 presumably came with the deal, but it's been so out of date for so long that 
 I switched to one of the standard themes years ago. Fortunately, Radomir's 
 EuroPython theme is actively maintained, works with recent MoinMoin releases, 
 looks a lot better than the old theme, and is used elsewhere.

As a disclaimer, I have no idea about the specific configuration of Moin used
at wiki.python.org.

 As for Moin 1.x being notoriously hard to extend beyond macros, you can get 
 a long way with macros and actions, although I agree that sometimes it's 
 possible to hit architectural constraints.

It's just that every Moin installation I've come across used custom patches,
and as a consequence was difficult to update.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] WSGI is now Python 3-friendly

2010-09-25 Thread P.J. Eby
I have only done the Python 3-specific changes at this point; the 
diff is here if anybody wants to review, nitpick or otherwise comment:


  
http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014r2=85013pathrev=85014

For that matter, if anybody wants to take a crack at updating Python 
3's wsgiref based on the above, feel free.  ;-)  I'll be happy to 
answer any questions I can that come up in the process.


(Please note: I went with Ian Bicking's headers are strings, bodies 
are bytes proposal, rather than my original bodies and outputs are 
bytes one, as there were not only some good arguments in its favor, 
but because it also resulted in fewer changes to the PEP, especially 
in the code samples.)


I will continue to work on adding the other addenda/errata mentioned here:

  http://mail.python.org/pipermail/web-sig/2010-September/004655.html

But because these are shoulds rather than musts, and apply to both 
Python 2 and 3, they are not as high priority for immediate 
implementation in wsgiref and do not necessarily need to hold up the 
3.2 release.


(Nonetheless, if anybody is willing to implement them in the Python 3 
version, I will happily review the changes for backport into the 
Python 2 standalone version of wsgiref, and issue an updated release 
to include them.)


Thanks!

___
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] Summary of Python tracker Issues

2010-09-25 Thread R. David Murray
On Sat, 25 Sep 2010 14:22:06 +0200, Georg Brandl g.bra...@gmx.net wrote:
 Am 25.09.2010 14:10, schrieb Martin v. L=F6wis:
  The total numbers reported are really the totals. Also, the delta
  reported for the totals is the difference to the last report.
 
  The number reported with +/- for open/closed are *not* deltas, but the
  number of issues opened since last week. As some open issues were closed
  and some closed issues were opened, they don't sum up the way you
  expect. An example:
 
  old:
open:   #1 #2
closed: #3 #4
  new:
open:   #1 #3 #5
closed: #2 #4
 
  The report would be
 
open: 3 (+2, namely #3 and #5); delta would be +1
closed: 2 (+1, namely #4); delta would be 0
 
  IOW, the numbers after +/- match the counts in the lists shown below,
  not the delta since last week.
 
 Yes, and that's what I complained about. However, your example doesn't
 demonstrate my problem, since its deltas *are* real deltas, and
 +1 + +0 = +1.
 
 I guess a better example would be
 
 old:
   open #1 #2
   closed #3
 new:
   open #1
   closed #2 #3 #4 #5
 
 which results in +2 for open (since #4 and #5 were opened) and +3 for closed
 (since #2, #4 and #5 were closed), however the total issue delta is +2.  Th=
 is why I think these numbers should be labeled openings and closings.

I haven't looked at the code, so I don't know the details of the
algorithm that is actually used, but from what Ezio said your example
is *not* correct.  The numbers in parenthesis are the number of issues
opened/closed in the past week that are *still* open or closed.  So open
would certainly not be +2.  I'm not sure if it would be +0 or -1 without
looking at the code.

I agree that having the delta against open from the previous week would
be the most helpful.

--David
___
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

2010-09-25 Thread Guido van Rossum
On Sat, Sep 25, 2010 at 12:12 PM, Paul Boddie p...@boddie.org.uk wrote:
 Guido van Rossum wrote:
 Also, I gotta say that the wiki login process is awkward.

 MoinMoin supports OpenID, although I did find and report issues with Moin 1.9
 in this regard. Something on my now-huge list of things to do is to make Moin
 authentication better, especially where there might be a choice of
 authentication methods.

Unfortunately, most sites using OpenID seem have an awkward login
process. Maybe it's just me (I don't use OpenID much) but I expect
that without a lot more handholding of new users, OpenID actually
turns more people away than any other registration/login process. The
people who like OpenID are often the ultra-geeks who cannot imagine
the worldview of a typical internet user, and when they design a
website they are often clueless about what it feels like to start
using OpenID for the first time or to remember your OpenID handle if
the last time you used it was a month ago.

Not that the native Moin login method is much better... Either way,
Python's wikis have some of the most awkward auth systems I've come
across.

-- 
--Guido van Rossum (python.org/~guido)
___
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] WSGI is now Python 3-friendly

2010-09-25 Thread Guido van Rossum
This is a very laudable initiative and I approve of the changes -- but
I really think it ought to be a separate PEP rather than pretending it
is just a set of textual corrections on the existing PEP 333.

--Guido

On Sat, Sep 25, 2010 at 12:56 PM, P.J. Eby p...@telecommunity.com wrote:
 I have only done the Python 3-specific changes at this point; the diff is
 here if anybody wants to review, nitpick or otherwise comment:

  http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014r2=85013pathrev=85014

 For that matter, if anybody wants to take a crack at updating Python 3's
 wsgiref based on the above, feel free.  ;-)  I'll be happy to answer any
 questions I can that come up in the process.

 (Please note: I went with Ian Bicking's headers are strings, bodies are
 bytes proposal, rather than my original bodies and outputs are bytes one,
 as there were not only some good arguments in its favor, but because it also
 resulted in fewer changes to the PEP, especially in the code samples.)

 I will continue to work on adding the other addenda/errata mentioned here:

  http://mail.python.org/pipermail/web-sig/2010-September/004655.html

 But because these are shoulds rather than musts, and apply to both Python
 2 and 3, they are not as high priority for immediate implementation in
 wsgiref and do not necessarily need to hold up the 3.2 release.

 (Nonetheless, if anybody is willing to implement them in the Python 3
 version, I will happily review the changes for backport into the Python 2
 standalone version of wsgiref, and issue an updated release to include
 them.)

 Thanks!

 ___
 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/guido%40python.org




-- 
--Guido van Rossum (python.org/~guido)
___
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

2010-09-25 Thread Martin v. Löwis
 Unfortunately, most sites using OpenID seem have an awkward login
 process. Maybe it's just me (I don't use OpenID much) but I expect
 that without a lot more handholding of new users, OpenID actually
 turns more people away than any other registration/login process.

So how do you like the OpenID login of PyPI, which has a Google,
MyOpenID and Launchpad icon, which users need to click on to create
in account or login?

The ultra geeks demanded and got a separate page where they
can enter long URLs.

Regards,
Martin
___
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] Summary of Python tracker Issues

2010-09-25 Thread Martin v. Löwis

 I guess a better example would be
 
 old:
   open #1 #2
   closed #3
 new:
   open #1
   closed #2 #3 #4 #5
 
 which results in +2 for open (since #4 and #5 were opened) and +3 for closed
 (since #2, #4 and #5 were closed), however the total issue delta is +2.  This
 is why I think these numbers should be labeled openings and closings.

I *have* looked at the code, any I'm certain that this is not how the
computation goes.

Instead, I'm also certain that it goes as in the message I sent.
Notice that it prints the numbers I put into parentheses (+2, +1),
and they do *not* sum up to +1. The numbers I posted as delta would
be are not currently included in the report.

Regards,
Martin
___
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] Summary of Python tracker Issues

2010-09-25 Thread Georg Brandl
Am 25.09.2010 23:41, schrieb Martin v. Löwis:
 
 I guess a better example would be
 
 old:
   open #1 #2
   closed #3
 new:
   open #1
   closed #2 #3 #4 #5
 
 which results in +2 for open (since #4 and #5 were opened) and +3 for closed
 (since #2, #4 and #5 were closed), however the total issue delta is +2.  This
 is why I think these numbers should be labeled openings and closings.
 
 I *have* looked at the code, any I'm certain that this is not how the
 computation goes.
 
 Instead, I'm also certain that it goes as in the message I sent.
 Notice that it prints the numbers I put into parentheses (+2, +1),
 and they do *not* sum up to +1. The numbers I posted as delta would
 be are not currently included in the report.

Ah. I misunderstood, sorry.  Well, let's bury this thread then and I will
put it on my todo list to modify it to work as expected.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Relative imports in Py3k

2010-09-25 Thread Martin v. Löwis
 Also, it's a horrible bug report, if that's what it is.

It's not a bug report, and I don't think it was meant to be
one. It started with I wonder if, suggesting that it is
really a request for help.

What you read as a bug report was labeled user story,
which I think is anatoly's way of saying it's not a bug
report.

Regards,
Martin
___
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

2010-09-25 Thread Georg Brandl
Am 25.09.2010 23:43, schrieb Martin v. Löwis:
 For me a major annoyance is the empty page with two links on 
 wiki.python.org
 While it allows to tell new people that there is also a Jython wiki,
 my vision that it should be instead be oriented on existing
 contributors immediately providing instruments to work with Python
 wiki. So if smb. need Jython wiki - it should be moved to
 wiki.jython.org


 That's funny, I've never seen that page before. Does it get linked to
 from somewhere?
 
 It's at http://wiki.python.org/, and FTR, it has annoyed me as well.
 
 So how would you propose to resolve this? Keep in mind that existing
 links need to continue to work.

Redirect wiki.python.org to the Python wiki front page, and put the Jython
wiki somewhere on its own (whether it's wiki.jython.org or not).

The only people who will need a pointer are those who went directly to
wiki.python.org/ and intended to go to the Jython wiki; a link might be
added on the front page of the Python wiki.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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

2010-09-25 Thread skip

 As we're now seeing, people don't feel that it's acceptable to
 publish the subscribers list,

Michael To be fair, quite a few people said they thought it was fine /
Michael a good thing.  A couple (maybe 3?) said that as the list was
Michael originally advertised with the member list hidden it would be
Michael unfair to change.  So based on responses, more people think it
Michael *is* acceptable.

I've not yet responded to this aspect of the thread.  I see no reason not to
make the membership list visible to the list members themselves.  Beyond
that, I don't think it serves any benefit, and of course, runs the risk of
exposing email addresses to spam harvesters.  OTOH, those of us who are
visible enough on the web that we get to the point of helping maintain a
very public website have probably already exposed our email addresses dozens
or hundreds of times (or more) to spammers.  Googling for s...@pobox.com
(the quotes are required to constrain the search properly) yields about
22,000 hits.  gu...@python.org yields about 38,000 hits.  Paul's and
Michael's addresses returned multiple thousands of hits.  And so on.

As I recall, one reason for the formation of pydotorg-www was to create a
more visible list than pydotorg so the maintenance of the website didn't
appear so cabalistic to the interested observer.  Still, I see that most/all
lists hosted on mail.python.org seem to restrict the list membership to the
list admins, so leaving the status quo probably won't hurt anything.

Skip
___
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

2010-09-25 Thread Martin v. Löwis
 Redirect wiki.python.org to the Python wiki front page, and put the Jython
 wiki somewhere on its own (whether it's wiki.jython.org or not).

But that can't work: then off-site links into either wiki break.

Regards,
Martin
___
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

2010-09-25 Thread Georg Brandl
Am 26.09.2010 00:16, schrieb Martin v. Löwis:
 Redirect wiki.python.org to the Python wiki front page, and put the Jython
 wiki somewhere on its own (whether it's wiki.jython.org or not).
 
 But that can't work: then off-site links into either wiki break.

Why -- they can be redirected easily.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] os.path.normcase rationale?

2010-09-25 Thread Greg Ewing

Paul Moore wrote:


Windows has (I believe) user definable filesystems, too, but the OS
has get me the real filename style calls,


Does it really, though? The suggestions I've seen for doing
this involve abusing the short/long filename translation
machinery, and I'm not sure they're guaranteed to return the
actual case rather than something that happens to work.

--
Greg
___
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

2010-09-25 Thread Martin v. Löwis
Am 26.09.2010 00:48, schrieb Georg Brandl:
 Am 26.09.2010 00:16, schrieb Martin v. Löwis:
 Redirect wiki.python.org to the Python wiki front page, and put the Jython
 wiki somewhere on its own (whether it's wiki.jython.org or not).

 But that can't work: then off-site links into either wiki break.
 
 Why -- they can be redirected easily.

Ok, so please be more specific: what exactly should the new structure
look like?

Regards,
Martin
___
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] Goodbye

2010-09-25 Thread Steve Holden
On 9/24/2010 10:50 AM, Antoine Pitrou wrote:
 Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit :

 I have often used searches on performance or resource usage to find
 what was needing a review or a patch. I think it would be a mistake to
 remove those two categories.

 That purpose would be served just as well by keywords though
 (particularly since those attributes aren't mutually exclusive -
 resource usage problems will usually *cause* performance problems, and
 you may notice the latter first).

Keywords are generally better than a restricted vocabulary for richness
of content, but worse for finding the appropriate search term. You pays
yer money and takes yer chance. Given that we could (if necessary)
overlay some sort of Python-specific semantic category generation to
searches if we needed to, I tend to favor the liberally tag with
keywords approach. But without any smarts being applied to the problem
it's always to know whether you are searching for the right
keywords.

 A generic bug classification would also better suit documentation
 bugs. The simpler we can make the more common fields, while still
 providing the essential information, the better.
 
 But how should a performance improvement be filed? Bug? Feature request?
 Or should feature request be renamed improvement?
 
Not all features would be improvements (and I'm thinking specifically
here of 2.x's print  f as an egregious design wart added for
entirely pragmatic reasons).

They could, however, be classified along with performance improvement
requests as Enhancement requests.

The big problem, I suspect, is that we don't give clear enough guidance
to almost total noobs about how to fill in the issue tracker form. If
you can't remember what your first month as a programmer was like then
you probably aren't qualified to be writing int on-line help for the
tracker. (The tracker does *have* on-line help, right?)

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

___
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] WSGI is now Python 3-friendly

2010-09-25 Thread Jesse Noller
On Sat, Sep 25, 2010 at 3:56 PM, P.J. Eby p...@telecommunity.com wrote:
 I have only done the Python 3-specific changes at this point; the diff is
 here if anybody wants to review, nitpick or otherwise comment:

  http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014r2=85013pathrev=85014

 For that matter, if anybody wants to take a crack at updating Python 3's
 wsgiref based on the above, feel free.  ;-)  I'll be happy to answer any
 questions I can that come up in the process.

 (Please note: I went with Ian Bicking's headers are strings, bodies are
 bytes proposal, rather than my original bodies and outputs are bytes one,
 as there were not only some good arguments in its favor, but because it also
 resulted in fewer changes to the PEP, especially in the code samples.)

 I will continue to work on adding the other addenda/errata mentioned here:

  http://mail.python.org/pipermail/web-sig/2010-September/004655.html

 But because these are shoulds rather than musts, and apply to both Python
 2 and 3, they are not as high priority for immediate implementation in
 wsgiref and do not necessarily need to hold up the 3.2 release.

 (Nonetheless, if anybody is willing to implement them in the Python 3
 version, I will happily review the changes for backport into the Python 2
 standalone version of wsgiref, and issue an updated release to include
 them.)

 Thanks!

This looks like good progress (and does not seem to block the progress
of PEP 444) but would it be possible to do it as a different PEP
rather then just an update; or adding an explicit these are the
differences between v1 and v2 section? It seems like it will end up
different enough to be a different specification, closely related to
the original, but different enough to trip up all the people
maintaining current WSGI servers and apps.

jesse
___
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] WSGI is now Python 3-friendly

2010-09-25 Thread P.J. Eby

At 09:22 PM 9/25/2010 -0400, Jesse Noller wrote:

It seems like it will end up
different enough to be a different specification, closely related to
the original, but different enough to trip up all the people
maintaining current WSGI servers and apps.


The only actual *change* to the spec is mandating the use of the 
'bytes' type or equivalent for HTTP bodies when using Python 3.


Seriously, that's *it*.

Everything else that's (planned to be) added is either 100% truly 
just clarifications (e.g. nothing in the spec *ever* said SERVER_PORT 
could be an int, but apparently some people somehow interpreted it 
so), or else best-practice recommendations from people who actually 
implemented WSGI servers.


For example, the readline() size hint is not supported in the 
original spec (meaning clients can't call it and be compliant).  The 
planned modification is servers should implement it (best 
practice), but you can't call an implementation that *doesn't* 
implement it noncompliant.  (This just addresses the fact that most 
practical implementations *did* in fact support it, and code out 
there relies on this.)


So, no (previously-)compliant implementations were harmed in the 
making of the updated spec.  If they were compliant before, they're 
compliant now.


I'm actually a bit surprised people are bringing this up now, since 
when I announced the plan to make these changes, I said that nothing 
would be changed that would break anything...  even for what I 
believe are the only Python 3 WSGI implementations right now (by 
Graham Dumpleton and Robert Brewer).


Indeed, all of the changes (except the bytes thing) are stuff 
previously discussed endlessly on the Web-SIG (years ago in most 
cases) and widely agreed on as, this should have been made clear in 
the original PEP.


And, I also explicitly deferred and/or rejected items that *can't* be 
done in a 100% backward-compatible way, and would have to be WSGI 1.1 
or higher -- indeed, I have a long list of changes from Graham that 
I've pronounced can't be done without a 1.1.


Indeed, the entire point of the my scope choices were to allow all 
this to happen *without* a whole new spec.  ;-)


___
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] Summary of Python tracker Issues

2010-09-25 Thread Terry Reedy

On 9/25/2010 1:08 PM, Antoine Pitrou wrote:

On Sat, 25 Sep 2010 19:02:06 +0200
Georg Brandlg.bra...@gmx.net  wrote:


Am 25.09.2010 18:53, schrieb Terry Reedy:

On 9/25/2010 7:11 AM, Georg Brandl wrote:


I'll bother Ezio when he's back.  It just feels strange to me that the bit
of statistic I feel is most interesting -- whether there are less open bugs
at the end of the week than at the start -- is not obvious from the report.


As of just now, the default search for all open issues returns 2475.
That is down steadily over the last 8 or so weeks from a peak of about
2750 in early June. About 30 people have closed at least one issue in
this period.


That's really promising.  (And that's also why I want to see a negative delta
for the open count.)  Thanks for these numbers!


Without any precision on how and why these bugs were closed, these
numbers don't mean anything. We would need a breakdown of bug closings
according to the resolution field, at the minimum.


Doing some hand-counting because I do not have proper (as in sql query) 
access to the database, closed issues so far for Activity: 2010-09


174 fixed
 36 invalid
 31 out of date
  1 postponed
 18 reject
 18 won't fix
  7 works for me
---
285

--
Terry Jan Reedy

___
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] WSGI is now Python 3-friendly

2010-09-25 Thread P.J. Eby

At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote:

This is a very laudable initiative and I approve of the changes -- but
I really think it ought to be a separate PEP rather than pretending it
is just a set of textual corrections on the existing PEP 333.


With the exception of the bytes change, I ruled out accepting any 
proposed amendments that would actually alter the protocol.  The 
amendments are all either textual clarifications, clarifications of 
ambiguous/unspecified areas, or best-practice recommendations by 
implementors.  (i.e., which are generally already implemented in major servers)


The full list of things Graham and others have asked for or 
recommended would indeed require a 1.1 version at minimum, and thus a 
new PEP.  But I really don't want to start down that road right now, 
and therefore hope that I can talk Graham or some other poor soul 
into shepherding a 1.1 PEP instead.  ;-)


(Seriously: through an ironic twist of fate, I have done nearly 
*zero* Python web programming since around the time I drafted the 
first spec in 2004, so even if it makes sense for me to finish PEP 
333, it makes little sense for me to be starting a *new* one on the topic now!)


___
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] WSGI is now Python 3-friendly

2010-09-25 Thread Guido van Rossum
On Sat, Sep 25, 2010 at 7:00 PM, P.J. Eby p...@telecommunity.com wrote:
 At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote:

 This is a very laudable initiative and I approve of the changes -- but
 I really think it ought to be a separate PEP rather than pretending it
 is just a set of textual corrections on the existing PEP 333.

 With the exception of the bytes change, I ruled out accepting any proposed
 amendments that would actually alter the protocol.  The amendments are all
 either textual clarifications, clarifications of ambiguous/unspecified
 areas, or best-practice recommendations by implementors.  (i.e., which are
 generally already implemented in major servers)

Of those, IMO only textual clarifications ought to be made to an
existing, accepted, widely implemented standards-track PEP.

Clarifications of ambiguous/unspecified behavior can possibly rule as
non-conforming implementations that used to get the benefit of the
doubt. Best-practice recommendations also have the effect of changing
(perceived) compliance.

Really, what's the problem with creating a new PEP? PEPs are cheap --
it's getting the acceptance that's costly, and you've already gotten
that part. It doesn't have to be long. You can still make pure textual
clarifications to PEP 333 (basically, improve grammar) and add a
pointer to the new PEP. Or, you can create a new PEP that is an
updated copy of PEP 333, and just add a pointer to PEP 333 saying
(especially in the context of Python 3) this PEP is now superseded by
PEP .

I strongly disagree with using (standards-track) PEPs as mutable
documents -- before you know it people will have to use weasel words
like compliant with PEP 333 as of date X to describe their
software's conformity. If you add a new PEP #, software declared
compliant with PEP 333 remains compliant (and some such software can
now also claim compliance with the new PEP without any changes).

 The full list of things Graham and others have asked for or recommended
 would indeed require a 1.1 version at minimum, and thus a new PEP.  But I
 really don't want to start down that road right now, and therefore hope that
 I can talk Graham or some other poor soul into shepherding a 1.1 PEP
 instead.  ;-)

That's fine. It will just be another PEP.

 (Seriously: through an ironic twist of fate, I have done nearly *zero*
 Python web programming since around the time I drafted the first spec in
 2004, so even if it makes sense for me to finish PEP 333, it makes little
 sense for me to be starting a *new* one on the topic now!)

Don't see this as a new spec. See it as a procedural issue.

-- 
--Guido van Rossum (python.org/~guido)
___
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