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 one,
[Guido van Rossum, 2011-03-02]
On Wed, Mar 2, 2011 at 4:56 AM, Piotr Ożarowski pi...@debian.org wrote:
[Sandro Tosi, 2011-03-02]
On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
I co-maintain with Matthias a package that provides /usr/bin/python
symlink in Debian
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
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) change
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:
See
On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum gu...@python.org 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
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 the
2011/3/3 Sümer Cip sum...@gmail.com:
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
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. I
On 03/03/2011 13:45, Benjamin Peterson wrote:
2011/3/3 Sümer Cipsum...@gmail.com:
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
On Thu, Mar 3, 2011 at 06:40, anatoly techtonik techto...@gmail.com wrote:
On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum gu...@python.org
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
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,
On Thu, Mar 3, 2011 at 9:05 AM, Michael Foord fuzzy...@voidspace.org.uk 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
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 pi...@debian.org wrote:
[Sandro Tosi, 2011-03-02]
On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski pi...@debian.org wrote:
I co-maintain with
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 roadmap
On Thu, Mar 3, 2011 at 4:12 PM, Brian Curtin brian.cur...@gmail.com wrote:
On Thu, Mar 3, 2011 at 06:40, anatoly techtonik techto...@gmail.com wrote:
On Sat, Feb 26, 2011 at 12:43 AM, Guido van Rossum gu...@python.org
wrote:
Now that the language moratorium is lifted, let's make sure to get
On 03/03/2011 15:09, Graham Stratton wrote:
On Mar 2, 3:01 pm, Graham Strattongrahamstrat...@gmail.com 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
On Thu, Mar 3, 2011 at 9:40 AM, MRAB pyt...@mrabarnett.plus.com wrote:
On 03/03/2011 15:09, Graham Stratton wrote:
On Mar 2, 3:01 pm, Graham Strattongrahamstrat...@gmail.com wrote:
We are using marshal for serialising objects before distributing them
around the cluster, and extremely
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 have any
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 posting
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 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
On Thu, 3 Mar 2011 09:24:29 -0800
Raymond Hettinger raymond.hettin...@gmail.com 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
On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
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 03/03/2011 21:54, anatoly techtonik wrote:
On Thu, Mar 3, 2011 at 10:44 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
On Wed, Mar 2, 2011 at 4:22 AM, Stephen J. Turnbull step...@xemacs.org 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
On Wed, Mar 2, 2011 at 5:25 AM, Westley Martínez aniko...@gmail.com 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.
___
On Wed, Mar 2, 2011 at 2:54 PM, Andrew Svetlov andrew.svet...@gmail.com 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
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 Thu, Mar 3, 2011 at 11:58 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
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 the
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
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 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
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
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).
Nitpickingly, I'd add
PEP: ???
Title: The python Utility on Unix-Like Systems
Version: ???
Last-Modified: ???
Author: Kerrick Staley mail at kerrickstaley.com
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Mar-2011
Post-History: ???
Abstract
==
This PEP provides a convention to ensure
38 matches
Mail list logo
