On Sat, May 5, 2012 at 6:49 AM, Carl Meyer wrote:
> 1) Document it and provide a tool for easily upgrading a venv in this
> situation. This may be adequate. In practice the situation is quite rare:
> 2.6.8/2.7.3 is the only actual example in the history of virtualenv that I'm
> aware of. The disad
On 5/4/2012 9:39 PM, Terry Reedy wrote:
The gist of my response is that the venv 'tail' should way the python
'dog' as little as possbile.
Yes, that was exactly my thought too. But I'm not sure the technology
permits, with Windows not having exec. On the other hand, one might
speculate abo
On 5/4/2012 11:58 PM, Glenn Linderman wrote:
On 5/4/2012 8:48 PM, Terry Reedy wrote:
CPython is developed, tested, packaged, distributed, and installed as
one unit. It is intended to be run as one package. If something caches
a copy of python.exe, it seems to me that it should check and update
a
On 5/4/2012 8:48 PM, Terry Reedy wrote:
CPython is developed, tested, packaged, distributed, and installed as
one unit. It is intended to be run as one package. If something caches
a copy of python.exe, it seems to me that it should check and update
as needed. Could venv check the file date of
On 5/4/2012 4:49 PM, Carl Meyer wrote:
Hi all,
The recent virtualenv breakage in Python 2.6.8 and 2.7.3 reveals an
issue that deserves to be explicitly addressed in PEP 405: what happens
when the system Python underlying a venv gets an in-place bugfix
upgrade. If the bugfix includes a simultaneo
On Sat, May 5, 2012 at 4:07 AM, Edward C. Jones wrote:
> /usr/include/bzlib.h
> /usr/lib/x86_64-linux-gnu/libbz2.a
> /usr/lib/x86_64-linux-gnu/libbz2.so
> /lib/x86_64-linux-gnu/libbz2.so.1
> /lib/x86_64-linux-gnu/libbz2.so.1.0
> /lib/x86_64-linux-gnu/libbz2.so.1.0.4
I have an Ubuntu Maverick 64-b
Hi all,
The recent virtualenv breakage in Python 2.6.8 and 2.7.3 reveals an
issue that deserves to be explicitly addressed in PEP 405: what happens
when the system Python underlying a venv gets an in-place bugfix
upgrade. If the bugfix includes a simultaneous change to the interpreter
and sta
On Fri, May 04, 2012 at 02:07:28PM -0400, "Edward C. Jones"
wrote:
> From the Debian website, I got the list of all the
> files in these three packages:
Don't know about amd64 arch, sorry. You can list content of a package
from command line:
dpkg [-L|--listfiles] libbz2-dev
Oleg.
--
O
On Fri, 4 May 2012 13:21:17 +0800
Senthil Kumaran wrote:
> On Thu, May 3, 2012 at 12:46 AM, Antoine Pitrou wrote:
> > Daily code coverage builds would be nice, but that's probably beyond
> > what the current infrastructure can offer. It would be nice if someone
> > wants to investigate that.
>
>
I use up-to-date Debian testing (wheezy), amd64 architecture.
I have made a "clone" of the developmental version of Python 3.3.
"make -s -j3" prints:
...
Python build finished, but the necessary bits to build these modules were
not found:
_bz2 _curses_curses_panel
_
On Fri, May 4, 2012 at 10:07 AM, Python tracker wrote:
>
> ACTIVITY SUMMARY (2012-04-27 - 2012-05-04)
> 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:
> open
I don't have the time to figure it out right now, but I'll look more
into it later.
I recently did an analysis here:
http://mail.python.org/pipermail/python-dev/2012-January/115375.html
The motivation for C++ compilation is gone meanwhile, as VS now supports
C in WinRT apps quite well. Howev
ACTIVITY SUMMARY (2012-04-27 - 2012-05-04)
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:
open3399 ( -6)
closed 23101 (+45)
total 26500 (+39)
Open issues wit
Antoine Pitrou pitrou.net> writes:
> If that's the only failing test, we can simply skip it when run from a
> venv. A non-existent argv[0] is arguably a borderline case which you
> should only encounter when e.g. embedding Python.
Actually there are four module failures: test_sys, test_packaging
On Fri, May 4, 2012 at 10:08 AM, Dirkjan Ochtman wrote:
> On Wed, May 2, 2012 at 10:43 AM, Larry Hastings wrote:
>> Do we officially support any C compilers that *don't* permit "intermingled
>> variable declarations and code"? Do we *unofficially* support any? And if
>> we do, what do we gain?
On Wed, May 2, 2012 at 10:43 AM, Larry Hastings wrote:
> Do we officially support any C compilers that *don't* permit "intermingled
> variable declarations and code"? Do we *unofficially* support any? And if
> we do, what do we gain?
This might be of interest:
http://herbsutter.com/2012/05/03/
2012/5/4 Eric V. Smith :
> On 5/4/2012 1:14 AM, benjamin.peterson wrote:
>> http://hg.python.org/cpython/rev/b0deafca6c02
>> changeset: 76743:b0deafca6c02
>> user: Benjamin Peterson
>> date: Fri May 04 01:14:03 2012 -0400
>> summary:
>> avoid unitialized memory
>>
>> files:
>>
2012/5/4 Larry Hastings :
> + if (times && (times != Py_None)) {
>
> Conditions in parenthesis like this is not style.
>
>
> Can you point me to where this is described in PEP 7? I can't find it.
It's not explicitly stated, but there is the following nice example:
if (type->tp_dictoffset != 0
On Fri, May 4, 2012 at 10:17 PM, Pierre Chanial
wrote:
> Hello,
>
> PEP 377 has been rejected for lack of use cases. Here is one.
>
> I'm writing an MPI-based application and in some cases, when there is less
> work items than processes, I need to create a new communicator excluding the
> processe
On Fri, 4 May 2012 08:44:25 + (UTC)
Vinay Sajip wrote:
> IIUC, the program name of the Python executable is set to whatever argv[0] is.
> Is there a reason for this, rather than using one of the various OS-specific
> APIs [1] for getting the name of the running executable? The reason I ask is
On Fri, 4 May 2012 13:29:14 +0100
Michael Foord wrote:
>
> On 4 May 2012, at 09:44, Vinay Sajip wrote:
>
> > IIUC, the program name of the Python executable is set to whatever argv[0]
> > is.
> > Is there a reason for this, rather than using one of the various OS-specific
> > APIs [1] for getti
Eric V. Smith writes:
> > -PyObject *divmod;
> > +PyObject *divmod = NULL;
> > divmod = PyNumber_Divmod(py_long, billion);
>
> How is that uninitialized if it's being set on the next line?
Maybe they finally developed a Sufficiently Stupid Compiler?
___
On 4 May 2012, at 09:44, Vinay Sajip wrote:
> IIUC, the program name of the Python executable is set to whatever argv[0] is.
> Is there a reason for this, rather than using one of the various OS-specific
> APIs [1] for getting the name of the running executable? The reason I ask is
> that in a vi
Hello,
PEP 377 has been rejected for lack of use cases. Here is one.
I'm writing an MPI-based application and in some cases, when there is less
work items than processes, I need to create a new communicator excluding
the processes that have nothing to do. This new communicator should finally
be f
On 05/04/2012 11:32 AM, larry.hastings wrote:
> http://hg.python.org/cpython/rev/fc5d2f4291ac
> changeset: 76747:fc5d2f4291ac
> user:Larry Hastings
> date:Fri May 04 02:31:57 2012 -0700
> summary:
> Issue #14127: Fix two bugs with the Windows implementation.
Would be nice to m
On Fri, 4 May 2012 01:07:04 -0400
Benjamin Peterson wrote:
> > + if (times && (times != Py_None)) {
>
> Conditions in parenthesis like this is not style.
If it's not style, then what is it? :-)
___
Python-Dev mailing list
Python-Dev@python.org
htt
Larry Hastings wrote:
On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
+if (times && ns) {
+PyErr_Format(PyExc_RuntimeError,
Why not a ValueError or TypeError?
Well it's certainly not a TypeError.
TypeError is not just for values of the wrong type,
it's also used for passing
benjamin.peterson wrote:
> files:
> Modules/posixmodule.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -3702,7 +3702,7 @@
> if (!PyTuple_
Larry Hastings wrote:
> On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
>
> +if (times && ns) {
> +PyErr_Format(PyExc_RuntimeError,
>
> Why not a ValueError or TypeError?
>
>
> Well it's certainly not a TypeError. The 3.2 documentation defines TypeError
> as:
benjamin.peterson wrote:
> summary:
> avoid unitialized memory
>
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -3576,7 +3576,7 @@
> split_py_long_to_s_and_ns(PyObject *py_long, time_t *s, long *ns)
> {
> int
04.05.12 02:45, Victor Stinner написав(ла):
* Two steps: compute the length and maximum character of the output
string, allocate the output string and then write characters. str%args
was using it.
* Optimistic approach. Start with a ASCII buffer, enlarge and widen
(to UCS2 and then UCS4) the
IIUC, the program name of the Python executable is set to whatever argv[0] is.
Is there a reason for this, rather than using one of the various OS-specific
APIs [1] for getting the name of the running executable? The reason I ask is
that in a virtual environment (venv), the exe's path is the only t
On 5/4/2012 1:14 AM, benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/b0deafca6c02
> changeset: 76743:b0deafca6c02
> user:Benjamin Peterson
> date:Fri May 04 01:14:03 2012 -0400
> summary:
> avoid unitialized memory
>
> files:
> Modules/posixmodule.c | 2 +-
> 1
On 04.05.2012 07:21, Senthil Kumaran wrote:
On Thu, May 3, 2012 at 12:46 AM, Antoine Pitrou wrote:
Daily code coverage builds would be nice, but that's probably beyond
what the current infrastructure can offer. It would be nice if someone
wants to investigate that.
Code coverage buildbots wou
That page would probably like a good cleanup. I don't even think
creating an user is required - it's just good practice, and you
probably want that user to have as few privileges as possible.
That's indeed the motivation. Buildbot slave operators need to
recognize that they are opening their mac
On 05/04/2012 08:04 AM, Larry Hastings wrote:
>
> On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
>>> +if (times && ns) {
>>> +PyErr_Format(PyExc_RuntimeError,
>> Why not a ValueError or TypeError?
>
> Well it's certainly not a TypeError. The 3.2 documentation defines TypeError
> a
36 matches
Mail list logo
