Re: [Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects

[Ben Wing]

Fredrik Lundh wrote:
> Ka-Ping Yee wrote:
>
>   
>> I'd say, don't pretend m is a sequence.  Pretend it's a mapping.
>> Then the conceptual issues go away.
>> 
>
> almost; that would mean returning KeyError instead of IndexError for 
> groups that don't exist, which means that the common pattern
>
>  a, b, c = m.groups()
>
> cannot be rewritten as
>
>  _, a, b, c = m
>
> which would, perhaps, be a bit unfortunate.
>
> taking everything into account, I think we should simply map __getitem__ 
> to group, and stop there.  no len(), no slicing, no sequence or mapping 
> semantics.  if people want full sequence behaviour with len and slicing 
> and iterators and whatnot, they can do list(m) first.
>
>   
i'm ok either way -- that is, either with the proposal i previously 
published, or with this restricted idea.

ben
___
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] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects

[Fredrik Lundh]

Ben Wing wrote:

> i'm ok either way -- that is, either with the proposal i previously 
> published, or with this restricted idea.

ok, I'll whip up a patch for the minimal version of the proposal, if 
nobody beats me to it (all that's needed is a as_sequence struct with a 
item slot that basically just calls match_getslice_by_index).



___
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] LSB: Selection of a Python version

[Anthony Baxter]

On Tuesday 05 December 2006 17:30, Martin v. Löwis wrote:
> People at the meeting specifically said whether security patches
> would still be applied to older releases, and for how many older
> releases. Linux distributors are hesitant to make commitments to
> maintain a software package if they know that their upstream
> source doesn't provide security patches anymore.

I agree we should have a written policy. At the moment, my policy is 
this:

normal bugfixes for 2.5
critical crasher bugfix releases for 2.5 and 2.4
security bugfix releases for 2.5, 2.4, and 2.3.

I'm planning on dropping 2.3 from this list sometime next year. 
After that, I guess we can produce officially blessed patches or 
something.

> I think we should come up with a policy for dealing with security
> patches (there haven't been that many in the past, anyway); I
> believe users (i.e. vendors in this case) would be happy with the
> procedure we followed for 2.3: just produce a source release
> integrating the security patches; no need for binary releases (as
> they will produce binaries themselves).

Depends - while 2.4 is officially "retired" now, if a security 
bugfix that affects windows/OS X comes up, I think we should still 
cut binary releases.

> So I think a public statement that we will support 2.4 with
> security patches for a while longer (and perhaps with security
> patches *only*) would be a good thing - independent of the LSB,
> actually.

Well, I don't know what sort of public statement you want to issue, 
but will this do? (Wearing my release manager hat)

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] LSB: Binary compatibility

[skip]

>> All in all, I think providing binary compatibility would be feasible,
>> and should be attempted. What do you think?

Neal> Let's assume that 2.4 is the first LSB version.  The ABI is
Neal> different for 2.4 and 2.5.  We can't change the ABI for 2.5 since
Neal> it's already released and our policy is to keep it constant.

It seems that adhering to LSB's constraints is going to create a new set of
problems for Python development.  It's unclear to me what LSB brings to
Python other than a bunch of new headaches.

Skip
___
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] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects

[Alastair Houghton]

On 5 Dec 2006, at 09:02, Ben Wing wrote:

> Fredrik Lundh wrote:
>> Ka-Ping Yee wrote:

>> taking everything into account, I think we should simply map  
>> __getitem__
>> to group, and stop there.  no len(), no slicing, no sequence or  
>> mapping
>> semantics.  if people want full sequence behaviour with len and  
>> slicing
>> and iterators and whatnot, they can do list(m) first.
>>
> i'm ok either way -- that is, either with the proposal i previously
> published, or with this restricted idea.

I prefer your previous version.  It matches my expectations as a user  
of regular expression matching and as someone with experience of  
other regexp implementations.

(The current groups() method *doesn't* match those expectations,  
incidentally.  I know I've been tripped up in the past because it  
didn't include the full match as element 0.)

Basically, I don't see the advantage in the restrictions Frederik is  
proposing (other than possibly being simpler to implement, though not  
actually all that much, I think).  Yes, it's a little unusual in that  
you'd be able to index the match "array" with either integer indices  
or using names, but I don't view that as a problem, and I don't see  
how not supporting len() or other list features like slicing and  
iterators helps.  What's more, I think it will be confusing for  
Python newbies because they'll see someone doing

   m[3]

and assume that m is a list-like object, then complain when things like

   for match in m:
 print match

or

   m[3:4]

fail to do what they expect.

Yes, you might say "it's a match object, not a list".  But, it seems  
to me, that's really in the same vein as "don't type quit or exit,  
press Ctrl-D".

Kind regards,

Alastair.

--
http://alastairs-place.net


___
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] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects

[Fredrik Lundh]

Alastair Houghton wrote:

> (The current groups() method *doesn't* match those expectations,  
> incidentally.  I know I've been tripped up in the past because it  
> didn't include the full match as element 0.)

that's because there is no "group 0" in a regular expression; that's 
just a historical API convenience thing.  groups are numbered from 1 and 
upwards, and "groups()" returns all the actual groups.

> What's more, I think it will be confusing for Python newbies because
 > they'll see someone doing
> 
>m[3]
> 
> and assume that m is a list-like object, then complain when things like
> 
>for match in m:
>  print match

that'll work, of course, which might be confusing for people who think 
they understand how for-in works but don't ;)

> or
> 
>m[3:4]
> 
> fail to do what they expect.

the problem with slicing is that people may 1) expect a slice to return 
a new object *of the same type* (which opens up a *gigantic* can of 
worms, both on the implementation level and on the wtf-is-this-thing-
really level), and 2) expect things like [::-1] to work, which opens up 
another can of worms.  I prefer the "If the implementation is easy to 
explain, it may be a good idea." design principle over "can of worms" 
design principle.



___
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] cross-compile patches

[Han-Wen Nienhuys]

Hello all, 

A couple of weeks ago, I posted a collection of patches to Python 2.5
on SF.net (#1597850) that enable python to be cross-compiled using
standard tools (ie. configure and environment settings), among others
on Linux/Darwin to Mingw32/Linux/Freebsd.

In response to Martin v Loewis' initial reply we have sent in
contributor agreements, but nothing else has happened so far.

I was wondering whether there is any way for me to speed up the review
process.  For example, I could post each patch separately and/or
prepare patches to Python SVN.

-- 
 Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen

___
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] Next PyPy sprint: Leysin 8-14th January 2007

[Armin Rigo]

Hi all,

=
 PyPy Leysin Winter Sports Sprint (8-14th January 2007)
=
.. image:: http://www.ermina.ch/002.JPG

The next PyPy sprint will be in Leysin, Switzerland, for the fourth
time.  This sprint will be the final public sprint of our EU-funded
period, and a kick-off for the final work on the upcoming PyPy 1.0
release (scheduled for mid-February).

The sprint is the last chance for students looking for a "summer" job
with PyPy this winter! If you have a proposal and would like to 
work with us in the mountains please send it in before 15th December 
to "pypy-tb at codespeak.net" and cross-read this page: 

   http://codespeak.net/pypy/dist/pypy/doc/summer-of-pypy.html

--
Goals and topics of the sprint
--

* Like previous winter, the main side goal is to have fun in winter
  sports :-) We can take a couple of days off for ski; at this time of
  year, ski days end before 4pm, which still leaves plenty of time
  to recover (er, I mean hack).

* Progress on the JIT compiler, which we are just starting to scale to
  the whole of PyPy. `[1]`_

* Polish the code and documentation of the py lib, and eventually
  release it.

* Work on prototypes that use the new features that PyPy enables:
  distribution `[2]`_ (based on transparent proxying `[3]`_),
  security `[4]`_, persistence `[5]`_, etc. `[6]`_.

.. _[1]: http://codespeak.net/pypy/dist/pypy/doc/jit.html
.. _[2]: http://codespeak.net/svn/pypy/dist/pypy/lib/distributed/
.. _[3]: http://codespeak.net/pypy/dist/pypy/doc/proxy.html
.. _[4]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#security
.. _[5]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#persistence
.. _[6]: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html

---
Location & Accomodation
---

Leysin, Switzerland, "same place as before".  Let me refresh your
memory: both the sprint venue and the lodging will be in a very spacious
pair of chalets built specifically for bed & breakfast:
http://www.ermina.ch/.  The place has a baseline ADSL Internet connexion
(600Kb) with wireless installed.  You can of course arrange your own
lodging anywhere (so long as you are in Leysin, you cannot be more than a
15 minute walk away from the sprint venue), but I definitely recommend
lodging there too -- you won't find a better view anywhere else (though you
probably won't get much worse ones easily, either :-)

I made pre-reservations in the Chalet, so please *confirm* quickly that
you are coming so that we can adjust the reservations as appropriate.
The rate so far has been 60 CHF a night all included in 2-person rooms,
with breakfast.  There are larger rooms too (less expensive, possibly
more available too) and the possibility to get a single room if you
really want to.

Please register by svn:

  
http://codespeak.net/svn/pypy/extradoc/sprintinfo/leysin-winter-2007/people.txt

or on the pypy-sprint mailing list if you do not yet have check-in rights:

  http://codespeak.net/mailman/listinfo/pypy-sprint

You need a Swiss-to-(insert country here) power adapter.  There will be
some Swiss-to-EU adapters around - bring a EU-format power strip if you
have one.

---
Exact times
---

Officially, 8th-14th January 2007.  Both dates are flexible, you can
arrive or leave earlier or later, though it is recommended to arrive on
the 7th (if many people arrive on the 6th we need to check for
accomodation availability first).  We will give introductions and
tutorials on the 8th, in the morning if everybody is there, or in the
afternoon otherwise.

--

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

Re: [Python-Dev] a feature i'd like to see in python #1: betteriteration control

[Raymond Hettinger]

[Ben Wing ]
>> many times writing somewhat complex loops over lists i've found the need
>> to sometimes delete an item from the list.  currently there's no easy
>> way to do so; basically, you have to write something like

[Adam Olsen]
> As I don't believe there's any need for a language extension, I've
> posted my approach to this on comp.lang.python:
>
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/724aa6bcf021cfad/c4c629bd1bacc12b#c4c629bd1bacc12b
>
> Note that deleting from the list as you iterate over it tends to have
> very poor performance for larger lists.  My post includes some
> timings, demonstrating this.


Well said.  And even if performance considerations could be addressed, it would 
be a crummy idea , leading people into knotty code.  When looping over a 
structure, the act of actively inserting and deleting entries, can introduce 
unexpected feedback between loop control and the loop body.  This is a recipe 
for bugs and hard-to-maintain code.

Overall, feature #1 is a non-starter and hopefully this thread will die quickly 
or move off-list.


Raymond 
___
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] LSB: Binary compatibility

[Martin v. Löwis]

Neal Norwitz schrieb:
>> All in all, I think providing binary compatibility would
>> be feasible, and should be attempted. What do you think?
> 
> Let's assume that 2.4 is the first LSB version.  The ABI is different
> for 2.4 and 2.5.  We can't change the ABI for 2.5 since it's already
> released and our policy is to keep it constant.

I'm not absolutely sure it's true, because it may be possible to
integrate the 2.4 ABI into future 2.5 releases by means of symbol
versioning, but, more likely, that's not possible (as you likely
can't represent the difference in symbol versions).

> Where does that leave us for moving forward?  Would we have to modify
> 2.5 to make it entirely compatible with 2.4?  Can we skip 2.5
> altogether and worry about making 2.6 compatible with 2.4?

The most likely outcome is that LSB 3.2 won't provide any Python ABI,
but just a Python API (for a scripting language, that's enough to
achieve portability of applications). With that, extension modules
would not be portable across releases.

Then, with LSB 4.0, we could try to specify an ABI as well. Whether
that would be the 2.4 ABI, the 2.5 ABI, or the 2.6 ABI must be
decided.

> Even if
> so, that means no matter what we still need to make 2.4 compatible
> APIs going forward, right?  That will require some archeaology to
> determine preciesly what we changed from 2.4.

The LSB people are happy if we declare a subset of the ABI as stable.
So if PyFrame_New wasn't in the ABI, that would probably be just fine.

I think most ABI breakages are due to changes to structure layout,
and we should remove all reliance on structure layout out of the
ABI - requiring that ABI-compliant extensions use accessor functions
for everything.

> Is our current practice of the following change acceptable?
> 
> Original:
>  PyAPI_FUNC(xxx) Py_Foo(xxx);
> 
> New version:
>  PyAPI_FUNC(xxx) Py_FooEx(xxx, yyy);
>  #define Py_Foo(x) Py_FooEx(x, NULL)
> 
> And similarly in the C file, but keeping the original PyFoo with
> something like:
> 
>  xxx Py_FooEx(...) { ... }
>  #undef Py_Foo
>   xxx Py_Foo(xxx) { return Py_FooEx(xxx, NULL); }

This would be perfectly fine for ABI stability. They could even
accept if we just changed the signature of Py_Foo, and use
symbol versioning to provide the old definition (*) - but for API
evolution, that wouldn't work, of course.

It would mean that extension writers need the old header files
to build extensions. The LSB people would be fine with that -
they provide a complete set of header files to build LSB-compatible
binaries, anyway (so they can tell people: use these headers,
and your binaries will be ABI-compliant).

Regards,
Martin


(*) symbol versioning would help in cases where we change
a parameter to be of type Py_ssize_t now: we'd provide another
definition (with an old version number) that has the original
signature, and do the same forwarding.
___
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] LSB: Selection of a Python version

[Martin v. Löwis]

Anthony Baxter schrieb:
>> So I think a public statement that we will support 2.4 with
>> security patches for a while longer (and perhaps with security
>> patches *only*) would be a good thing - independent of the LSB,
>> actually.
> 
> Well, I don't know what sort of public statement you want to issue, 
> but will this do? (Wearing my release manager hat)

This would be a good statement, but I have also a set of policies
in mind that clarify what a "security bugfix" is, so people know
what kind of changes they get when they install a new version that
only has security bugfixes.

I believe this guarantee works in two ways: we should guarantee
that we will accept security bugfixes, but we should also guarantee
that we *only* accept security bugfixes (and perhaps critical
crashers - although they overlap in the denial-of-service field).

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] LSB: Binary compatibility

[Martin v. Löwis]

[EMAIL PROTECTED] schrieb:
> >> All in all, I think providing binary compatibility would be feasible,
> >> and should be attempted. What do you think?
> 
> Neal> Let's assume that 2.4 is the first LSB version.  The ABI is
> Neal> different for 2.4 and 2.5.  We can't change the ABI for 2.5 since
> Neal> it's already released and our policy is to keep it constant.
> 
> It seems that adhering to LSB's constraints is going to create a new set of
> problems for Python development.  It's unclear to me what LSB brings to
> Python other than a bunch of new headaches.

I won't try to defend it, but would suggest that an evaluation is
deferred until it is clear what the actual problems are, and then
to judge whether they are additional problems (or perhaps just a
tightening of procedures which we had been following all along).

In any case, having Python in the LSB means that ISVs (software
vendors) who target LSB (rather than targetting specific Linux
distributions) could develop their applications also in Python
(whereas now they have to use C or C++). With not even Java being
included, that would put Python into a unique position in that
field (perhaps along with Perl, which is also targetted for
LSB 3.2 - this wasn't discussed yesterday, basically because
nobody from the Perl community was present).

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] LSB: Binary compatibility

[Fredrik Lundh]

Martin v. Löwis wrote:

> In any case, having Python in the LSB means that ISVs (software
> vendors) who target LSB (rather than targetting specific Linux
> distributions) could develop their applications also in Python
> (whereas now they have to use C or C++).

... without having to include a Python runtime.



___
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] cross-compile patches

[Martin v. Löwis]

Han-Wen Nienhuys schrieb:
> In response to Martin v Loewis' initial reply we have sent in
> contributor agreements, but nothing else has happened so far.
> 
> I was wondering whether there is any way for me to speed up the review
> process.

It may not be what you expect to hear, but there actually is:

If you review 5 patches, I'll review yours quickly in return.

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] LSB: Binary compatibility

[skip]

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

Martin> [EMAIL PROTECTED] schrieb:
>> >> All in all, I think providing binary compatibility would be feasible,
>> >> and should be attempted. What do you think?
>> 
Neal> Let's assume that 2.4 is the first LSB version.  The ABI is
Neal> different for 2.4 and 2.5.  We can't change the ABI for 2.5 since
Neal> it's already released and our policy is to keep it constant.
>> 
>> It seems that adhering to LSB's constraints is going to create a new set 
of
>> problems for Python development.  It's unclear to me what LSB brings to
>> Python other than a bunch of new headaches.

Martin> I won't try to defend it, but would suggest that an evaluation
Martin> is deferred until it is clear what the actual problems are, and
Martin> then to judge whether they are additional problems (or perhaps
Martin> just a tightening of procedures which we had been following all
Martin> along).

Taking one example from this thread, Python's bytecode has always been an
internal implementation detail.  If I read the thread correctly there is at
least a request (if not a requirement) to make it part of an external ABI if
Python is to become part of the ABI.  That may or may not be a large
technical challenge, but I think it would be a significant philosophical
change.

Martin> In any case, having Python in the LSB means that ISVs (software
Martin> vendors) who target LSB (rather than targetting specific Linux
Martin> distributions) could develop their applications also in Python
Martin> (whereas now they have to use C or C++). 

Why?  Lots of people write portable Python programs today.

Skip
___
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] LSB: Binary compatibility

[Brett Cannon]

On 12/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


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

Martin> [EMAIL PROTECTED] schrieb:
>> >> All in all, I think providing binary compatibility would be
feasible,
>> >> and should be attempted. What do you think?
>>
Neal> Let's assume that 2.4 is the first LSB version.  The ABI is
Neal> different for 2.4 and 2.5.  We can't change the ABI for 2.5since
Neal> it's already released and our policy is to keep it constant.
>>
>> It seems that adhering to LSB's constraints is going to create a
new set of
>> problems for Python development.  It's unclear to me what LSB
brings to
>> Python other than a bunch of new headaches.

Martin> I won't try to defend it, but would suggest that an evaluation
Martin> is deferred until it is clear what the actual problems are,
and
Martin> then to judge whether they are additional problems (or perhaps
Martin> just a tightening of procedures which we had been following
all
Martin> along).

Taking one example from this thread, Python's bytecode has always been an
internal implementation detail.  If I read the thread correctly there is
at
least a request (if not a requirement) to make it part of an external ABI
if
Python is to become part of the ABI.  That may or may not be a large
technical challenge, but I think it would be a significant philosophical
change.



I don't think we are being asked to standardize the bytecode, but that we
will accept .pyc files as generated by 2.4 in future interpreters as
legitimate.  That seems to implicitly require us to standardize the bytecode
*and* they .pyc file format.

-Brett
___
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] cross-compile patches

[Han-Wen Nienhuys]

Martin v. Löwis escreveu:
> Han-Wen Nienhuys schrieb:
>> In response to Martin v Loewis' initial reply we have sent in
>> contributor agreements, but nothing else has happened so far.
>>
>> I was wondering whether there is any way for me to speed up the review
>> process.
> 
> It may not be what you expect to hear, but there actually is:
> 
> If you review 5 patches, I'll review yours quickly in return.
> 

Fair enough. 

I'm not familiar with the process, python internals, and couldn't 
find much of guidelines. I also don't have permission to fiddle with the 
tracker, so here are 5 small ones that I could understand

1608267 - added comment, asking for explanation. looks bogus.
1608579 - problem analysis + solution looks good
1507247 - I can reproduce the problem it tries to fix. Fix looks ok.
1520879 - trivial fix; should go in. disregard the comment about relative 
--prefix
1339673 - superseeded by #1597850

-- 
 Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen

___
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] LSB: Binary compatibility

[Greg Ewing]

Could backwards compatibility concerns be addressed
by including more than one version of Python in
the LSB? Python already allows multiple versions
to coexist, so applications targeting the LSB
would just need to be explicit about which version
of the interpreter to launch.

--
Greg
___
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] LSB: Selection of a Python version

[Neal Norwitz]

On 12/5/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
>
> > So I think a public statement that we will support 2.4 with
> > security patches for a while longer (and perhaps with security
> > patches *only*) would be a good thing - independent of the LSB,
> > actually.
>
> Well, I don't know what sort of public statement you want to issue,
> but will this do? (Wearing my release manager hat)

I think we should document our intentions in the release PEP (or some
other PEP possibly).  Should we state that we will support version x.y
for N years after initial release or based on version numbers such as
x.(y-N) where y is the current version and N is a small number?

I'd prefer the time based approach because it seems much more common.
For reference here are some release dates:

2.2: 2001-12-21
2.3: 2003-07-29
2.4: 2004-11-30

If we stopped supporting 2.3, that would mean we support for 2-3 years.

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] DRAFT: python-dev summary for 2006-11-16 through 2006-11-30

[Steven Bethard]

Here's the summary for the second half of November. As always,
corrections and comments are greatly appreciated.  If you were
involved in the November portions of the LSB discussions, I'd
particularly appreciate your reviews of that section.


=
Announcements
=

--
Python 2.5 malloc families
--

Remember that if you find your extension module is crashing with
Python 2.5 in malloc/free, there is a high chance that you have a
mismatch in malloc "families". Fredrik Lundh's FAQ has more:

http://effbot.org/pyfaq/why-does-my-c-extension-suddenly-crash-under-2.5.htm

Contributing thread:

- `2.5 portability problems
`__

-
Roundup tracker schema discussion
-

If you'd like to be involved in the discussion of the setup for the
`new tracker`_, you can now file issues on the `meta tracker`_ or post
to the `tracker-discuss mailing list`_. Be sure to sign up for an
account so your comments don't show up as anonymous!

.. _new tracker: http://psf.upfronthosting.co.za/roundup/tracker/
.. _meta tracker: http://psf.upfronthosting.co.za/roundup/meta/
.. _tracker-discuss mailing list:
http://mail.python.org/mailman/listinfo/tracker-discuss

Contributing thread:

- `discussion of schema for new issue tracker starting
`__


=
Summaries
=


Python and the Linux Standard Base (LSB)


Ian Murdock, the chair of the Linux Standard Base (LSB), explained
that they wanted to add Python to `LSB 3.2`_. Martin v. Löwis promised
to go to their meeting in Berlin and report back to python-dev.

The discussion then turned to the various ways in which the different
Linux variants package Python. A number of people had been troubled by
Debian's handling of distutils. At one point, Debian had excluded
distutils completely, requiring users to install the "python-dev"
package to get distutils functionality. While current versions of
Debian had put distutils back in the stdlib, they had excluded the
``config`` directory, meaning that distutils worked only for pure
Python modules, not extension modules. And because Debian had no way
of knowing that a computer with both gcc and Python installed would
likely benefit from having the ``config`` directory installed, the
user still had to install "python-dev" separately.

There was also some discussion about how to handle third party modules
so that updating a module didn't break some application which was
expecting a different version. These kinds of problems were
particularly dangerous on distributions like Gentoo and Ubuntu which
relied heavily on their own system Python for the OS to work properly.
Guido suggested introducing a vendor-packages directory for the third
party modules required by the OS and Martin v. Löwis reopened an
`earlier patch`_ suggesting this. A number of folks also thought that
adding a ~/.local/lib/pythonX.X/site-packages directory for user
specific (not site wide) packages could be useful. Phillip J. Eby
pointed out that distutils and setuptools already allow you to install
packages this way by putting::

[install]
prefix = ~/.local

into ./setup.cfg, ~/.pydistutils.cfg, or
/usr/lib/python2.x/distutils/distutils.cfg. He also explained that
setuptools could address some of the application-level problems:
setuptools-generated scripts adjust their sys.path to include the
specific eggs they need, and can specify these eggs with an exact
version if necessary. Thus OS-level scripts would likely specify exact
versions and then users could feel free to install newer eggs without
worrying that the OS would try to use them instead.

.. _LSB 3.2: http://www.freestandards.org/en/LSB_Roadmap
.. _earlier patch: http://bugs.python.org/1298835

Contributing thread:

- `Python and the Linux Standard Base (LSB)
`__

--
Thread-safe operations
--

Fredrik Lundh has been working on a `new Python FAQ`_ and asked about
what kinds of operations could be considered "atomic" for the purposes
of thread-safety. While almost any statement in Python can invoke an
arbitrary special method (e.g. ``a = b`` can invoke ``a.__del__()``),
Fredrik was interested in situations where the objects involved were
either builtins or objects that didn't override special methods. In
situations like these, you can be guaranteed things like::

* If two threads execute ``L.append(x)``, two items will be added to
the list (though the order is unspecified)
* If two threads execute ``x.y = z``, the field ``y`` on the ``x``
object will exist and contain one of the values assigned by one of the
threads

You get these guarantees mainly becaus

Re: [Python-Dev] LSB: Binary compatibility

[Martin v. Löwis]

[EMAIL PROTECTED] schrieb:
> Taking one example from this thread, Python's bytecode has always been an
> internal implementation detail.

I think that has stopped being true at least since I wrote 1997, or
perhaps even since dis.py was written (i.e. right from the beginning
of the language). With dis.py, the bytecode instructions are documented,
and their numeric values accessible through opcode.h.

What *hasn't* been documented is the marshal format, as it may change
across releases. That hasn't stopped people from using the format as
if it were specified, e.g. there is a Perl reader for marshal data:

http://search.cpan.org/~simonw/Python-Serialise-Marshal-0.02/lib/Python/Serialise/Marshal.pm

> If I read the thread correctly there is at
> least a request (if not a requirement) to make it part of an external ABI if
> Python is to become part of the ABI.  That may or may not be a large
> technical challenge, but I think it would be a significant philosophical
> change.

The philosophical change would be that a specific version of that would
be standardized. The "current" version could still evolve in a less
documented way.

> Martin> In any case, having Python in the LSB means that ISVs (software
> Martin> vendors) who target LSB (rather than targetting specific Linux
> Martin> distributions) could develop their applications also in Python
> Martin> (whereas now they have to use C or C++). 
> 
> Why?  Lots of people write portable Python programs today.

But if they distribute them, they either have to request that a Python
interpreter is installed on the target system, or they have to ship a
Python interpreter with their installation DVD (as they can't rely on
Python being available on the system, in a certain version).

With LSB specifying that Python must be present, and must have a certain
(minimal) version, they can include Python scripts in their application,
and they will work out of the box without the administrator of the
target machine having to do anything.

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] DRAFT: python-dev summary for 2006-11-16 through 2006-11-30

[Fredrik Lundh]

Steven Bethard wrote:

> Fredrik Lundh has been working on a `new Python FAQ`_ 

footnote: working on cleaning up the old FAQ, to be precise.  it'll end 
up on python.org, as soon as Andrew Kuchling gets around to complete his 
FAQ renderer (which may take a while, since he's busy with PyCon 2007).



___
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] Looking for new Python-Dev Summarizers

[Steven Bethard]

It's been my pleasure to write the Python-Dev Summaries for the last
year and a half -- 40 summaries all told, 8 of those with Tim Lesher
and 23 with Tony Meyer. It's really been an incredible learning
experience, both in how the Python development process works, and in
how Python as a community interacts.

As I'm now coming up on the last semester of so of my Ph.D., I need to
make some more time to get research done, and so I'm looking to retire
from the summaries. Hence, I'm soliciting for a good replacement (or a
few) who would be willing to pick up the job.

The job takes a few hours about once every two weeks. I have scripts
to automate most of the grunt work (e.g. collecting the threads from
mail.python.org and laying out the summary as necessary for the
website), so the job is pretty much just writing a ReST-formatted
paragraph or two on each topic.

If you've been reading Python-Dev for a while, and you'd like to get
involved, this is a great place to start - I can guarantee you'll
learn a lot from it.  Please drop me an email if you're interested!

Thanks,

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] Threading, atexit, and logging

[Martin v. Löwis]

In bug #1566280 somebody reported that he gets an
exception where the logging module tries to write
to closed file descriptor.

Upon investigation, it turns out that the file descriptor
is closed because the logging atexit handler is invoked.
This is surprising, as the program is far from exiting at
this point.

Investigating further, I found that the logging atexit
handler is registered *after* the threading atexit handler,
so it gets invoked *before* the threading's atexit.

Now, threading's atexit is the one that keeps the
application running, by waiting for all non-daemon threads
to shut down. As this application does all its work in
non-daemon threads, it keeps running for quite a while -
except that the logging module gives errors.

The real problem here is that atexit handlers are
invoked even though the program logically doesn't exit,
yet (it's not just that the threading atexit is invoked
after logging atexit - this could happen to any atexit
handler that gets registered).

I added a patch to this report which makes the MainThread
__exitfunc a sys.exitfunc, chaining what is there already.
This will work fine for atexit (as atexit is still imported
explicitly to register its sys.exitfunc), but it might break
if other applications still insist on installing a
sys.exitfunc.

What do you think about this approach?

Regards,
Martin

P.S. There is another issue reported about the interpreter
crashing; I haven't been able to reproduce this, yet.

___
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] Distribution tools: What I would like to see

[Talin]

Talin wrote:
> What I am doing right now is creating a new extension project using 
> setuputils, and keeping notes on what I do. So for example, I start by 
> creating the directory structure:
> 
> mkdir myproject
> cd myproject
> mkdir src
> mkdir test

I'd forgotten about this until I was reminded in the python-dev summary 
(dang those summaries are useful.) Anyway, I've put my notes on the 
Wiki; you can find them here at:

http://wiki.python.org/moin/ExtensionTutorial

This is an extremely minimalist guide for people who want to write an 
extension module, starting from nothing but a bare interpreter prompt.

If I made any mistakes, well - it's a wiki, you know what to do :)

-- Talin
___
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] LSB: Selection of a Python version

[Martin v. Löwis]

Neal Norwitz schrieb:
> I think we should document our intentions in the release PEP (or some
> other PEP possibly).  Should we state that we will support version x.y
> for N years after initial release or based on version numbers such as
> x.(y-N) where y is the current version and N is a small number?
> 
> I'd prefer the time based approach because it seems much more common.
> For reference here are some release dates:
> 
> 2.2: 2001-12-21
> 2.3: 2003-07-29
> 2.4: 2004-11-30
> 
> If we stopped supporting 2.3, that would mean we support for 2-3 years.

I like Anthony's view of having three modes of maintenance: general
bug fixes, serious crashers, and security fixes. We should continue
to have general bug fixes only for the most recent feature release
(i.e. 2.5 at the moment).

At the rate at which security fixes are reported, it should be
possible to keep 2.3 supported (for security patches only) for
quite some time longer.

I'm not sure about "serious crashers", as I don't have a feeling
how often they are reported and how difficult they are to backport.
For many of these, it's often the case that it is bad coding on
the application's side, in which case I think the application
should just work-around when it wants to support old Python
versions. Those are typically not security-relevant, at least
not if you can't force the crash by passing bad input data
(people accepting arbitrary code from untrusted users in their
 programs are on their own, anyway - since we removed the rexec
 module).

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