Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

2011-01-09 Thread Georg Brandl 
Am 08.01.2011 23:22, schrieb Antoine Pitrou:
> On Sat, 08 Jan 2011 23:05:06 +0100
> brett.cannon  wrote:
>> +For bugs, an issue needs to:
>> +
>> +* Clearly explain the bug so it can be reproduced
>> +* All relevant platform details are included
>> +* What version(s) of Python are affected by the bug are fully known
>> +* Is there a proper unit test that can reproduce the bug?
>> +
>> +These are things anyone can help with.
> 
> FWIW, I'm really not fond of handing out triage tasks to beginners.
> First because the claim that it doesn't require any specific knowledge
> is wrong (in the case of Python, because it is a highly technical
> product; it might be right for office suites, who knows).
> Second because a newbie triager gets to interact with other newbies who
> might be very confused if they are given misleading comments or asked
> misleading (or completely irrelevant) questions.

+1.  Remember, this is not a purely hypothetical statement.

> Things may be different when the person in question has been a long-time
> community member, or has specific expertise, and is therefore able to
> communicate meaningful advice. But for true beginners, I think it would
> be much better to let them write a patch or a doc fix.

Yep.

Georg

___
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] RELEASED python-mode.el 5.2.0

2011-01-09 Thread Barry Warsaw 
On behalf of the python-mode developers I'm happy to announce the release of
python-mode.el 5.2.0.  A summary of the changes since 5.1.0 is included below.

python-mode.el is a major mode for editing Python code in Emacs and XEmacs.
This version has been supported and developed by core Python developers since
1992, and predates by many years the python.el mode that comes with GNU Emacs.
It provides many useful features, including Ken Manheimer's awesome pdbtrack
for command line debugging.

Many thanks to Andreas Roehler and Georg Brandl for the majority of the work
on this version.

You can download the python-mode.el file or the full tarball from:

https://launchpad.net/python-mode

Bugs can be filed at:

https://bugs.launchpad.net/python-mode

Enjoy,
-Barry

New in version 5.2.0


- Fixed filling of triple-quoted strings.

- Add new font-lock faces for class names and exception names.

- Do not fill when calling fill-paragraph with point in a region of code.

- Fixed font-locking of exception names in parenthesized lists.

- Fixed font-locking of decorators with arguments.

- Fixed font-locking of triple-quoted strings; single quotes appearing in
  triple-quoted strings no longer upset font-locking.

- Fixed the stack-entry regexp used by pdbtrack so that it now works with
  module-level frames.

- Do not bind C-c C-h; `py-help-at-point' is now on C-c C-e by default.

- hide-show mode is now supported.

- When shifting regions right and left, keep the region active in Emacs.



signature.asc
Description: PGP 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] Summary of Python tracker Issues

2011-01-09 Thread Michael Foord 

On 07/01/2011 17:07, Python tracker wrote:

ACTIVITY SUMMARY (2010-12-31 - 2011-01-07)
Python tracker at http://bugs.python.org/

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

Issues counts and deltas:
   open2501 (-24)
   closed 20138 (+80)
   total  22639 (+56)



Nice work everyone. :-)

At this rate we'll be down to zero open issues in only 2 years. ;-)

Michael


Open issues with patches: 1045


Issues opened (40)
==

#4188: test_threading hang when running as verbose
http://bugs.python.org/issue4188  reopened by r.david.murray

#8109: Server-side support for TLS Server Name Indication extension
http://bugs.python.org/issue8109  reopened by pitrou

#10789: Lock.acquire documentation is misleading
http://bugs.python.org/issue10789  reopened by terry.reedy

#10803: ctypes: better support of bytearray objects
http://bugs.python.org/issue10803  opened by mfxmfx

#10805: traceback.print_exception throws AttributeError when exception
http://bugs.python.org/issue10805  opened by abingham

#10808: ssl unwrap fails with Error 0
http://bugs.python.org/issue10808  opened by apollo13

#10811: sqlite segfault with generators
http://bugs.python.org/issue10811  opened by Erick.Tryzelaar

#10812: Add some posix functions
http://bugs.python.org/issue10812  opened by rosslagerwall

#10813: Suppress adding decimal point for places=0 in moneyfmt()
http://bugs.python.org/issue10813  opened by cgrohmann

#10817: urllib.request.urlretrieve never raises ContentTooShortError i
http://bugs.python.org/issue10817  opened by RC

#10818: pydoc: Remove old server and tk panel
http://bugs.python.org/issue10818  opened by haypo

#10820: 3.2 Makefile changes for versioned scripts break OS X framewor
http://bugs.python.org/issue10820  opened by ned.deily

#10822: test_getgroups failure under Solaris
http://bugs.python.org/issue10822  opened by pitrou

#10826: pass_fds sometimes fails
http://bugs.python.org/issue10826  opened by pitrou

#10827: Functions in time module should support year<  1900 when accep
http://bugs.python.org/issue10827  opened by belopolsky

#10829: PyUnicode_FromFormatV() bugs with "%" and "%%" format strings
http://bugs.python.org/issue10829  opened by haypo

#10830: PyUnicode_FromFormatV("%c") doesn't support non-BMP characters
http://bugs.python.org/issue10830  opened by haypo

#10831: PyUnicode_FromFormatV() doesn't support %li, %lli, %zi
http://bugs.python.org/issue10831  opened by haypo

#10832: Add support of bytes objects in PyBytes_FromFormatV()
http://bugs.python.org/issue10832  opened by haypo

#10833: Replace %.100s by %s in PyErr_Format(): the arbitrary limit of
http://bugs.python.org/issue10833  opened by haypo

#10834: Python 2.7 x86 fails to run in Windows 7
http://bugs.python.org/issue10834  opened by excubated

#10835: sys.executable default and altinstall
http://bugs.python.org/issue10835  opened by allan

#10836: TypeError during exception handling in urllib.request.urlretri
http://bugs.python.org/issue10836  opened by Alexandru.MoÈ^(TM)oi

#10837: Issue catching KeyboardInterrupt while reading stdin
http://bugs.python.org/issue10837  opened by Josh.Hanson

#10838: subprocess __all__ is incomplete
http://bugs.python.org/issue10838  opened by a.badger

#10839: email module should not allow some header field repetitions
http://bugs.python.org/issue10839  opened by adrien-saladin

#10841: binary stdio
http://bugs.python.org/issue10841  opened by v+python

#10842: Update third-party libraries for OS X installer builds
http://bugs.python.org/issue10842  opened by ned.deily

#10843: OS X installer: install the Tools source directory
http://bugs.python.org/issue10843  opened by ned.deily

#10845: test_multiprocessing failure under Windows
http://bugs.python.org/issue10845  opened by pitrou

#10847: Distutils drops -fno-strict-aliasing when CFLAGS are set
http://bugs.python.org/issue10847  opened by skrah

#10848: Move test.regrtest from getopt to argparse
http://bugs.python.org/issue10848  opened by brett.cannon

#10849: Backport test/__main__
http://bugs.python.org/issue10849  opened by belopolsky

#10850: inconsistent behavior concerning multiprocessing.manager.BaseM
http://bugs.python.org/issue10850  opened by chrysn

#10851: further extend ssl SNI and ciphers API
http://bugs.python.org/issue10851  opened by grooverdan

#10852: SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by defau
http://bugs.python.org/issue10852  opened by grooverdan

#10854: Output DLL name in error message of ImportError when DLL is mi
http://bugs.python.org/issue10854  opened by techtonik

#10855: wave.Wave_read.close() doesn't release file
http://bugs.python.org/issue10855  opened by pjcreath

#10856: documentation for ImportError parameters and attributes
http://bugs.python.org/issue10856  opened by techtonik

#10828: Cannot use nonascii utf8 in names of files imported from
http://bugs.python.org/issue10828  opened by ingemar



Most re

Re: [Python-Dev] Add sendfile() to core?

2011-01-09 Thread max ulidtko 
On Wed, 20 Mar 2002 14:53:58 -0500, Andrew Kuchling wrote:
| sendfile() is used when writing really high-performance Web servers,
| in order to save an unnecessary memory-to-memory copy.  Question:
| should I make up a patch to add a sendfile() wrapper to Python?

So, was this proposal rejected? If so, for what reasons?

Wrapper of such a useful call would be of great convenience, especially
considering its availability on Win32 (see Thomas Heller's notice, [1]).

Anyway, when one needs to send (arbitrarily large) files to a socket and
back, ugly and slow workarounds are born, like this one:

def copy_file(file1, file2, length, blocksize=40960):
""" Transfer exactly length bytes from one file-like object to
another """
sofar = 0
while sofar < length:
amount = blocksize if sofar + blocksize <= length \
   else length - sofar
file2.write(file1.read(amount))
sofar += amount


Using hypothetical os.sendfile() would be so much better!

The only difficulty I can see is the choice of name for the wrapper.
IMO, using "sendfile" from Linux and FreeBSD is pretty much okay; but
objections may arise.

[1] http://mail.python.org/pipermail/python-dev/2002-March/021543.html

--
Sincerely,
max ulidtko

___
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] Add sendfile() to core?

2011-01-09 Thread Antoine Pitrou 
On Sat, 08 Jan 2011 09:55:19 +0200
max ulidtko  wrote:
> On Wed, 20 Mar 2002 14:53:58 -0500, Andrew Kuchling wrote:
> | sendfile() is used when writing really high-performance Web servers,
> | in order to save an unnecessary memory-to-memory copy.  Question:
> | should I make up a patch to add a sendfile() wrapper to Python?
> 
> So, was this proposal rejected? If so, for what reasons?

I saw no patch for it, so Andrew probably didn't get to it.

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

Re: [Python-Dev] Add sendfile() to core?

2011-01-09 Thread Guido van Rossum 
Isn't that just shutil.copyfileobj()?

On Fri, Jan 7, 2011 at 11:55 PM, max ulidtko  wrote:
> On Wed, 20 Mar 2002 14:53:58 -0500, Andrew Kuchling wrote:
> | sendfile() is used when writing really high-performance Web servers,
> | in order to save an unnecessary memory-to-memory copy.  Question:
> | should I make up a patch to add a sendfile() wrapper to Python?
>
> So, was this proposal rejected? If so, for what reasons?
>
> Wrapper of such a useful call would be of great convenience, especially
> considering its availability on Win32 (see Thomas Heller's notice, [1]).
>
> Anyway, when one needs to send (arbitrarily large) files to a socket and
> back, ugly and slow workarounds are born, like this one:
>
> def copy_file(file1, file2, length, blocksize=40960):
>    """ Transfer exactly length bytes from one file-like object to
> another """
>    sofar = 0
>    while sofar < length:
>        amount = blocksize if sofar + blocksize <= length \
>                           else length - sofar
>        file2.write(file1.read(amount))
>        sofar += amount
>
>
> Using hypothetical os.sendfile() would be so much better!
>
> The only difficulty I can see is the choice of name for the wrapper.
> IMO, using "sendfile" from Linux and FreeBSD is pretty much okay; but
> objections may arise.
>
> [1] http://mail.python.org/pipermail/python-dev/2002-March/021543.html
>
> --
> Sincerely,
> max ulidtko
>
> ___
> Python-Dev mailing list
> [email protected]
> 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
[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] Add sendfile() to core?

2011-01-09 Thread Giampaolo Rodolà 
A strong +1.
Projects such as Twisted would certainly benefit from such an addiction.
I'm not sure the os module is the right place for sendfile() to land though.
Implementation between different platforms tends to vary quite a bit.
A good resource is the samba source code which contains an
implementation for all major UNIX systems.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/


2011/1/8 max ulidtko :
> On Wed, 20 Mar 2002 14:53:58 -0500, Andrew Kuchling wrote:
> | sendfile() is used when writing really high-performance Web servers,
> | in order to save an unnecessary memory-to-memory copy.  Question:
> | should I make up a patch to add a sendfile() wrapper to Python?
>
> So, was this proposal rejected? If so, for what reasons?
>
> Wrapper of such a useful call would be of great convenience, especially
> considering its availability on Win32 (see Thomas Heller's notice, [1]).
>
> Anyway, when one needs to send (arbitrarily large) files to a socket and
> back, ugly and slow workarounds are born, like this one:
>
> def copy_file(file1, file2, length, blocksize=40960):
>    """ Transfer exactly length bytes from one file-like object to
> another """
>    sofar = 0
>    while sofar < length:
>        amount = blocksize if sofar + blocksize <= length \
>                           else length - sofar
>        file2.write(file1.read(amount))
>        sofar += amount
>
>
> Using hypothetical os.sendfile() would be so much better!
>
> The only difficulty I can see is the choice of name for the wrapper.
> IMO, using "sendfile" from Linux and FreeBSD is pretty much okay; but
> objections may arise.
>
> [1] http://mail.python.org/pipermail/python-dev/2002-March/021543.html
>
> --
> Sincerely,
> max ulidtko
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.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

Re: [Python-Dev] Add sendfile() to core?

2011-01-09 Thread Antoine Pitrou 
On Sun, 9 Jan 2011 11:17:40 -0800
Guido van Rossum  wrote:
> Isn't that just shutil.copyfileobj()?

copyfileobj() still uses an user-space buffer (the Python bytes
object used in the loop).  The advantage of sendfile() is to bypass
user-space logic and do the transfer entirely in kernel.  How much it
allows to gain *in practice* on a modern capable OS such as Linux I
don't know.

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

Re: [Python-Dev] API refactoring tracker field for Python4

2011-01-09 Thread Meador Inge 
On Fri, Jan 7, 2011 at 11:20 AM, anatoly techtonik  wrote:
> This happened, because of poor bug management, where community doesn't
> play any role in determining which issues are desired.
> This mostly because of limitation of our tracker and desire of people
> to extend it to get damn "stars", module split, sorting, digging and
> tagging options.

Adding a few new features to the issue tracker isn't going to make the
forgotten changes problems (assuming that it is, indeed, a problem)
that you mentioned magically go away.  Tools alone don't fix problems,
there are people using the tools involved too, and getting people to
use tools effectively is much more difficult.  Adding more features to
a tool that is not be used effectively, just makes it be used even
less effectively.

I speak from recent experiences of helping roll out JIRA to a 50 man
engineering team.  The one regret that I have is that we turned too
many stars, bells, and whistles on instead of helping people create
good issue reports.  Some times there is very good reason to add such
features, but significant amount of data should be there backing that
decision up.  It is better to wait until the data is there pointing to
the problem.

I grabbed the following descriptions from a reply from another part of
this thread:

> Stars:
>  go http://code.google.com/p/support/issues/list
>  find Stars column
>  guess

JIRA has voting, which I have used.  However, it boils back to the
tools vs. people problem.  Enabling voting is useless if no one honors
the votes.  I have seen this happen.  You must have community support.

> Module split:
>  try to get all issues for 'os' module
>  try to subscribe to all commits for 'CGIHTTPServer'

I have myself wanted this as well before.  However, the downside is
that having more options to select from will inevitably increase the
amount of incorrect selections that are made.  Fewer choices, better
data.  I would rather have better data.

> Sorting:
> click on column titles in bug tracker search results

You can just do sorted searches, right?

> Tagging:
>  as a tracker user, try to add tag 'easy' to some easy issue

Are you suggesting that *any* tracker user be allowed to place
arbitrary tags on an issue?  If so, then I think that would be more
confusing as there would be no uniformity to the entries.  I like the
keywords in use on the tracker today better.

-- Meador
___
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] API refactoring tracker field for Python4

2011-01-09 Thread Éric Araujo 
Le 07/01/2011 19:39, Brian Curtin a écrit :
> On Fri, Jan 7, 2011 at 12:14, anatoly techtonik  wrote:
>> Module split:
>>  try to get all issues for 'os' module
> No solution for this right now, but people have suggested that we add
> drop-downs for each module. I'm -0 on that.

I proposed that on
http://wiki.python.org/moin/DesiredTrackerFeatures#new-field-for-module-package
and R. David Murray replied that this had already been brought up and
shot down numerous times on python-dev.  I’ve been unable to find those
threads.

Regards

___
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] Add sendfile() to core?

2011-01-09 Thread Martin v. Löwis 
Am 09.01.2011 21:31, schrieb Antoine Pitrou:
> On Sun, 9 Jan 2011 11:17:40 -0800
> Guido van Rossum  wrote:
>> Isn't that just shutil.copyfileobj()?
> 
> copyfileobj() still uses an user-space buffer (the Python bytes
> object used in the loop).  The advantage of sendfile() is to bypass
> user-space logic and do the transfer entirely in kernel.  How much it
> allows to gain *in practice* on a modern capable OS such as Linux I
> don't know.

There would be at least two layers of savings:
a) no Python objects would be created, and no bytecode loop would
   run the copying
b) the data are not even copied into userspace at all

My guess is that the savings of doing a) are larger than the savings
of doing b).

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] API refactoring tracker field for Python4

2011-01-09 Thread Martin v. Löwis 
> Maybe that could be fixed? Then the remaining feature would be a way
> to sort issue lists by number of nosy people, and to display the
> length of the nosy list.

http://bugs.python.org/iss...@action=search&@columns=title,id,nosy_count&status=1&@sort=-nosy_count

You can create an URL like this through the search form.

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] API refactoring tracker field for Python4

2011-01-09 Thread Antoine Pitrou 
On Sun, 09 Jan 2011 22:52:47 +0100
Éric Araujo  wrote:

> Le 07/01/2011 19:39, Brian Curtin a écrit :
> > On Fri, Jan 7, 2011 at 12:14, anatoly techtonik  wrote:
> >> Module split:
> >>  try to get all issues for 'os' module
> > No solution for this right now, but people have suggested that we add
> > drop-downs for each module. I'm -0 on that.
> 
> I proposed that on
> http://wiki.python.org/moin/DesiredTrackerFeatures#new-field-for-module-package
> and R. David Murray replied that this had already been brought up and
> shot down numerous times on python-dev.  I’ve been unable to find those
> threads.

A drop-down would be terribly cumbersome. An input field with realtime
completion would be probably better.

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

Re: [Python-Dev] devguide: Add an intermediate task of helping triage issues (not to be confused with the

2011-01-09 Thread Brett Cannon 
On Sun, Jan 9, 2011 at 00:26, Georg Brandl  wrote:
> Am 08.01.2011 23:22, schrieb Antoine Pitrou:
>> On Sat, 08 Jan 2011 23:05:06 +0100
>> brett.cannon  wrote:
>>> +For bugs, an issue needs to:
>>> +
>>> +* Clearly explain the bug so it can be reproduced
>>> +* All relevant platform details are included
>>> +* What version(s) of Python are affected by the bug are fully known
>>> +* Is there a proper unit test that can reproduce the bug?
>>> +
>>> +These are things anyone can help with.
>>
>> FWIW, I'm really not fond of handing out triage tasks to beginners.
>> First because the claim that it doesn't require any specific knowledge
>> is wrong (in the case of Python, because it is a highly technical
>> product; it might be right for office suites, who knows).
>> Second because a newbie triager gets to interact with other newbies who
>> might be very confused if they are given misleading comments or asked
>> misleading (or completely irrelevant) questions.
>
> +1.  Remember, this is not a purely hypothetical statement.

OK, so the sentence is poorly phrased, but in the list of tasks it is
labeled explicitly as intermediate when one is comfortable with the
process, not a newbie. Does that alleviate the worry you both have?

-Brett

>
>> Things may be different when the person in question has been a long-time
>> community member, or has specific expertise, and is therefore able to
>> communicate meaningful advice. But for true beginners, I think it would
>> be much better to let them write a patch or a doc fix.
>
> Yep.
>
> Georg
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
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] Add sendfile() to core?

2011-01-09 Thread James Y Knight 
If you're gonna wrap sendfile, it might be nice to also wrap the splice, tee, 
and vmsplice syscalls on linux, since they're a lot more flexible.

Also note that sendfile on BSD has a completely different signature to sendfile 
on linux. The BSD one has the rather odd functionality of a built-in writev() 
before and after the sending of the file itself, with an extra struct argument 
to specify that, while on linux, if you want to write some other buffers, 
you're just expected to call writev yourself.

James
___
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] Add sendfile() to core?

2011-01-09 Thread max ulidtko 
On Sun, 9 Jan 2011 11:17:40 -0800, Guido van Rossum wrote:
| Isn't that just shutil.copyfileobj()?
|

This function has two drawbacks. First, it copies until EOF, and has no
possibility to copy exactly N bytes from source fd (say, opened socket).
This is the reason why I (re)wrote my custom copying function - to allow
that.

The second drawback is not using huge performance bonus achievable with
sendfile(2) syscall on some unices and TransmitFile() on win32. It
allows for sending and receiving files at ethernet speeds with no CPU
load at all, because no memory copying occurs (and no Python wrapper
objects would be created for the buffers, no heap allocation, etc). All
needed I/O requests are handled inside the kernel without a single
copying of data.

Thus for e.g. FTP servers using this syscall became a standard. It would
be good if Python supported it.

P.S.
There seems to be a package which enables the sendfile support for
Linux, FreeBSD and AIX, .
Though it's available only for 2.x.

Hopefully I'll end up with a patch soon.


---
Regards,
max ulidtko

___
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] Add sendfile() to core?

2011-01-09 Thread exarkun 

On 9 Jan, 08:09 pm, [email protected] wrote:

A strong +1.
Projects such as Twisted would certainly benefit from such an 
addiction.


Eh.  There would probably be some benefits, but I don't think they would 
be very large in the majority of cases.  Also, since adding it to 2.x 
would be prohibited, it will be at least several years before Twisted 
actually benefits from its addition to the standard library.


Plus, Pavel Pergamenshchik wrapped sendfile for Twisted already many 
years ago, but no one was interested enough to actually land the change 
in trunk.


However, if it would help, I'm sure Pavel's code can be contributed to 
CPython.  If anyone would like to take a look:


http://twistedmatrix.com/trac/browser/branches/sendfile-585-4/twisted/python/test/test_sendfile.py

http://twistedmatrix.com/trac/browser/branches/sendfile-585-4/twisted/python/_sendfile.c

Jean-Paul
___
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] Add sendfile() to core?

2011-01-09 Thread Terry Reedy 

On 1/8/2011 2:55 AM, max ulidtko wrote:

On Wed, 20 Mar 2002 14:53:58 -0500, Andrew Kuchling wrote:
| sendfile() is used when writing really high-performance Web servers,
| in order to save an unnecessary memory-to-memory copy.  Question:
| should I make up a patch to add a sendfile() wrapper to Python?


There is no issue on the tracker and he apparently never did.
There is a general policy of lightly wrapping useful os calls in os.
Martin said this already in what was essentially a 'go ahead'.

Problems include os differences,


The only difficulty I can see is the choice of name for the wrapper.
IMO, using "sendfile" from Linux and FreeBSD is pretty much okay; but
objections may arise.

[1] http://mail.python.org/pipermail/python-dev/2002-March/021543.html


such as name differences (but I think *nix generally wins ;-),

and the need for 'someone' to write the patches for the appropriate 
C-coded os files: posix, nt, os2, ce. Patch write makes initial decision 
on ironing out differences.


The above was the second and last substantive answer to Andrew, as there 
was nothing much more to say.


The tracker awaits ;-). Specify, if you can, whether you think the 
windows TransmitFile or modern equivalent is sufficiently compatible 
with the *nix sendfile to be wrapped with the same API or whether you 
propose Availability: Unix only.


--
Terry Jan Reedy

___
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] API refactoring tracker field for Python4

2011-01-09 Thread Stephen J. Turnbull 
Antoine Pitrou writes:

 > A drop-down [list of modules] would be terribly cumbersome.

On the XEmacs tracker, we use a multilink with a checkbox list for the
modules field.  This allows you to type in the text field, to check
multiple boxes, and provides input checking.  In my typical usage, I
don't find this cumbersome at all; it's my preferred UI for that field.
(OTOH, I set it up, so my favorite components are all at the top. :-)

The main problem is format of the checkbox page.  By default it only
allows a limited number of entries per page, the limit is pretty low
because its formatted as a single column, and if you switch pages it
"forgets" the entries you've already checked.  This shouldn't be hard
to improve, but I haven't bothered as I have yet to hear a complaint
about it.

 > An input field with realtime completion would be probably better.

Maybe.  I've often been unable to remember the initial letter of a
package, which makes completion difficult. ;-)


___
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