[Python-Dev] DRAFT: pydev summary for 2006-12-01 to 2006-12-15

[Calvin Spealman]

=
Announcements
=

Some of you may know that Steven Bethard, having taken over the summaries from
Brett Cannon some time ago, is no longer able to keep up with them. After much
holiday stress and busy days, I've come to take over this honor and archive all
the goings on here. I hope I can do a good job, and allow the summaries to
continue being a useful and transparent fixture.

Also, after catching up with my backlog of summary work, I plan to begin the
first summaries of python-3000 (and, possibly, but not likely, the python-
ideas list), as more and more actual work, rather than debating and theory-talk,
is going on there.

Sincerly,
Your new summary writer,
Calvin Spealman

=
Summaries
=

-
[NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
-

Subscripting re match objects directly was proposed and the debate the waged
mostly on how to deal with slicing and m.group(0) to be the entire match. The
consensus seemed to be that returning a match object would break, largely
because m[1:2][0] != m[1], which breaks intuition with slices. Returning a list
as a slice also breaks the intuitions about the type of a slice.

Contributing thread:

- `a feature i'd like to see in python #2: indexing of match objects
`__


Python and the Linux Standard Base (LSB)


Discussions about how to properly document the expected Python environment for
all LSB compliant distributions continued shortly. Focus was on how distros have
a need to split the standard library up, even if the entire thing is eventually
installed, and issues such as Tkinter requiring X leading to standard modules
being ommitted for flexable packages.

Contributing thread:

- `Python and the Linux Standard Base (LSB)
`__

--
[Python-checkins] MSI being downloaded 10x more than all other files?!
--

Guido was impressed with out download numbers on Windows, but most people just
attributed it to other platforms including and mirroring Python. Even taking
that to consideration, the ratio of Windows to source downloads has shifted in
Windows favor a good bit. The use of Python in introductory courses at MIT was
mentioned as something to push these numbers further in the near future.

Contributing thread:

- `[Python-checkins] MSI being downloaded 10x more than all other
files?! 
`__


a feature i'd like to see in python #1: better iteration control


The request was made to allow direct deletion of items from iterables through
the iterator, but the idea was deemed unscalable to iterables in general and
broken with dictionaries. The solutions to work around the problem were given
and generally agreed to be sufficient (such as copying all the items you want
to keep, instead).

Contributing thread:

- `a feature i'd like to see in python #1: better iteration control
`__

-
LSB: Binary compatibility
-

The other side of the LSB issue was discussed, related to the CPython ABI, the
.pyc bytecode and the marshall formats, and exactly which versions of Python
may or may not gain a standard ABI, as well as how to carry this forward to
future (already existing and evolving) version of Python. Some mention was made
of the difficulties and conflicts being brought on by the idea of LSB standards
for Python, while the benefits of this were challenged.

Contributing thread:

- `LSB: Binary compatibility
`__


Adding resume (206) support to urllib(2)


Daniel Watkins asked about adapting his HTTP resuming support into urllib, but
suggestions directly moved this to urllib2 and then to httplib. The conversation
quickly drifted into talking about how abstract and minimal the urllib(2) should
be, while the httplib module may grow increasing complex and feature supporting.
The original poster made no final comment on his intentions to follow through
with the patch.

Contributing thread:

- `Adding resume (206) support to urllib(2)
`__

---
__str__ and unicode
---

Re: [Python-Dev] Bug or not? Different behaviour iterating list and collections.deque

[Christos Georgiou]

""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Christos Georgiou schrieb:
>> Is that intentional?
>
> It would have helped if you had said what "that" is you are referring
> to, it would also have helped if you had stated an opinion on whether
> you believe that to be a bug. For example, I think I would have phrased
> your post like this:

Yes, you are correct: I see now that I was too cryptic, but being cryptic 
was not my intention; instead, I wanted to avoid a discussion on the issue 
of the algorithm, which I didn't manage to avoid, so obviously my terseness 
was mistaken. I should be clear from the start.

In retrospection, the example code I chose, although it showed the two 
issues I thought important ('list / deque iteration discrepancy' and 'empty 
/ non-empty deque iteration discrepancy') was not as plain as needed, since 
it gave to Josiah, at least, the impression that the matter was about list / 
deque merging.

> """
> If I apply .next() to an iter of a deque that has been modified, I
> get a RuntimeError:
>
> py> d=collections.deque()
> py> d.append(10)
> py> i=iter(d)
> py> d.append(10)
> py> i.next()
> Traceback (most recent call last):
>  File "", line 1, in ?
> RuntimeError: deque mutated during iteration
>
> Yet when I apply .next() to an iter of an initially-empty deque,
> I get StopIteration:
>
> py> d=collections.deque()
> py> i=iter(d)
> py> d.append(10)
> py> i.next()
> Traceback (most recent call last):
>  File "", line 1, in ?
> StopIteration
>
> Is this a bug? Shouldn't the second example also raise the RuntimeError
> as the deque has been modified?
> (also, is appending an element a modification or a mutation?)
> """
>
> To this question (.next on an iterator of a modified deque), my answer
> would be: "yes, that is a bug".

Yes. This behaviour was meant to be shown with the 'special_case' check. I 
will open a bug for this.

> However, I feel you are referring to a different issue, unfortunately,
> I cannot tell from your post what that issue is.

No, you managed to capture large part of the essence of what I was saying, 
but again, this was not your responsibility, but mine. I should be more 
explicit.

Thank you. 


___
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] Pydoc Improvements / Rewrite

[Laurent Gautier]

2007/1/7, Ron Adam <[EMAIL PROTECTED]>:
> Laurent Gautier wrote:
> > 2007/1/6, Ron Adam <[EMAIL PROTECTED]>:
[...]
> I'd like to know more about using the sandbox, I know it would be easy for
> people to read the source there, but who all can have write access to it 
> without
> having write access to other python areas?  I would not mind giving that a try
> if someone who already knows how could point me to the correct how-to
> documentation with some advice on what not to do.

Limiting where different people can commit code changes is possible... it's
just that I am not certain whether sourceforge allows it or not.
I asked A.M. Kuchling about that.

> I'm actually more concerned about the what not to do stuff.  I really would 
> not
> like to clobber someone else's work or create problems because of my
> inexperience with CVS.

I see that you are under Microsoft windows, so you may want to check
TortoiseSVN.
(The python project is stored on a SVN server, so it would make sense
to favor this  one over CVS - in the case the project administrators
have directory-level control -).

Regarding the possibility of jeopardizing something in the repository,
the directory-level sandbox should only allow you trash your own work
;-)
(but even then, you should always be able to recover from mistakes).

>
> >[...]
>
> >> If someone who has more experience with group projects would like to
> >> manage it,
> >> that would be good too.  That may speed things up considerably.
> >
> > I have some experience in it (in companies, and in an open source project)
> > I can always file a application for a sourceforge project,
> > and can help you with managing it until you feel like taking it on your own
> > (or it is merged with the python trunk)
>
> I don't see this as taking a long time if we keep it to cleaning up with some
> API and user interface improvements.

That's all in the meaning of "some" I guess... ;-)

> I know there are some here who want a smart parsing engine, which probably 
> would
> take a long term commitment to maintain and fix bugs, etc.  But lets look at 
> the
> actual use's that pydoc serves first.
>
> Use's for pydoc in order of importance and frequency of use:
>
> 1. Console (builtin) help.  ie.. the help() function.
> 2. HTML browsing and quick reference.
> 3. Document generation in text.
> 4. Document generation in html.
> 5. Document generation in other formats.  (not currently possible)
>
> I'm concentrating on 1 and 2.  Use cases 3 and 4 are just an easy to do
> byproduct of doing 1 and 2.  I think the cleaning up may make doing 5 
> possible.

I am fully on that line, with the remark that thinking about point 5
early is that
could make the cut. The exercise will be in avoiding over-complication
in a design that is not used in the end.

Reactions on this thread brought a lot of good ideas and pointers to
existing work.
It loo


> Lets turn the question around.  How well would other document generators 
> supply
> pydoc with the equivalent text of the help() function, interactive help 
> session
> output, and the equivalent html needed for dynamic html browsing?
>
> Also keep in mind the help function is always by default imported into python,
> so keeping that small and relatively simple with a minimum of external
> dependencies is good.
>
>
>  > I am willing to contribute to the implementation (I suspect that
>  > things like unit tests be needed).
>
> Yes, there will need to be some unit tests.  It may even help for those be
> written now.  That would help us identify things that still need to be done.

Regarding tests, it is never early enough to think about them (that
let one write
code that is actually "test-able").

>
> [...]
___
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] Pydoc Improvements / Rewrite

[Ron Adam]

Laurent Gautier wrote:
> 2007/1/7, Ron Adam <[EMAIL PROTECTED]>:
>> Laurent Gautier wrote:
>> > 2007/1/6, Ron Adam <[EMAIL PROTECTED]>:
> [...]
>> I'd like to know more about using the sandbox, I know it would be easy 
>> for
>> people to read the source there, but who all can have write access to 
>> it without
>> having write access to other python areas?  I would not mind giving 
>> that a try
>> if someone who already knows how could point me to the correct how-to
>> documentation with some advice on what not to do.
> 
> Limiting where different people can commit code changes is possible... it's
> just that I am not certain whether sourceforge allows it or not.
> I asked A.M. Kuchling about that.

I'm not concerned about limiting changes to this project.  I want others to 
work 
on it.  Can write access be *easily* granted to just one cvs sandbox directory, 
for this project, without granting access to other directories in the sandbox 
or 
trunk?

>> I'm actually more concerned about the what not to do stuff.  I really 
>> would not
>> like to clobber someone else's work or create problems because of my
>> inexperience with CVS.
> 
> I see that you are under Microsoft windows, so you may want to check
> TortoiseSVN.
> (The python project is stored on a SVN server, so it would make sense
> to favor this  one over CVS - in the case the project administrators
> have directory-level control -).

Thank's I'll try TortoiseSVN out. :-)


> Regarding the possibility of jeopardizing something in the repository,
> the directory-level sandbox should only allow you trash your own work
> ;-)
> (but even then, you should always be able to recover from mistakes).

That would be fine then.  But I'll let you decide since you are offering to 
manage getting it set up.


>> >[...]
>>
>> >> If someone who has more experience with group projects would like to
>> >> manage it,
>> >> that would be good too.  That may speed things up considerably.
>> >
>> > I have some experience in it (in companies, and in an open source 
>> project)
>> > I can always file a application for a sourceforge project,
>> > and can help you with managing it until you feel like taking it on 
>> your own
>> > (or it is merged with the python trunk)
>>
>> I don't see this as taking a long time if we keep it to cleaning up 
>> with some
>> API and user interface improvements.
> 
> That's all in the meaning of "some" I guess... ;-)

Yep.

>> I know there are some here who want a smart parsing engine, which 
>> probably would
>> take a long term commitment to maintain and fix bugs, etc.  But lets 
>> look at the
>> actual use's that pydoc serves first.
>>
>> Use's for pydoc in order of importance and frequency of use:
>>
>> 1. Console (builtin) help.  ie.. the help() function.
>> 2. HTML browsing and quick reference.
>> 3. Document generation in text.
>> 4. Document generation in html.
>> 5. Document generation in other formats.  (not currently possible)
>>
>> I'm concentrating on 1 and 2.  Use cases 3 and 4 are just an easy to do
>> byproduct of doing 1 and 2.  I think the cleaning up may make doing 5 
>> possible.
> 
> I am fully on that line, with the remark that thinking about point 5
> early is that
> could make the cut. The exercise will be in avoiding over-complication
> in a design that is not used in the end.
> 
> Reactions on this thread brought a lot of good ideas and pointers to
> existing work.
> It loo

Yes, It does help to have additional view points and references.


>> Lets turn the question around.  How well would other document 
>> generators supply
>> pydoc with the equivalent text of the help() function, interactive 
>> help session
>> output, and the equivalent html needed for dynamic html browsing?
>>
>> Also keep in mind the help function is always by default imported into 
>> python,
>> so keeping that small and relatively simple with a minimum of external
>> dependencies is good.
>>
>>
>>  > I am willing to contribute to the implementation (I suspect that
>>  > things like unit tests be needed).
>>
>> Yes, there will need to be some unit tests.  It may even help for 
>> those be
>> written now.  That would help us identify things that still need to be 
>> done.
> 
> Regarding tests, it is never early enough to think about them (that
> let one write
> code that is actually "test-able").

Right, and thanks for taking more than a casual interest in this. :-)

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] Pydoc Improvements / Rewrite

[Steve Holden]

Ron Adam wrote:
> Laurent Gautier wrote:
>> 2007/1/7, Ron Adam <[EMAIL PROTECTED]>:
>>> Laurent Gautier wrote:
 2007/1/6, Ron Adam <[EMAIL PROTECTED]>:
>> [...]
>>> I'd like to know more about using the sandbox, I know it would be easy 
>>> for
>>> people to read the source there, but who all can have write access to 
>>> it without
>>> having write access to other python areas?  I would not mind giving 
>>> that a try
>>> if someone who already knows how could point me to the correct how-to
>>> documentation with some advice on what not to do.
>> Limiting where different people can commit code changes is possible... it's
>> just that I am not certain whether sourceforge allows it or not.
>> I asked A.M. Kuchling about that.
> 
> I'm not concerned about limiting changes to this project.  I want others to 
> work 
> on it.  Can write access be *easily* granted to just one cvs sandbox 
> directory, 
> for this project, without granting access to other directories in the sandbox 
> or 
> trunk?
> 
An alternative is just to trust people only to scribble in the sandbox. 
I really don't think we have a bog security issue here as long as the 
individuals are "known the the community" (or should that be "known to 
the PSU"?).

After all, it *is* a configuration control system, which by definition 
can revert to previous content in the event of some unwanted change.

>>> I'm actually more concerned about the what not to do stuff.  I really 
>>> would not
>>> like to clobber someone else's work or create problems because of my
>>> inexperience with CVS.
>> I see that you are under Microsoft windows, so you may want to check
>> TortoiseSVN.
>> (The python project is stored on a SVN server, so it would make sense
>> to favor this  one over CVS - in the case the project administrators
>> have directory-level control -).
> 
> Thank's I'll try TortoiseSVN out. :-)
> 
I can heartily recommend it.
> 
>> Regarding the possibility of jeopardizing something in the repository,
>> the directory-level sandbox should only allow you trash your own work
>> ;-)
>> (but even then, you should always be able to recover from mistakes).
> 
> That would be fine then.  But I'll let you decide since you are offering to 
> manage getting it set up.
>
[ ... ]

Let's not spend too much time on paranoid administration, since we are 
supposed to be an open source community :)

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd  http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note:  http://holdenweb.blogspot.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] Bug or not? Different behaviour iterating list andcollections.deque

[Raymond Hettinger]

"Christos Georgiou"
> In retrospection, the example code I chose, although it showed the two
> issues I thought important ('list / deque iteration discrepancy' and 'empty 
> / non-empty deque iteration discrepancy') was not as plain as needed, ...

Lists are unique in the way they allow mutation during iteration because
indexed lookup allows for a meaningful definition of what should be
done as the list mutates.

In contrast, deques are more like dictionaries and should not be mutated
during iteration.  The issue is that a deque could be so substantially
modified that there is not a clear, meaningful, and useful definition of what
item should be next served-up.

With respect to the second question, please assign an SF report to me
and I'll look at it in detail when I have time.  It appears to be an
idiosyncracy resulting from the ordering of the test for StopIteration
versus the test for RuntimeError.  The question is whether I can swap
the test order without introducing other anomalies.

Raymond



P.S.  The patch would look like this:

Index: collectionsmodule.c
===
--- collectionsmodule.c (revision 53281)
+++ collectionsmodule.c (working copy)
@@ -911,15 +911,14 @@
 {
PyObject *item;

-   if (it->counter == 0)
-   return NULL;
-
if (it->deque->state != it->state) {
it->counter = 0;
PyErr_SetString(PyExc_RuntimeError,
"deque mutated during iteration");
return NULL;
}
+   if (it->counter == 0)
+   return NULL;
assert (!(it->b == it->deque->rightblock &&
  it->index > it->deque->rightindex));
___
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