Re: [Python-Dev] Googlebot and the mail.python.org python-dev archive
Guido van Rossum schrieb: > I think the better syntax would be to add site:mail.python.org to the > query, but you're right, that doesn't seem to find recent messages. > Maybe the absence of a robots.txt file on mail.python.org could be a > partial explanation? Doesn't the absence of a robots.txt mean "you may index everything"? 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Googlebot and the mail.python.org pyth on-dev archive
Georg Brandl gmx.net> writes: > > Guido van Rossum schrieb: > > I think the better syntax would be to add site:mail.python.org to the > > query, but you're right, that doesn't seem to find recent messages. > > Maybe the absence of a robots.txt file on mail.python.org could be a > > partial explanation? > > Doesn't the absence of a robots.txt mean "you may index everything"? It does. However, pages such as: http://mail.python.org/pipermail/python-dev/ (and, it seems, all other pipermail-generated archive pages) have the following HTML tag in them: which explicitly instructs Web spiders *not* to index contents nor follow links. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] What type of object mmap.read_byte should return on py3k?
Hello. I noticed mmap.read_byte returns 1-length unicode on py3k. I felt
this was strange, so I created issue on bug tracker
(http://bugs.python.org/issue5391) and Martin proposed this is suitable
for discussion on python-dev. I'll quote messages on bug tracker here.
I wrote:
On Python3000, mmap.read_byte returns str not bytes, and mmap.write_byte
accepts str. Is this intended behavior?
import mmap
m = mmap.mmap(-1, 10)
type(m.read_byte())
m.write_byte("a")
m.write_byte(b"a")
Maybe another possibility. read_byte() returns int which represents
byte, write_byte accepts int which represents byte. (Like b"abc"[0]
returns int not 1-length bytes)
Martin wrote:
Indeed, I think it should use the "b" code, instead of the "c" code.
Please discuss this on python-dev, though.
It might not be ok to backport this to 3.0, since it may break existing
code.
Furthermore, all other uses of the "c" code might need to be reconsidered.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Googlebot and the mail.python.org python-dev archive
Antoine Pitrou wrote: > Georg Brandl gmx.net> writes: >> Guido van Rossum schrieb: >>> I think the better syntax would be to add site:mail.python.org to the >>> query, but you're right, that doesn't seem to find recent messages. >>> Maybe the absence of a robots.txt file on mail.python.org could be a >>> partial explanation? >> Doesn't the absence of a robots.txt mean "you may index everything"? > > It does. > However, pages such as: > http://mail.python.org/pipermail/python-dev/ > (and, it seems, all other pipermail-generated archive pages) > have the following HTML tag in them: > > which explicitly instructs Web spiders *not* to index contents nor follow > links. That's not quite true - that meta tag says not to index the current page, but *do* follow the links to other pages. The archive page and the monthly summary pages say the same two things. Once you get down to the individual post level, then it switches around - the meta tags on those pages say to index the page and NOT to follow links. Those settings actually makes a certain amount of sense - it should encourage the actual messages to turn up in search results rather than the index pages pointing to those messages. The top-level list of mailing lists and the description pages for each list don't have the meta tag at all, so they should all be both indexed and the links followed. However, I checked on Wayback and it hasn't archived anything from mail.python.org since late 2007, suggesting there may be something about the current setup that well behaved web crawlers don't like. Is pydotorg-www still the place for website questions?* If so, I should probably take this over there... Cheers, Nick. * I ask because that list doesn't appear to have seen any traffic since May last year... -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What type of object mmap.read_byte should return on py3k?
Hirokazu Yamamoto wrote:
> Hello. I noticed mmap.read_byte returns 1-length unicode on py3k. I felt
> this was strange, so I created issue on bug tracker
> (http://bugs.python.org/issue5391) and Martin proposed this is suitable
> for discussion on python-dev. I'll quote messages on bug tracker here.
>
> I wrote:
>> On Python3000, mmap.read_byte returns str not bytes, and mmap.write_byte
>> accepts str. Is this intended behavior?
>>
> import mmap
> m = mmap.mmap(-1, 10)
> type(m.read_byte())
>>
> m.write_byte("a")
> m.write_byte(b"a")
>>
>> Maybe another possibility. read_byte() returns int which represents
>> byte, write_byte accepts int which represents byte. (Like b"abc"[0]
>> returns int not 1-length bytes)
>
> Martin wrote:
>> Indeed, I think it should use the "b" code, instead of the "c" code.
>> Please discuss this on python-dev, though.
>>
>> It might not be ok to backport this to 3.0, since it may break existing
>> code.
>
>> Furthermore, all other uses of the "c" code might need to be
>> reconsidered.
It certainly seems like mmap should be playing in an all-bytes world
(where only already encoded strings are allowed). On the specific
question of whether it would be better for read_byte()/write_byte to use
1-length bytes objects or integers, I have no strong opinion (the former
is closer to the 2.x class API, the later more consistent with the
operation of the 3.x bytes class).
However, as Martin says, it wouldn't be reasonable to backport the fixes
in this to 3.0 - the associated API changes would almost certainly break
otherwise working code.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Googlebot and the mail.python.org pyth on-dev archive
Nick Coghlan gmail.com> writes: > > > > > which explicitly instructs Web spiders *not* to index contents nor follow links. > > That's not quite true - that meta tag says not to index the current > page, but *do* follow the links to other pages. The archive page and the > monthly summary pages say the same two things. For some mysterious reason my brain had read "nofollow" in the above. Well, nevermind. cheers Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Googlebot and the mail.python.org python-dev?archive
On Sat, Feb 28, 2009 at 10:37:09AM +, Antoine Pitrou wrote: > have the following HTML tag in them: > > which explicitly instructs Web spiders *not* to index contents nor follow > links. I believe this makes spiders not index this page, but does follow links. Individual messages have "index,nofollow". --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What type of object mmap.read_byte should return on py3k?
It certainly seems like mmap should be playing in an all-bytes world
(where only already encoded strings are allowed).
Agreed.
On the specific
question of whether it would be better for read_byte()/write_byte to use
1-length bytes objects or integers, I have no strong opinion (the former
is closer to the 2.x class API, the later more consistent with the
operation of the 3.x bytes class).
Personally, I was surprised when I saw b"0123"[1] != b"1". But I don't
have strong opinion neither.
However, as Martin says, it wouldn't be reasonable to backport the fixes
in this to 3.0 - the associated API changes would almost certainly break
otherwise working code.
Agreed.
I greped py3k source tree with "c", I found another Py_BuildValue("c" in
curse module. But this function returns unicode in else clause, so
probably this is correct usage.
Modules\mmapmodule.c(207): return Py_BuildValue("c", value);
Modules\_cursesmodule.c(893): return Py_BuildValue("c", rtn);
Modules\_dbmmodule.c(380): else if ( strcmp(flags, "c") == 0 )
Modules\_ctypes\cfield.c(112): if (idict->getfunc ==
getentry("c")->getfunc) {
Modules\_ctypes\stgdict.c(459): if (dict->getfunc !=
getentry("c")->getfunc
Modules\_ctypes\_ctypes.c(1372): if (itemdict->getfunc ==
getentry("c")->getfunc) {
Modules\_ctypes\_ctypes.c(1536): if (dict && (dict->setfunc ==
getentry("c")->setfunc)) {
Modules\_ctypes\_ctypes.c(1545): if (dict && (dict->setfunc ==
getentry("c")->setfunc)) {
Modules\_ctypes\_ctypes.c(4197): if (itemdict->getfunc ==
getentry("c")->getfunc) {
Modules\_ctypes\_ctypes.c(4890): if (itemdict->getfunc ==
getentry("c")->getfunc) {
PC\os2emx\getpathp.c(128): strcat(filename, Py_OptimizeFlag ? "o" :
"c");
Python\import.c(1756): strcpy(buf+i, Py_OptimizeFlag ? "o" : "c");
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What type of object mmap.read_byte should return on py3k?
About m.read_byte(), we have two choices:
(a) Py_BuildValue("b", value) => 0
(b) Py_BuildValue("y#", &value, 1) => b"\x00"
About m.write_byte(x), we have also two choices:
(a) PyArg_ParseTuple(args, "b:write_byte", &value): write_byte(0)
(b) PyArg_ParseTuple(args, "y#:write_byte", &value, &length) and
check for length=1: write_byte(b"\x00")
(b) choices are close to Python 2.x API. But we can already use
m.read(1)->b"\x00" and m.write(b"\x00") to use byte string of 1 byte. So it
would be better to break the API and use integers, (a) choices which require
also documentation changes:
mmap.read_byte()
Returns a string of length 1 containing the character at the current file
position, and advances the file position by 1.
mmap.write_byte(byte)
Write the single-character string byte into memory at the current position
of the file pointer; the file position is advanced by 1. If the mmap was
created with ACCESS_READ, then writing to it will throw a TypeError
exception.
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What type of object mmap.read_byt e should return on py3k?
Le Saturday 28 February 2009 15:06:38 Hirokazu Yamamoto, vous avez écrit :
> I greped py3k source tree with "c", I found another Py_BuildValue("c" in
> curse module. But this function returns unicode in else clause, so
> probably this is correct usage.
I used different regex on to catch "...c..." with Py_BuildValue and
PyArg_Parse... because a function may have other arguments or specify the
function name with "...:name":
http://bugs.python.org/issue5391
It looks like msvcrt.putch(char) and msvcrt.ungetch(char) use the wrong types.
--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What type of object mmap.read_byte should return on py3k?
Victor Stinner wrote:
About m.read_byte(), we have two choices:
(a) Py_BuildValue("b", value) => 0
(b) Py_BuildValue("y#", &value, 1) => b"\x00"
About m.write_byte(x), we have also two choices:
(a) PyArg_ParseTuple(args, "b:write_byte", &value): write_byte(0)
(b) PyArg_ParseTuple(args, "y#:write_byte", &value, &length) and
check for length=1: write_byte(b"\x00")
(b) choices are close to Python 2.x API. But we can already use
m.read(1)->b"\x00" and m.write(b"\x00") to use byte string of 1 byte. So it
would be better to break the API and use integers, (a) choices which require
also documentation changes:
I'm +1 for (a) because mmap.__getitem__ already returns integer not
1-length bytes. And as I wrote in http://bugs.python.org/msg82912, it
seems that more bytes cleanup is needed in mmap
documentaion/implementation. I hope someone else will look into other
modules' ones. ;-)
___
Python-Dev mailing list
[email protected]
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 X Installer for 3.0.1 and supported versions
On 27 Feb, 2009, at 1:57, Ned Deily wrote:
In article ,
"Russell E. Owen" wrote:
I want to follow up on this a bit. In the past if the Mac Python
installer was built on a machine that did NOT have a locally
installed
Tcl/Tk then it would fail to work with a locally installed Tcl/Tk:
Python would segfault when trying to use Tkinter.
The solution was to build the Mac python installer on a machine
with a
locally installed Tcl/Tk. The resulting installer package would
work on
all systems -- with or without locally installed Tcl/Tk.
So...has this problem been worked around, or is the Mac installer
still
built on a machine that has a locally installed Tcl/Tk?
Ronald will have to answer that for sure since he built the installer
for 3.0.1.
However, it seems to be true that the most recent python.org OS X
installers will always favor a /System/Library/Frameworks/{Tcl/Tk}:
That's correct, I don't have a locally installed Tcl/Tk on my laptop
at the moment and couldn't arrange for one in time for the 3.0.1
release.
BTW. The fact that this should result in crashes when a user does have
a locally installed Tcl/Tk is new to me. The reason earlier builds of
the OSX installer were build with a locally installed Tcl/Tk is that
several Tkinter users indicated that the system version is
significantly less useful than a local install.
Most people who makes serious use of Tkinter presumably have a
locally
installed Tcl/Tk because the version that Apple provides is ancient
and
is missing many important bug fixes and performance enhancements.
Also, a somewhat related issue: Tcl/Tk 8.4 is no longer maintained.
All
development work is going on in Tcl/Tk 8.5. Presumably Apple will
transition one of these days, and at that point we may need a
separate
Mac Python installer for the older operating systems vs. the newer.
Yes, something will need to be done for that if Snow Leopard does have
newer versions.
Thanks for bringing this up!
Do Python 2.6 and 3.0 support building with Tcl/Tk 8.5? I vaguely
recall messages about issues on python-dev but don't know if those
issues were real and/or solved.
Ronald
smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Challenge: Please break this! [Now with blog post]
Guido van Rossum wrote: On Mon, Feb 23, 2009 at 3:16 PM, "Martin v. Löwis" wrote: Don't I remember the previous restricted module dying a similar "death of 1,000 cuts" before it was concluded to be unsafe at any height and abandoned? I think you are slightly misremembering. It got cut again and again, but never died. Then, new-style classes hit an artery, and it bled to death. I'm curious how this one fares. FWIW, I am remembering more about how Samuele cracked it. It had to do with getting the supervisor code to call one of its own functions with arguments provided by the sandboxed code. Tav's safelite.py doesn't seem to be directly exploitable that way because (using ctypes hacks) it *removes* some offending special methods. But that door would be at least slightly ajar with Tar's proposed patch to Python, as that doesn't remove the offending attributes (__subclasses__ etc.); it only forbids them in restricted mode. But this once again enables Samuele's hack. (Oh if I only could find the link with the actual attack -- it was quite a bit more devious than attacks linked to so far.) http://mail.python.org/pipermail/python-dev/2003-March/033978.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Googlebot and the mail.python.org python-dev archive
On Sat, Feb 28, 2009 at 09:53:10PM +1000, Nick Coghlan wrote: > Is pydotorg-www still the place for website questions?* If so, I should > probably take this over there... Just 'pydotorg' is the current list (http://mail.python.org/mailman/listinfo/pydotorg). Looking at the access logs, mail.python.org is being actively crawled: 66.249.71.119 - - [28/Feb/2009:18:32:51 +0100] "GET /pipermail/python-list/2004-June/265194.html HTTP/1.1" 304 - "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 72.30.79.38 - - [28/Feb/2009:18:32:51 +0100] "GET /pipermail/csv/2003-February/000368.html HTTP/1.0" 200 3929 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 65.55.211.30 - - [28/Feb/2009:18:32:51 +0100] "GET /pipermail/python-list/2006-May/382528.html HTTP/1.1" 200 4028 "-" "msnbot/1.1 (+http://search.msn.com/msnbot.htm)" Is it maybe that the site is just too large, so the search engines index only 10,000 messages from it? One possible solution might be to block crawling of the python-list archive; it's enormous, and already available through Google's Usenet search. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] More on Py3K urllib -- urlencode()
Hi. I've been using Py3K successfully for a while now, and have some
questions about urlencode().
1) The docs mention that items sent to urlencode() are quoted using
quote_plus(). However, instances of type "bytes" are not handled like
they are with quote_plus() because urlencode() converts the parameters
to strings first (which then puts a small "b" and single quotes around a
textual representation of the bytes). It just seems to me that
instances of type "bytes" should be passed directly to quote_plus().
That would complicate the code just a bit, but would end up being much
more intuitive and useful.
2) If urlencode() relies so heavily on quote_plus(), then why doesn't it
include the extra encoding-related parameters that quote_plus() takes?
3) Regarding the following code fragment in urlencode():
k = quote_plus(str(k))
if isinstance(v, str):
v = quote_plus(v)
l.append(k + '=' + v)
elif isinstance(v, str):
# is there a reasonable way to convert to ASCII?
# encode generates a string, but "replace" or "ignore"
# lose information and "strict" can raise UnicodeError
v = quote_plus(v.encode("ASCII","replace"))
l.append(k + '=' + v)
I don't understand how the "elif" section is invoked, as it uses the
same condition as the "if" section.
Thanks in advance for any thoughts on this issue. I could submit a
patch for urlencode() to better explain my ideas if that would be useful.
- Dan
___
Python-Dev mailing list
[email protected]
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 X Installer for 3.0.1 and supported versions
> Do Python 2.6 and 3.0 support building with Tcl/Tk 8.5? Yes, that works fine. The Windows binaries ship with 8.5, and there weren't any complaints (in this respect). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on Py3K urllib -- urlencode()
Dan Mahn wrote:
> 3) Regarding the following code fragment in urlencode():
>
>k = quote_plus(str(k))
> if isinstance(v, str):
>v = quote_plus(v)
>l.append(k + '=' + v)
>elif isinstance(v, str):
># is there a reasonable way to convert to ASCII?
># encode generates a string, but "replace" or "ignore"
># lose information and "strict" can raise UnicodeError
>v = quote_plus(v.encode("ASCII","replace"))
>l.append(k + '=' + v)
>
> I don't understand how the "elif" section is invoked, as it uses the
> same condition as the "if" section.
This looks like a 2->3 bug; clearly only the second branch should be
used in Py3K. And that "replace" is also a bug; it should signal an
error on encoding failures. It should probably catch UnicodeError and
explain the problem, which is that only Latin-1 values can be passed in
the query string. So the encode() to "ASCII" is also a mistake; it
should be "ISO-8859-1", and the "replace" should be a "strict", I think.
Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on Py3K urllib -- urlencode()
Bill Janssen wrote:
> Dan Mahn wrote:
>
> > 3) Regarding the following code fragment in urlencode():
> >
> >k = quote_plus(str(k))
> > if isinstance(v, str):
> >v = quote_plus(v)
> >l.append(k + '=' + v)
> >elif isinstance(v, str):
> ># is there a reasonable way to convert to ASCII?
> ># encode generates a string, but "replace" or "ignore"
> ># lose information and "strict" can raise UnicodeError
> >v = quote_plus(v.encode("ASCII","replace"))
> >l.append(k + '=' + v)
> >
> > I don't understand how the "elif" section is invoked, as it uses the
> > same condition as the "if" section.
>
> This looks like a 2->3 bug; clearly only the second branch should be
> used in Py3K. And that "replace" is also a bug; it should signal an
> error on encoding failures. It should probably catch UnicodeError and
> explain the problem, which is that only Latin-1 values can be passed in
> the query string. So the encode() to "ASCII" is also a mistake; it
> should be "ISO-8859-1", and the "replace" should be a "strict", I think.
Sorry! In 3.0.1, this whole thing boils down to
l.append(quote_plus(k) + '=' + quote_plus(v))
Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on Py3K urllib -- urlencode()
Bill Janssen wrote:
Bill Janssen wrote:
Dan Mahn wrote:
3) Regarding the following code fragment in urlencode():
k = quote_plus(str(k))
if isinstance(v, str):
v = quote_plus(v)
l.append(k + '=' + v)
elif isinstance(v, str):
# is there a reasonable way to convert to ASCII?
# encode generates a string, but "replace" or "ignore"
# lose information and "strict" can raise UnicodeError
v = quote_plus(v.encode("ASCII","replace"))
l.append(k + '=' + v)
I don't understand how the "elif" section is invoked, as it uses the
same condition as the "if" section.
This looks like a 2->3 bug; clearly only the second branch should be
used in Py3K. And that "replace" is also a bug; it should signal an
error on encoding failures. It should probably catch UnicodeError and
explain the problem, which is that only Latin-1 values can be passed in
the query string. So the encode() to "ASCII" is also a mistake; it
should be "ISO-8859-1", and the "replace" should be a "strict", I think.
Sorry! In 3.0.1, this whole thing boils down to
l.append(quote_plus(k) + '=' + quote_plus(v))
Bill
Thanks. Generally, I would tend to agree. I actually tried something
like that, but I found that I had inadvertently been sending numeric
values, in which case the str() was saving me. Considering that, I
would rather just see something like ...
k = quote_plus(k) if isinstance(k,(str,bytes)) else quote_plus(str(k))
if isinstance(v,(str,bytes)):
l.append(k + "=" + quote_plus(v))
else:
# just keep what's in the else
I think it would be more compatible with existing code calling
urlencode(). Additionally, I think it would be nice to allow selection
of the quote_plus() string encoding parameters, but that was one of the
other points I listed.
A similar thing could be done when "not doseq", but the handling of "v"
would be exactly like "k".
- Dan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch Ready for review
Well, what got me interested in Python was the fact that it had support for reading mail files and for the curses library. When I found out there was a need for folks to work on this module I thought I would start contributing, I would love to become a primary maintainer of this particular module, because I think writing console apps is cool (yes I know my inner nerd is showing). Maybe someday I will also create a computational geometry module that can be plugged in to Python as well, but for the time being I think I could handle working on this module. "Martin v. Löwis" wrote: > >> I am wondering what to expect next. How long will it be before it is >> applied etc. This is my first attempt to submit a patch to Python. > > Unfortunately, it may take any time between a day and five years, see > below. > >> Also, does anyone know who the main person is for running changes to the >> curses library I wanted to get guidance for implementing support for >> family >> of functions newterm, set_term, reset_term. > > The curses module is largely unmaintained; nobody is really responsible > for it (my feeling is that it also has fairly few users). Use "svn log" > to find out what people have been making changes over time; if the > commit messages indicate that they had applied patches from the bug > tracker, also try to recognize any regular non-commit contributors. > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lists%40nabble.com > > -- View this message in context: http://www.nabble.com/Patch-Ready-for-review-tp22254109p22269124.html Sent from the Python - python-dev mailing list archive at Nabble.com. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
