Re: [Python-Dev] Py2.6 buildouts to the set API

[Martin v. Löwis]

> * New method (proposed by Shane Holloway):  s1.isdisjoint(s2).
> Logically equivalent to "not s1.intersection(s2)" but has an
> early-out if a common member is found.  The speed-up is potentially
> large given two big sets that may largely overlap or may not
> intersect at all.  There is also a memory savings since a new set
> does not have to be formed and then thrown away.

I'd rather see iterator versions of the set operations. Then you
could do

def isempty(i):
  try:
i.next()
  except StopIteration:
return True
  else:
return False

if isempty(s1.iter_intersection(s2)):
  ...

> * Additional optional arguments for basic set operations to allow
> chained operations.  For example, s=s1.union(s2, s3, s4) would be
> logically equivalent to s=s1.union(s2).union(s3).union(s4) but would
> run faster because no intermediate sets are created, copied, and
> discarded.  It would run as if written:  s=s1.copy(); s.update(s2);
> s.update(s3); s.update(s4).

I'd rather see this as collections.bigunion.

> * Make sets listenable for changes (proposed by Jason Wells):

-1, IAGNI.

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] Py2.6 buildouts to the set API

[Giovanni Bajo]

On 19/05/2007 3.34, Raymond Hettinger wrote:

> * Make sets listenable for changes (proposed by Jason Wells):
> 
> s = set(mydata)
> def callback(s):
>  print 'Set %d now has %d items' % (id(s), len(s))
> s.listeners.append(callback)
> s.add(existing_element)   # no callback
> s.add(new_element)# callback

-1 because I can't see why sets are so specials (compared to other containers 
or objects) to provide a builtin implementation of the observer pattern.

In fact, in my experience, real-world use cases of this pattern often require 
more attention to details (eg: does the set keep a strong or weak reference to 
the callback? What if I need to do several *transactional* modifications in a 
row, and thus would like my callback to be called only once at the end?).
-- 
Giovanni Bajo

___
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] Need Survey Answers from Core Developers

[Nick Coghlan]

Jeff Rush wrote:
> Time is short and I'm still looking for answers to some questions about
> cPython, so that it makes a good showing in the Forrester survey.
> 
> 1) How is the project governed?  How does the community make decisions
>on what goes into a release?
> 
>You know, I've been a member of the Python community for many years
>-- I know about PEPs, Guido as BDFL, and +1/-1.  But I've never
>figured out exactly how -final- decisions are made on what goes
>into a release.  I've never needed to, until now.  Can someone
>explain in one paragraph?

As others have already pointed out, the ultimate authority rests with 
GvR. For any given release, Guido delegates a fair bit of authority to 
the release manager, and will often defer to the release manager's 
judgment (especially for maintenance releases).

The current status of a release (including naming names for the release 
team) is tracked using an Informational track PEP. The initial Python 
2.5 release was tracked in PEP 356. The Python 2.6 release is being 
tracked in PEP 361.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] Wither PEP 335 (Overloadable Boolean Operators)?

[Jason Orendorff]

On 5/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean
> Operators) by Greg Ewing.

-1.  "and" and "or" affect the flow of control.  It's a matter
of taste, but I feel the benefit is too small here to add
another flow-control quirk.  I like that part of the language
to be simple.

Anyway, if this *is* done, logically it should cover
"(... if ... else ...)" as well.  Same use cases.

-j
___
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] The docs, reloaded

[Georg Brandl]

Hi,

over the last few weeks I've hacked on a new approach to Python's documentation.
As Python already has an excellent documentation framework, the docutils, with a
readable yet extendable markup format, reST, I thought that it should be
possible to use those instead of the current LaTeX->latex2html toolchain.

For the impatient: the result can be seen at .

I've written a converter tool that handles most of the LaTeX markup and turns it
into reST, as well as a builder tool that adds many custom directives and roles,
and also features like index generation and cross-document linking.

(What you can see at the URL is a completely statical version of the docs, as it
would be shipped with the distribution. For the real online docs, I have more
plans; I'll come to that later.)

So why the effort?

Here's a partial list of things that have already been improved:

- the source is much more readable (for examples, try the "view source" links in
   the left navbar)
- all function/class/module names are properly cross-referenced
- the HTML pages are generated from templates, using a language similar to
   Django's template language
- Python and C code snippets are syntax highlighted
- for the offline version, there's a JavaScript enabled search function
- the index is generated over all the documentation, making it easier to find
   stuff you need
- the toolchain is pure Python, therefore can easily be shipped

What more?

If there is support for this approach, I have plans for things that can be added
to the online version:

- a "quick-dispatch" function: e.g., docs.python.org/q?os.path.split would
   redirect you to the matching location.
- "interactive patching": provide an "propose edit" link, leading to a Wiki-like
   page where you can edit the source. From the result, a diff is generated,
   which can be accepted, edited or rejected by the development team. This is
   even more straightforward than plain old comments.
- the same infrastructure could be used for developers, with automatic checkin
   into subversion.
- of course, plain old comments can be useful too.

Concluding, a small caveat: The conversion/build tools are, of course, not
complete yet. There are a number of XXX comments in the text, most of them
indicate that the converter could not handle a situation -- that would have
to be corrected once after conversion is done.

Waiting for comments!

Cheers,
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] The docs, reloaded

[Michael Foord]

Georg Brandl wrote:
> Hi,
>
> over the last few weeks I've hacked on a new approach to Python's 
> documentation.
> As Python already has an excellent documentation framework, the docutils, 
> with a
> readable yet extendable markup format, reST, I thought that it should be
> possible to use those instead of the current LaTeX->latex2html toolchain.
>
> For the impatient: the result can be seen at .
>   

Wow! Very impressive.

Changing to ReST would encourage more contributions to the documentation 
and widen the range of people able to maintain them.

Michael Foord

___
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] The docs, reloaded

[Steven Bethard]

On 5/19/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> For the impatient: the result can be seen at .
[snip]
> Here's a partial list of things that have already been improved:
>
> - the source is much more readable (for examples, try the "view source" links 
> in
>the left navbar)
> - all function/class/module names are properly cross-referenced
> - the HTML pages are generated from templates, using a language similar to
>Django's template language
> - Python and C code snippets are syntax highlighted
> - for the offline version, there's a JavaScript enabled search function
> - the index is generated over all the documentation, making it easier to find
>stuff you need
> - the toolchain is pure Python, therefore can easily be shipped

Very cool!  I'd love to see the docs move to ReST.

> If there is support for this approach, I have plans for things that can be 
> added
> to the online version:
>
> - a "quick-dispatch" function: e.g., docs.python.org/q?os.path.split would
>redirect you to the matching location.
> - "interactive patching": provide an "propose edit" link, leading to a 
> Wiki-like
>page where you can edit the source. From the result, a diff is generated,
>which can be accepted, edited or rejected by the development team. This is
>even more straightforward than plain old comments.
> - the same infrastructure could be used for developers, with automatic checkin
>into subversion.

Yes, these would all be outstanding features.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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 Tracker Issues

[Josiah Carlson]

"Aaron Brady" <[EMAIL PROTECTED]> wrote:
> "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
> > If we're going to do CAPTCHA, what we're looking for is something that
> > any 4 year old does automatically, but machines can't do at all.
> > Visual recognition used to be one, but isn't any more.  The CAPTCHA
> > literature claims that segmentation still is (dividing complex images
> > into letters), but that's nontrivial for humans, too, and I think that
> > machines will eventually catch up.  (Ie, within a handful of months.)
> 
> Complex backgrounds used?  Colorful foreground on a interior decorating
> background.
> 
> Also gradient foreground, gradient background.

Captchas like this are easily broken using computational methods, or
even the porn site trick that was already mentioned.  Never mind
Stephen's stated belief, that you quoted, that he believes that even the
hard captchas are going to be beaten by computational methods soon.  Please
try to pay attention to previous posts.


 - Josiah

As an aside, while the '4 year old can do it' is a hard qualification to
meet, add 10 years and there exists a fairly sexist method (-), that can
be subjective (-), that seems to work quite well (+), but requires
javascript (-); the 'hot or not' captcha. It fetches 9 random pictures
from hot or not (hopefully changes their file names) and asks the user
to pick the 4 hottest of the 9. A variant exists that asks "choose the 4
horses" or "select all of the iguanas", but it requires an ever-evolving
number of tagged input images (which is why hot or not works so well as
a source).

___
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] The docs, reloaded

[Josiah Carlson]

Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> over the last few weeks I've hacked on a new approach to Python's 
> documentation.
> As Python already has an excellent documentation framework, the docutils, 
> with a
> readable yet extendable markup format, reST, I thought that it should be
> possible to use those instead of the current LaTeX->latex2html toolchain.
> 
> For the impatient: the result can be seen at .

I'm generally a curmudgeon when it comes to 'the docs could be done
better'.  But this?  I like it.  A lot.  Especially if you can get these
other features in:

> - a "quick-dispatch" function: e.g., docs.python.org/q?os.path.split would
>redirect you to the matching location.
> - "interactive patching": provide an "propose edit" link, leading to a 
> Wiki-like
>page where you can edit the source. From the result, a diff is generated,
>which can be accepted, edited or rejected by the development team. This is
>even more straightforward than plain old comments.
> - the same infrastructure could be used for developers, with automatic checkin
>into subversion.

I'm a bit iffy on yet another tool, but if roundup integration could be
done, I think it would be great.

 - Josiah

___
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] The docs, reloaded

[Dustin J. Mitchell]

On Sat, May 19, 2007 at 10:48:29AM -0700, Josiah Carlson wrote:
> I'm generally a curmudgeon when it comes to 'the docs could be done
> better'.  But this?  I like it.  A lot.  Especially if you can get these
> other features in:
> 
> > - a "quick-dispatch" function: e.g., docs.python.org/q?os.path.split would
> >redirect you to the matching location.

Seconded! -- even if it's just for modules, this would be great.  

I can't count the times I've wished I could type e.g.,
'docs.python.org/httplib' the way I can type 'php.net/array_search' to
try to find out whether the needle comes before or after the haystack.

Dustin
___
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] [Doc-SIG] The docs, reloaded

[Lea Wiemann]

Georg Brandl wrote:

> over the last few weeks I've hacked on a new approach to Python's 
> documentation.
> As Python already has an excellent documentation framework, the docutils, 
> with a
> readable yet extendable markup format, reST, I thought that it should be
> possible to use those instead of the current LaTeX->latex2html toolchain.
>
> For the impatient: the result can be seen at .

Awesome, that looks pretty amazing!

I'd reeeally like to have a look at the source code (don't worry if it's
not clean!).  Can you publish or post it somewhere?  If you'd like to
store it in the Docutils sandboxes, just drop me a line and I'll give
you SVN access.  By the way, things get a lot easier for me if you place
it in the public domain, because that's the license Docutils uses, and
it's obviously compatible to every other license.

I actually have a Google Summer of Code project, "Documenting Python
Packages with Docutils", which I'll start working on May 28:
.
It has a somewhat different scope, so our projects will complement each
other nicely I believe.  (To the point where we may end up with a
complete tool-chain to actually migrate the Python documentation to
reST.  Très cool.)

Your effort and mine only seem to have some limited overlap.  I see that
you added at least some markup to reST that allows documents to be
marked up in a similar fashion as the current Python-specific LaTeX
markup, which is on my list, too.  If you see more overlap, please let
me know, because I may need to adjust my time-line or project-scope
(which is totally fine with me, by the way, so don't worry about
"getting into the way of my project" or so!).

May I suggest we continue the discussion on Doc-SIG only and prune
Python-dev from the CC?  I'm on Jabber/GoogleTalk ([EMAIL PROTECTED]),
by the way, so feel free to IM me.

Best wishes,

Lea


[Rest of the quoted message below.]

> I've written a converter tool that handles most of the LaTeX markup and turns 
> it
> into reST, as well as a builder tool that adds many custom directives and 
> roles,
> and also features like index generation and cross-document linking.
> 
> (What you can see at the URL is a completely statical version of the docs, as 
> it
> would be shipped with the distribution. For the real online docs, I have more
> plans; I'll come to that later.)
> 
> So why the effort?
> 
> Here's a partial list of things that have already been improved:
> 
> - the source is much more readable (for examples, try the "view source" links 
> in
>the left navbar)
> - all function/class/module names are properly cross-referenced
> - the HTML pages are generated from templates, using a language similar to
>Django's template language
> - Python and C code snippets are syntax highlighted
> - for the offline version, there's a JavaScript enabled search function
> - the index is generated over all the documentation, making it easier to find
>stuff you need
> - the toolchain is pure Python, therefore can easily be shipped
> 
> What more?
> 
> If there is support for this approach, I have plans for things that can be 
> added
> to the online version:
> 
> - a "quick-dispatch" function: e.g., docs.python.org/q?os.path.split would
>redirect you to the matching location.
> - "interactive patching": provide an "propose edit" link, leading to a 
> Wiki-like
>page where you can edit the source. From the result, a diff is generated,
>which can be accepted, edited or rejected by the development team. This is
>even more straightforward than plain old comments.
> - the same infrastructure could be used for developers, with automatic checkin
>into subversion.
> - of course, plain old comments can be useful too.
> 
> Concluding, a small caveat: The conversion/build tools are, of course, not
> complete yet. There are a number of XXX comments in the text, most of them
> indicate that the converter could not handle a situation -- that would have
> to be corrected once after conversion is done.
> 
> Waiting for comments!
> 
> Cheers,
> Georg
> 
> 
___
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] The docs, reloaded

[Ron Adam]

Georg Brandl wrote:
> Hi,
> 
> over the last few weeks I've hacked on a new approach to Python's 
> documentation.
> As Python already has an excellent documentation framework, the docutils, 
> with a
> readable yet extendable markup format, reST, I thought that it should be
> possible to use those instead of the current LaTeX->latex2html toolchain.
> 
> For the impatient: the result can be seen at .

Wow, very nice.  I like it.. +1

I've been working on improving pydoc. (slowly but steadily) Maybe we can 
join efforts as I think the two projects overlap in a number of areas, and 
it sounds like we are thinking of some of the same things as far as the 
tool chain.  So maybe there's some synergy we can take advantage of.

Some of the things I've recently considered adding to pydoc.

- To output individual sections for use in a template engine.
- A reST formatter.
- Use docutils to format reST doc strings to html in the html
formatter.  (as an option, not the default.)

It looks like there may be a few areas where we can share code.

- The html syntax highlighters.   (Pydoc can use those)
- A shared html style sheet.
- Document locater.  [1]
- An HTMLServer for local (dynamic dispatching) html viewing. [2]
- The reST source for viewing topics and keywords in pydoc.
  (Instead of scraping html pages. Ick)

(1.) Pydoc has a locater function which finds the html docs and presents a 
link to the html page for an individual item.  But it would be more 
reliable if the dispatcher where on the document end.  Then pydoc would 
have a single place to link to.  (Either locally or on line.)

(2.) The server in pydoc will probably work as is.  You just need to supply 
a callback to get the pages.  It's a separate module now.

Cheers,
Ron


> I've written a converter tool that handles most of the LaTeX markup and turns 
> it
> into reST, as well as a builder tool that adds many custom directives and 
> roles,
> and also features like index generation and cross-document linking.
> 
> (What you can see at the URL is a completely statical version of the docs, as 
> it
> would be shipped with the distribution. For the real online docs, I have more
> plans; I'll come to that later.)
 >
> So why the effort?
> 
> Here's a partial list of things that have already been improved:
> 
> - the source is much more readable (for examples, try the "view source" links 
> in
>the left navbar)
> - all function/class/module names are properly cross-referenced
> - the HTML pages are generated from templates, using a language similar to
>Django's template language
> - Python and C code snippets are syntax highlighted
> - for the offline version, there's a JavaScript enabled search function
> - the index is generated over all the documentation, making it easier to find
>stuff you need
> - the toolchain is pure Python, therefore can easily be shipped
> 
> What more?
> 
> If there is support for this approach, I have plans for things that can be 
> added
> to the online version:
> 
> - a "quick-dispatch" function: e.g., docs.python.org/q?os.path.split would
>redirect you to the matching location.
> - "interactive patching": provide an "propose edit" link, leading to a 
> Wiki-like
>page where you can edit the source. From the result, a diff is generated,
>which can be accepted, edited or rejected by the development team. This is
>even more straightforward than plain old comments.
> - the same infrastructure could be used for developers, with automatic checkin
>into subversion.
> - of course, plain old comments can be useful too.
> 
> Concluding, a small caveat: The conversion/build tools are, of course, not
> complete yet. There are a number of XXX comments in the text, most of them
> indicate that the converter could not handle a situation -- that would have
> to be corrected once after conversion is done.
> 
> Waiting for comments!
> 
> Cheers,
> Georg

___
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] The docs, reloaded

[Brett Cannon]

On 5/19/07, Georg Brandl <[EMAIL PROTECTED]> wrote:


Hi,

over the last few weeks I've hacked on a new approach to Python's
documentation.
As Python already has an excellent documentation framework, the docutils,
with a
readable yet extendable markup format, reST, I thought that it should be
possible to use those instead of the current LaTeX->latex2html toolchain.

For the impatient: the result can be seen at .



I really want this!


From a doc writer's perspective I find this reST approach much easier to

grapple than the LaTeX one since I find reST markup nicer for simple things
like lists and bolding.   From a committer's POV I like this as it should
hopefully get more people to help with changes and make it easy for me to
build the docs locally to make sure the markup is correct.  And from a lazy
coder's POV I love it as Georg has already done all the work (and in Python
so if I really have to change something I have a better chance of figuring
out how).

-Brett
___
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] Summary of Tracker Issues

[Tracker]

ACTIVITY SUMMARY (05/13/07 - 05/20/07)
Tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 1649 open ( +0) /  8584 closed ( +0) / 10233 total ( +0)

Average duration of open issues: 799 days.
Median duration of open issues: 750 days.

Open Issues Breakdown
   open  1649 ( +0)
pending 0 ( +0)

___
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] The docs, reloaded

[Ka-Ping Yee]

On Sat, 19 May 2007, Georg Brandl wrote:
> For the impatient: the result can be seen at .

This is extremely impressive.  Thank you for this work!

If all the documentation is generated from a base format that is
closer to text (reST instead of LaTeX), that will make it easier
for volunteers to read diffs, make edits, and contribute patches.

I agree that interactivity (online commenting and editing) will
be a huge advantage.

I could imagine this heading in a Wiki-like direction -- where a
particular version is tagged as the official revision shipped
with a particular Python release, but everyone can make edits
online to yield new versions, eventually yielding the revision
that will be released with the next Python release.


-- ?!ng
___
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] The docs, reloaded

[Talin]

Georg Brandl wrote:
> Hi,
> 
> over the last few weeks I've hacked on a new approach to Python's 
> documentation.
> As Python already has an excellent documentation framework, the docutils, 
> with a
> readable yet extendable markup format, reST, I thought that it should be
> possible to use those instead of the current LaTeX->latex2html toolchain.
> 
> For the impatient: the result can be seen at .
> 
> I've written a converter tool that handles most of the LaTeX markup and turns 
> it
> into reST, as well as a builder tool that adds many custom directives and 
> roles,
> and also features like index generation and cross-document linking.

Very impressive.

I should say that although in the past I have argued strongly against 
the use of reST as a markup language for source-code comments (because 
the reST language only indicates presentation, not semantics), I am 100% 
supportive of the use of reST in reference documents such as these, 
especially considering that LaTeX is also a presentational markup (at 
least, that's the way it tends to be used.)

I know that for myself, LaTeX has been a barrier to contributing to the 
Python documentation, and reST would be much less of a barrier. In fact, 
I have considered in the past asking whether or not the Python 
documentation could be migrated to a format with wider fluency, but I 
never actually posted on this issue because I was afraid that the answer 
would be that it's too hard / too late to do anything about it. I am 
glad to have been proven wrong.

-- Talin
___
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 Tracker Issues

[Talin]

Josiah Carlson wrote:
> Captchas like this are easily broken using computational methods, or
> even the porn site trick that was already mentioned.  Never mind
> Stephen's stated belief, that you quoted, that he believes that even the
> hard captchas are going to be beaten by computational methods soon.  Please
> try to pay attention to previous posts.

I think people are trying too hard here - in other words, they are 
putting more of computational science brainpower into the problem than 
it really merits. While it is true that there is an arms race between 
creators of social software applications and spammers, this arms race is 
only waged the largest scales - spammers simply won't spend the effort 
to go after individual sites, its not cost effective, especially when 
there are much more lucrative targets.

Generally, sites are only vulnerable when they have a comment submission 
interface that is identical to thousands of other sites. All that one 
needs to do on the web side is to make the submission process slightly 
idiosyncratic compared to other sites. If one wants to put in extra 
effort, you can change the comment submission process on a regular basis.

The real issue is comment submission via email, which I believe RoundUp 
supports (although I don't know if it's enabled for the Python tracker.) 
Because there's very little that you can do to "customize" an email 
submission interface (you have to work with standard email clients after 
all).

Do we know how these spam comments entered the system? There's no point 
in spending any thought securing the web interface if the comments were 
submitted via email.

And has there been any spam submitted since that point? If we're talking 
less than one spam a week on average, then this is all a moot point, its 
less effort for someone to just manually delete it than it is to come up 
with an automated system.

-- Talin
___
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] The docs, reloaded

[Martin Blais]

Hi Georg
Super impressive work! :-)

I haven't looked at it in depth yet, but I have a question.  One
concern from a long thread on Doc-Sig a long time ago, is that ReST
did not at the time possess the ability to nicely markup the objects
as LaTeX macros do.   Is your transformation losing markup information
from the original docs?  e.g. are you still marking classes as classes
and functions as functions in the ReST source, or is it converting
from qualified markup to "style" markup (e.g., to generic literals
instead of class/function/variable/keyword argument docutils roles,
etc.).If you solved that problem, how did you solve it?  Is the
resulting ReST pretty?  Do you think we can build a better index?

My beef with using ReST for documentation, as much as I like ReST, is
that unless we have roles and structure for declaring functions,
classes, etc. it would remain inferior to the LaTeX macros, which in
spite of being LaTeX, qualify the kinds of objects to some extent.

Wow, it looks amazingly good.  Amazing work.  Very impressed.

(Somewhat related, but another idea from back then, which was never
implemented IMO, was to find a way to automatically pull and convert
the docstrings from the source code into the documentation, thus
unifying all the information in one place.)



On 5/19/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> over the last few weeks I've hacked on a new approach to Python's 
> documentation.
> As Python already has an excellent documentation framework, the docutils, 
> with a
> readable yet extendable markup format, reST, I thought that it should be
> possible to use those instead of the current LaTeX->latex2html toolchain.
>
> For the impatient: the result can be seen at .
>
> I've written a converter tool that handles most of the LaTeX markup and turns 
> it
> into reST, as well as a builder tool that adds many custom directives and 
> roles,
> and also features like index generation and cross-document linking.
>
> (What you can see at the URL is a completely statical version of the docs, as 
> it
> would be shipped with the distribution. For the real online docs, I have more
> plans; I'll come to that later.)
>
> So why the effort?
>
> Here's a partial list of things that have already been improved:
>
> - the source is much more readable (for examples, try the "view source" links 
> in
>the left navbar)
> - all function/class/module names are properly cross-referenced
> - the HTML pages are generated from templates, using a language similar to
>Django's template language
> - Python and C code snippets are syntax highlighted
> - for the offline version, there's a JavaScript enabled search function
> - the index is generated over all the documentation, making it easier to find
>stuff you need
> - the toolchain is pure Python, therefore can easily be shipped
>
> What more?
>
> If there is support for this approach, I have plans for things that can be 
> added
> to the online version:
>
> - a "quick-dispatch" function: e.g., docs.python.org/q?os.path.split would
>redirect you to the matching location.
> - "interactive patching": provide an "propose edit" link, leading to a 
> Wiki-like
>page where you can edit the source. From the result, a diff is generated,
>which can be accepted, edited or rejected by the development team. This is
>even more straightforward than plain old comments.
> - the same infrastructure could be used for developers, with automatic checkin
>into subversion.
> - of course, plain old comments can be useful too.
>
> Concluding, a small caveat: The conversion/build tools are, of course, not
> complete yet. There are a number of XXX comments in the text, most of them
> indicate that the converter could not handle a situation -- that would have
> to be corrected once after conversion is done.
>
> Waiting for comments!
>
> Cheers,
> 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/blais%40furius.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

Re: [Python-Dev] Summary of Tracker Issues

[Ron Adam]

Talin wrote:
> Josiah Carlson wrote:
>> Captchas like this are easily broken using computational methods, or
>> even the porn site trick that was already mentioned.  Never mind
>> Stephen's stated belief, that you quoted, that he believes that even the
>> hard captchas are going to be beaten by computational methods soon.  Please
>> try to pay attention to previous posts.
> 
> I think people are trying too hard here - in other words, they are 
> putting more of computational science brainpower into the problem than 
> it really merits. While it is true that there is an arms race between 
> creators of social software applications and spammers, this arms race is 
> only waged the largest scales - spammers simply won't spend the effort 
> to go after individual sites, its not cost effective, especially when 
> there are much more lucrative targets.

[clip]

> And has there been any spam submitted since that point? If we're talking 
> less than one spam a week on average, then this is all a moot point, its 
> less effort for someone to just manually delete it than it is to come up 
> with an automated system.

I was thinking the same thing.  Once we start using it, any spam that does 
get though won't stay there very long.  At most maybe half a day, but 
likely only an hour or two. (or less)

If it becomes a frequent problem, then it is the time to put the brain 
cells to work on this.  So far we've only had one instance over how long?

Lets spend the brain power on getting it up and running first.

Cheers,
Ron

___
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] The docs, reloaded

[Steven Bethard]

On 5/19/07, Martin Blais <[EMAIL PROTECTED]> wrote:
> I haven't looked at it in depth yet, but I have a question.  One
> concern from a long thread on Doc-Sig a long time ago, is that ReST
> did not at the time possess the ability to nicely markup the objects
> as LaTeX macros do.   Is your transformation losing markup information
> from the original docs?  e.g. are you still marking classes as classes
> and functions as functions in the ReST source, or is it converting
> from qualified markup to "style" markup (e.g., to generic literals
> instead of class/function/variable/keyword argument docutils roles,
> etc.).If you solved that problem, how did you solve it?  Is the
> resulting ReST pretty?

Looking at http://pydoc.gbrandl.de/modules/collections.txt, I can see
it has markup like::

.. class:: deque([iterable])

   Returns a new deque object initialized left-to-right (using :meth:`append()`)
   with data from `iterable`.  If `iterable` is not specified, the new deque is
   empty.

.. method:: deque.append(x)

   Add `x` to the right side of the deque.

So he's clearly got some of the info in there with things like ``..
class::`` and ``:meth:``.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] Py2.6 buildouts to the set API

[Raymond Hettinger]

>> * New method (proposed by Shane Holloway):  s1.isdisjoint(s2).
>> Logically equivalent to "not s1.intersection(s2)" but has an
>> early-out if a common member is found.  

[MvL]
> I'd rather see iterator versions of the set operations. 

Interesting idea.  I'm not sure I see how to make it work.
If s|t returned an iterator, then how would s|t|u work?
Are you proposing lazy evaluation of unions, intersections,
and differences?


Raymond
___
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 Tracker Issues

[Martin v. Löwis]

> Do we know how these spam comments entered the system? 

Through the web site. Submission through email is not an
issue: you need to use a registered email address, and
those are hard to guess.

> And has there been any spam submitted since that point?

One day after the tracker was renamed to bugs.python.org, there
were 10 spam submissions, and new spam was entered at a high
rate. We then added some anti-spam measures, and now new spam
is added very infrequently.

The real problem now is that people panic when they see spam
in the tracker, demanding all kinds of immediate action, and
wondering what bastards let the spam in in the first place.

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] Py2.6 buildouts to the set API

[Martin v. Löwis]

>> I'd rather see iterator versions of the set operations. 
> 
> Interesting idea.  I'm not sure I see how to make it work.
> If s|t returned an iterator, then how would s|t|u work?

I don't think s.union(t) should return an iterator, if for
no other reason than compatibility. Instead, there might
be s.iunion(t) (or s.unioni(t), or s.iterating_union(t)).

Then, you could spell s.iunion(t.iunion(u)). iunion is
implemented as

def iunion(self, other):
  for o in self:
yield o
  for o in other:
if o not in self:
  yield o

So rather than writing

  x = a.union(b,c,d,e)

you could write

  x = set(a.iunion(b.iunion(c.iunion(d.iunion(e)

or

  x = a.union(b.iunion(c.iunion(d.iunion(e

Likewise

def iintersection(self, other):
  for o in other:
if o in self:
  yield o

> Are you proposing lazy evaluation of unions, intersections,
> and differences?

I'm not so sure about differences: union and intersections
are commutative, so one should typically be able to reorder
the evaluation so that the left operand is a true set,
and the other is the iterator. For difference, it would
be necessary that the right operand is the true set;
it couldn't be an iterator, as you need to test whether
an element of self is in the other operand.

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-3000] PEP 367: New Super

[Tim Delaney]

Phillip J. Eby wrote:
> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>> Determining the class object to use
>> '''
>>
>> The exact mechanism for associating the method with the defining
>> class is not
>> specified in this PEP, and should be chosen for maximum performance.
>> For CPython, it is suggested that the class instance be held in a
>> C-level variable
>> on the function object which is bound to one of ``NULL`` (not part
>> of a class),
>> ``Py_None`` (static method) or a class object (instance or class
>> method).
>
> Another open issue here: is the decorated class used, or the
> undecorated class?

Sorry I've taken so long to get back to you about this - had email problems.

I'm not sure what you're getting at here - are you referring to the 
decorators for classes PEP? In that case, the decorator is applied after the 
class is constructed, so it would be the undecorated class.

Are class decorators going to update the MRO? I see nothing about that in 
PEP 3129, so using the undecorated class would match the current super(cls, 
self) behaviour.

Tim Delaney 

___
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-3000] PEP 367: New Super

[Tim Delaney]

Tim Delaney wrote:
> Phillip J. Eby wrote:
>> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>>> Determining the class object to use
>>> '''
>>>
>>> The exact mechanism for associating the method with the defining
>>> class is not
>>> specified in this PEP, and should be chosen for maximum performance.
>>> For CPython, it is suggested that the class instance be held in a
>>> C-level variable
>>> on the function object which is bound to one of ``NULL`` (not part
>>> of a class),
>>> ``Py_None`` (static method) or a class object (instance or class
>>> method).
>>
>> Another open issue here: is the decorated class used, or the
>> undecorated class?
>
> Sorry I've taken so long to get back to you about this - had email
> problems.
> I'm not sure what you're getting at here - are you referring to the
> decorators for classes PEP? In that case, the decorator is applied
> after the class is constructed, so it would be the undecorated class.
>
> Are class decorators going to update the MRO? I see nothing about
> that in PEP 3129, so using the undecorated class would match the
> current super(cls, self) behaviour.

Duh - I'm an idiot. Of course, the current behaviour uses name lookup, so it 
would use the decorated class.

So the question is, should the method store the class, or the name? Looking 
up by name could pick up a totally unrelated class, but storing the 
undecorated class could miss something important in the decoration.

Tim Delaney 

___
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