PEP: ???
Title: The python Utility on Unix-Like Systems
Version: ???
Last-Modified: ???
Author: Kerrick Staley
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: ???
Abstract
==
This PEP provides a convention to ensure that Python scripts can con
> LGTM. Please specify what /usr/bin/python is supposed to be also
> (rather: the "python" utility). I'd like it ruled out that
> installations *only* provide python2 and python3 - "python" could
> be either one, but should be present "normally" (i.e. SHOULD
> in the RFC 2119 sense).
>
> Nitpicking
On Thu, Mar 03, 2011 at 09:46:23PM -0500, Barry Warsaw wrote:
> On Mar 03, 2011, at 09:08 AM, Toshio Kuratomi wrote:
>
> >Thinking outside of the box, I can think of something that would satisfy
> >your requirements but I don't know how appropriate it is for upstream python
> >to ship with. Stop
On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:
> On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:
>
> >On a related note, we have a number of scripts packaged across the
> >distributions with a shebang line that reads:
> > #!/usr/bin/env python
> >which AIUI follows upstream rec
On Mar 03, 2011, at 09:08 AM, Toshio Kuratomi wrote:
>Thinking outside of the box, I can think of something that would satisfy
>your requirements but I don't know how appropriate it is for upstream python
>to ship with. Stop shipping /usr/bin/python. Ship "python" in an alternate
>location like
On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:
>On a related note, we have a number of scripts packaged across the
>distributions with a shebang line that reads:
> #!/usr/bin/env python
>which AIUI follows upstream recommendations.
Actually, I think this is *not* a good idea for distro prov
On Mar 03, 2011, at 09:55 AM, Piotr Ożarowski wrote:
>I don't really mind adding /usr/bin/python2 symlink just to clean Arch
>mess, but I do mind changing /usr/bin/python to point to python3 (and I
>can use the same argument - "Explicit is better than implicit" - if you
>need Python 3, say so in t
On Thu, Mar 3, 2011 at 11:58 PM, Michael Foord
wrote:
>>>
>>> Without this option interrupting a test run with a ctrl-c kills the run
>>> and
>>> reports nothing. Seeing an unexpected failure or error during a long test
>>> run and having to wait to the end of the test run to see the traceback
>>>
Hi,
Some months ago, I proposed a patch to display the Python backtrace on a
segfault. The API was not stable, it was too for Python 3.2, and it was
enabled by default. I wrote a module instead of a patch so it can be
used on any version of Python, and it has a better API. And now I would
like to
On Wed, Mar 2, 2011 at 2:54 PM, Andrew Svetlov wrote:
>>
>> Will Mercurial make things more attractive?
>>
> Definitely yes! I welcome upcoming migration.
>
>>> And, of course, very long lifecycle of the most issues greatly reduces
>>> enthusisasm.
>>
>> True. I believe we are improving that, but
On Wed, Mar 2, 2011 at 5:25 AM, Westley Martínez wrote:
> If I got a message like that in my mailbox I would be rather annoyed,
> mark it as spam, and be less likely to contribute again.
>
> Just my point of view.
+1
--
anatoly t.
___
Python-Dev mailing
On Wed, Mar 2, 2011 at 4:22 AM, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
>
> > Following the example given in the original article, I was considering
> > a single freeform question: "why did you stop contributing after your
> > last patch to CPython?" (of course, that text should be
On 03/03/2011 21:54, anatoly techtonik wrote:
On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord
wrote:
On 03/03/2011 20:31, anatoly techtonik wrote:
I am looking at --help of test runner and asking the question: what is
the use case for -c, --catch option?
It catches keyboard interrupt and inst
On Mar 3, 2011, at 3:55 AM, Piotr Ożarowski wrote:
> I don't really mind adding /usr/bin/python2 symlink just to clean Arch mess
Is there any chance you would add the symlink in the next Debian stable point
release? If both Debian and Python upstream added the python2 symlink in the
next stable
On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord
wrote:
> On 03/03/2011 20:31, anatoly techtonik wrote:
>>
>> I am looking at --help of test runner and asking the question: what is
>> the use case for -c, --catch option?
>
> It catches keyboard interrupt and instead of just bombing out of the test
>
On Thu, 3 Mar 2011 09:24:29 -0800
Raymond Hettinger wrote:
>
> On Mar 3, 2011, at 4:40 AM, anatoly techtonik wrote:
>
> > How about official RoadMap? There is no visibility into what's going
> > on in Python development. New people can' t jump in and help do bring
> > some features faster. http:
On 03/03/2011 20:31, anatoly techtonik wrote:
I am looking at --help of test runner and asking the question: what is
the use case for -c, --catch option?
It catches keyboard interrupt and instead of just bombing out of the
test run it reports all the results collected so far.
Without this opti
I am looking at --help of test runner and asking the question: what is
the use case for -c, --catch option? It doesn't look like it should be
present in generic runner. I also can't find reasons to waste short
option for it. There will be big problems with people complaining
about BC break even if
On Thu, 2011-03-03 at 14:17 -0500, David Malcolm wrote:
> On Wed, 2011-03-02 at 01:14 +0100, "Martin v. Löwis" wrote:
> There are a number of other rpm packages with names matching "*py*",
> which use the system build of Python 3
Gah; I meant Python 2 here.
(Must proofread my screeds before po
On Wed, 2011-03-02 at 01:14 +0100, "Martin v. Löwis" wrote:
> > I think a PEP would help, but in this case I would request that before
> > the PEP gets written (it can be a really short one!) somebody actually
> > go out and get consensus from a number of important distros. Besides
> > Barry, do we
On Thu, Mar 3, 2011 at 9:40 AM, MRAB wrote:
> On 03/03/2011 15:09, Graham Stratton wrote:
>>
>> On Mar 2, 3:01 pm, Graham Stratton wrote:
>>>
>>> We are using marshal for serialising objects before distributing them
>>> around the cluster, and extremely occasionally a corrupted marshal is
>>> pro
On 03/03/2011 15:09, Graham Stratton wrote:
On Mar 2, 3:01 pm, Graham Stratton wrote:
We are using marshal for serialising objects before distributing them
around the cluster, and extremely occasionally a corrupted marshal is
produced. The current workaround is to serialise everything twice and
On Thu, Mar 3, 2011 at 4:12 PM, Brian Curtin wrote:
> On Thu, Mar 3, 2011 at 06:40, anatoly techtonik wrote:
>>
>> On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum
>> wrote:
>> > Now that the language moratorium is lifted, let's make sure to get PEP
>> > 380 implemented for Python 3.3.
>>
>> H
On Mar 3, 2011, at 4:40 AM, anatoly techtonik wrote:
> How about official RoadMap? There is no visibility into what's going
> on in Python development. New people can' t jump in and help do bring
> some features faster. http://dungeonhack.sourceforge.net/Roadmap
Thanks for the link. Their roadm
On Thu, Mar 03, 2011 at 09:55:25AM +0100, Piotr Ożarowski wrote:
> [Guido van Rossum, 2011-03-02]
> > On Wed, Mar 2, 2011 at 4:56 AM, Piotr Ożarowski wrote:
> > > [Sandro Tosi, 2011-03-02]
> > >> On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski wrote:
> > >> > I co-maintain with Matthias a package t
On Thu, Mar 3, 2011 at 9:05 AM, Michael Foord wrote:
..
> I think its fair enough to point out the inconsistency in python-dev
> declaring that authors *should not* use certain parts of the C-API in
> extensions whilst using them in the extensions python-dev is responsible
> for...
This is not a
A project roadmap is usually something that a team commits to, with
some caveats, in order to give the customers (the "outside world")
some view in development that is already planned or under way or on
some other way committed to.
But a roadmap itself takes effort to create and maintain. Also, of
On Thu, Mar 3, 2011 at 06:40, anatoly techtonik wrote:
> On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum
> wrote:
> > Now that the language moratorium is lifted, let's make sure to get PEP
> > 380 implemented for Python 3.3.
>
> How about official RoadMap? There is no visibility into what's g
On 03/03/2011 13:45, Benjamin Peterson wrote:
2011/3/3 Sümer Cip:
1) define PyModuleDef
2) change PyString_AS_STRING calls to _PyUnicode_AsString
Aside: Please don't use private APIs in Python extensions. Esp.
the above Unicode API is likely going to be phased out.
You're better off, using Py
>
> I'm not sure why what C-API is used in Python's extension modules
> needs to be anyway to you.
>
I just tought it is a better programming practice to decrease/narrow inter
modular usage of functions inside the whole dist. and also a good example
for the other 3rd party C Extension developers.
2011/3/3 Sümer Cip :
>
>> >
>> > 1) define PyModuleDef
>> > 2) change PyString_AS_STRING calls to _PyUnicode_AsString
>>
>> Aside: Please don't use private APIs in Python extensions. Esp.
>> the above Unicode API is likely going to be phased out.
>>
>> You're better off, using PyUnicode_AsUTF8Stri
> >
> > 1) define PyModuleDef
> > 2) change PyString_AS_STRING calls to _PyUnicode_AsString
>
> Aside: Please don't use private APIs in Python extensions. Esp.
> the above Unicode API is likely going to be phased out.
>
> You're better off, using PyUnicode_AsUTF8String() instead and
> then leaving
On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum wrote:
> Now that the language moratorium is lifted, let's make sure to get PEP
> 380 implemented for Python 3.3.
How about official RoadMap? There is no visibility into what's going
on in Python development. New people can' t jump in and help do
Le jeudi 03 mars 2011 à 11:06 +0200, Sümer Cip a écrit :
> While porting a C extension from 2 to 3, I realized that there are some
> general cases which can be automated. For example, for my specific
> application (yappi - http://code.google.com/p/yappi/), all I need to do is
> following things:
S
Sümer Cip wrote:
> Hi,
>
> While porting a C extension from 2 to 3, I realized that there are some
> general cases which can be automated. For example, for my specific
> application (yappi - http://code.google.com/p/yappi/), all I need to do is
> following things:
>
> 1) define PyModuleDef
> 2) c
Hi,
While porting a C extension from 2 to 3, I realized that there are some
general cases which can be automated. For example, for my specific
application (yappi - http://code.google.com/p/yappi/), all I need to do is
following things:
1) define PyModuleDef
2) change PyString_AS_STRING calls to
[Guido van Rossum, 2011-03-02]
> On Wed, Mar 2, 2011 at 4:56 AM, Piotr Ożarowski wrote:
> > [Sandro Tosi, 2011-03-02]
> >> On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski wrote:
> >> > I co-maintain with Matthias a package that provides /usr/bin/python
> >> > symlink in Debian and I can confirm tha
> Here is a draft PEP (forgive me if it's incorrectly formatted; I've
> never done this before).
LGTM. Please specify what /usr/bin/python is supposed to be also
(rather: the "python" utility). I'd like it ruled out that
installations *only* provide python2 and python3 - "python" could
be either o
38 matches
Mail list logo
