Re: [Python-Dev] Expose Subversion revision number to Python

[Martin v. Löwis]

Phillip J. Eby wrote:
> Only if you do an "svn update" immediately after *every* "svn commit". 
> Otherwise, the code base reflected will be a version *before* your
> changes.  This is fragile, since not everyone will know (or remember!)
> to do this.

That's true. It would be fairly reliable only for people without
commit access (although they still could checkout different revisions
for, say, Objects and Modules).

A revision number can't take the fact into account that you may
have local modifications, anyway.

> Thus, I'm -1 on including a revision number that will be frequently
> wrong (high *or* low) in practice.  If it's too "expensive" to do it
> right, it's *definitely* too expensive to do it wrong.  :)

Ok, understood. I'm -0 for this patch, because of the subtleties.
I think I would be -1 for a patch that noticably increases the
build time just to get some "better" single-revision number:
that *still* won't tell you what precise sources had been used
to build the binary, as different files simply can be on different
revisions, and no single number, in whatever way computed, can
give you full information.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Expose Subversion revision number to Python

[Martin v. Löwis]

Armin Rigo wrote:
> If you meant that the following situation is possible:
> 
> trunk$  svn up
> At revision xxx.
> trunk$  svn info
> Last Changed Rev: 1
> trunk$  cd Python
> trunk/python$  svn info
> Last Changed Rev: 10001
> 
> then I object.  As far as I can tell this is not possible.

It is possible:
svn up -r 1
cd Python
svn up -r 10001

(assuming Python changed in 10001).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Expose Subversion revision number to Python

[Armin Rigo]

Hi Martin,

On Sat, Dec 17, 2005 at 11:32:54AM +0100, "Martin v. L?wis" wrote:
> > trunk$  svn up
> > At revision xxx.
> > trunk$  svn info
> > Last Changed Rev: 1
> > trunk$  cd Python
> > trunk/python$  svn info
> > Last Changed Rev: 10001
> 
> It is possible:
> svn up -r 1
> cd Python
> svn up -r 10001
> 
> (assuming Python changed in 10001).

No, I know about this.  I meant -- obviously, I'd have expected... --
precisely the sequence of commands that my example shows: the operation
of doing only a plain 'svn up' in the root directory and nothing more --
which is what most people should do -- cannot leave a subdirectory's
Last Changed Rev higher than the root's.


A bientot,

Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Test branch for ssize_t changes

[martin]

I just created a branch for the ssize_t changes I had been working on
for a while. I hope to follow up with a PEP quickly.

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Expose Subversion revision number to Python

[Michael Hudson]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> that *still* won't tell you what precise sources had been used
> to build the binary, as different files simply can be on different
> revisions, and no single number, in whatever way computed, can
> give you full information.

A tangential point is that presumably source distributions will be
built from an 'svn export' and thus won't have any revision
information in, which in turns means that a Python built from such a
distribution will not have any revision information.  This seems
rather far from ideal, as I'd guess most Pythons (e.g. Debian's) are
built this way. For a different approach, would it be possible to have
a subversion trigger put the revision number into some file in the
repository?

Cheers,
mwh

-- 
  On the other hand, the following areas are subject to boycott
  in reaction to the rampant impurity of design or execution, as
  determined after a period of study, in no particular order:
...  http://www.naggum.no/profile.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Expose Subversion revision number to Python

[Martin v. Löwis]

Armin Rigo wrote:
> No, I know about this.  I meant -- obviously, I'd have expected... --
> precisely the sequence of commands that my example shows:

I still managed to miss that point :-( My fault, you are right.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Expose Subversion revision number to Python

[Martin v. Löwis]

Michael Hudson wrote:
> For a different approach, would it be possible to have
> a subversion trigger put the revision number into some file in the
> repository?

Not easily, to my knowledge. Assuming that the export will be made
from a tag, the revision at which the tag was created (along with
the path of the tag) could be added through a wrapper script to
perform the export.

Of course, if the policy to export from a tag is followed, *just*
having the tag name is also sufficient.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Expose Subversion revision number to Python

[Barry Warsaw]

On Fri, 2005-12-16 at 17:11 -0500, Phillip J. Eby wrote:

> It looks like using 'svnversion -c . | cut -f2 -d":"' would get the 
> most-recent committed version, plus the letter "M" if there are local 
> changes.  That sounds like what we should be using.
> 
> That way, a build with local revisions would include "M", thus nicely 
> addressing that issue as well.

I didn't know about svnversion, but that does seem like the right thing
to use.  One downside is that it can take a long time on a big tree, but
in my own limited testing, that doesn't seem like a practical concern
for the Python source checkout.

AFAICT, the reason to use -c is so that changes outside the Python
source tree (i.e. in the sandbox) won't show up in Python's build
number.  That's fine although I wouldn't mind leaving off the -c since
you'll still get the same snapshot of code from a revisioned checkout
either way, and that's my primary interest.

Because the 'M' can show up in the build number (and is useful
information), then I'll change the C API and sys attribute to be a
string instead of an int.

Other than that, it sounds like this is a generally acceptable change to
make to the build process, so I'll make the above modifications and
commit it.

Thanks everyone,
-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Expose Subversion revision number to Python

[Martin v. Löwis]

Barry Warsaw wrote:
> AFAICT, the reason to use -c is so that changes outside the Python
> source tree (i.e. in the sandbox) won't show up in Python's build
> number.  That's fine although I wouldn't mind leaving off the -c since
> you'll still get the same snapshot of code from a revisioned checkout
> either way, and that's my primary interest.

I think the -c should be omitted, as should be any attempts to cut(1)
this information. It's there for a reason.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] DRAFT: python-dev summary for 2005-11-16 to 2005-11-31

[Steven Bethard]

Here's the summary for the first half of November -- sorry for the bit
of a delay.  As always, let me or Tony know if you have any
corrections!


=
Summary Announcements
=

--
Reminder: Python is now on Subversion!
--

Don't forget that the Python source code is now hosted on
svn.python.org as a Subversion (rather than CVS) repository.

Note that because of the way the subversion conversion was done,
by-date revision specifications for dates prior to the switchover
won't work.  To work around this, you can use svn diff (find the
changes since some date), svn up (check out revision a some date), and
svn annotate (aka svn blame).

Removing the CVS repository from sourceforge isn't possible without
hacks (as a result of their "open source never goes away" policy). 
However, it's no longer available from the project page, and the
repository is now filled with files pointing people to the new
repository.

Contributing threads:

- `Is some magic required to check out new files from svn?
`__
- `svn diff -r {2001-01-01}
`__
- `CVS repository mostly closed now
`__

[TAM]

=
Summaries
=


Memory management in the AST


Thomas Lee's attempt to implement `PEP 341`_ brought up some issues
about working with the new AST code. Because the AST code used its own
custom objects instead of PyObjects, it also introduced its own set of
allocation/deallocation functions instead of the existing Py_INCREF
and Py_DECREF. There was some discussion about how best to simplify
the scheme, with the two main suggestions being:

(1) Convert all AST objects into PyObjects so Py_INCREF and Py_DECREF work
(2) Create an arena API, where objects are added to the arena and then
can be freed in one shot when the arena is freed

Neal Norwitz presented an example from the current AST code using the
various asdl_*_free functions, and he, Greg Ewing and Martin v. Löwis
compared how the code would look with the various API suggestions. 
While using ref-counting had the benefit of being consistent with the
rest of Python, there were still some who felt that the arena API
would simplify things enough to make the extra learning curve
worthwhile.  It seemed likely that branches or patches for the various
APIs would appear shortly.

While the C API is still undergoing these changes, and thus the Python
API is still a ways off, a few implementations for the Python API were
suggested.  If the AST code ends up using PyObjects, these could be
passed directly to Python code, though they would probably have to be
immutable.  Brett Cannon suggested that another route would be a
simple PyString marshalling like the current parser module, so that
Python code and C code would never share the same objects.

.. _PEP 341: http://www.python.org/peps/pep-0341.html

Contributing threads:

- `Memory management in the AST parser & compiler
`__
- `ast status, memory leaks, etc
`__
- `a Python interface for the AST (WAS: DRAFT: python-dev...)
`__

[SJB]

---
Profilers in the stdlib
---

Armin Rigo summarised the current Python profiler situation, which
includes profile.Profile (ages-old, slow, pure Python profiler with
limited support for profiling C calls), hotshot (Python 2.2+, faster
than profile.py, but very slow to convert the log file to the
pstats.Stats format, possibly inaccurate, doesn't know about C calls),
and `lsprof`_ (Brett Rosen, Ted Czotter, Michael Hudson, Armin Rigo;
doesn't support C calls, incompatible interface with
profile.py/hotshot, can record detailed stats about children).  He
suggested that lsprof be added to the standard library, keeping
profile.py as a pure Python implementation and replacing hotshot with
lsprof.

There was concern about maintenence of the library; however, since
Armin and Michael are core developers, this seems covered.  Martin
suggested that lsprof be distributed separately for some time, and
then included when it is more mature.  Many people were concerned
about having so many profilers included (with the preference for a
single profiler that would suit beginners, since advanced users can
easily install third-party modules, which could be referenced in the
documentation).

Tim Peters explained that the aim of hotshot wasn't to reduce total
time overhead, but to be less disruptive (than profile.py) to the code
being profiled, while that code is running, via tiny little C
functions that avo

Re: [Python-Dev] Expose Subversion revision number to Python

[Barry Warsaw]

On Sat, 2005-12-17 at 23:48 +0100, "Martin v. Löwis" wrote:
> Barry Warsaw wrote:
> > AFAICT, the reason to use -c is so that changes outside the Python
> > source tree (i.e. in the sandbox) won't show up in Python's build
> > number.  That's fine although I wouldn't mind leaving off the -c since
> > you'll still get the same snapshot of code from a revisioned checkout
> > either way, and that's my primary interest.
> 
> I think the -c should be omitted, as should be any attempts to cut(1)
> this information. It's there for a reason.

Done. r41744.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] commit of r41497 -python/trunk/Lib/test

[Neal Norwitz]

On 11/21/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
>
> > I just checked in the modification below.  I'm not sure if this
> > behaviour is on purpose or by accident.

[ /f shows diff on linux and windows ]

I checked in a fix for this so float('0x3') should not work on any platform now.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] ref leak in element tree/pyexpat

[Neal Norwitz]

I'm not sure where the problem is, but this code leaks a reference:
   parser = ET.XMLParser() ; parser.feed('text')

You need this to set it up:
  from xmlcore.etree import cElementTree as ET

This isn't a memory leak according to valgrind.

Also, I noticed several places where errors where being ignored.  What
is the procedure for the element tree?  Are we supposed to modify it
in the python SVN or treat it as read-only?

The patch below fixes a few small problems.  There were some others I
noticed, but didn't add to the patch.

n
--
Index: Modules/_elementtree.c
===
--- Modules/_elementtree.c  (revision 41747)
+++ Modules/_elementtree.c  (working copy)
@@ -905,6 +905,9 @@
 }

 args = PyTuple_New(2);
+if (!args)
+   return NULL;
+
 Py_INCREF(self); PyTuple_SET_ITEM(args, 0, (PyObject*) self);
 Py_INCREF(tag);  PyTuple_SET_ITEM(args, 1, (PyObject*) tag);

@@ -1641,8 +1644,8 @@
 PyObject* node = (PyObject*) self->last;
 res = PyTuple_New(2);
 if (res) {
-Py_INCREF(action); PyTuple_SET_ITEM(res, 0, (PyObject*) action);
-Py_INCREF(node);   PyTuple_SET_ITEM(res, 1, (PyObject*) node);
+Py_INCREF(action); PyTuple_SET_ITEM(res, 0, action);
+Py_INCREF(node);   PyTuple_SET_ITEM(res, 1, node);
 PyList_Append(self->events, res);
 Py_DECREF(res);
 } else
@@ -2586,10 +2589,14 @@
 #endif

 m = Py_InitModule("_elementtree", _functions);
+if (!m)
+   return;

 /* python glue code */

 g = PyDict_New();
+if (!g)
+   return;

 PyDict_SetItemString(g, "__builtins__", PyEval_GetBuiltins());
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com