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

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 rewr

Re: [Python-Dev] LSB: Binary compatibility

On 12/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > At the LSB meeting, Jeff Licquia asked whether Python could provide > binary compatibility with previous versions by use of ELF symbol > versioning. In ELF symbol versioning, you can have multiple > definitions for the same symbol; clients

Re: [Python-Dev] LSB: Selection of a Python version

Neal Norwitz schrieb: > What, if any, impact do you think the LSB should have wrt maintaining 2.4? 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 main

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

Brian Harring schrieb: >> I think this is incorrect. The implementation could well support it, >> putting a dummy object into the deleted key (which deletion needs >> to do, anyway). > > The implementation already uses a sentinel (NULL)- That' not the full truth. The implementation has a separate

Re: [Python-Dev] LSB: Selection of a Python version

What, if any, impact do you think the LSB should have wrt maintaining 2.4? n On 12/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > At the LSB meeting, there was a brief discussion of what Python > version should be incorporated into LSB. This is more an issue > if ABI compatibility for the C

Re: [Python-Dev] Python and LSB: Meeting Report

> [private, but feel free to respond on-list] >> - Allow Python scripts to run unmodified across Linux distributions >> - Optional: Allow extension modules to be used in binary form across >> distributions >> - Optional: Allow extension modules to be used in binary form across >> distributions

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

On Sun, 3 Dec 2006, Fredrik Lundh wrote: > Martin v. Löwis wrote: > > Well, the proposal was to interpret m[i] as m.group(i), for all values > > of i. I can't see anything confusing with that. > > it can quickly become rather confusing if you also interpret m[:] as > m.groups(), not to mention if y

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

On Mon, Dec 04, 2006 at 07:15:35PM +0100, "Martin v. L??wis" wrote: > Brian Harring schrieb: > > For dict; it actually *cannot* work. You can't remove keys from a > > dict as you're iterating over it (can change the val of a key, but not > > remove the key). > > I think this is incorrect. The i

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

Nick Coghlan wrote: > *The inconsistency being that group() considers the whole match to be group > 0, > while groups() does not. The real inconsistency seems to be that the groups are being treated as an array when they're really a tree. Maybe a different API altogether would be better, e.g.

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

On Sun, Dec 03, 2006 at 07:38:21PM +0100, "Martin v. L?wis" wrote: > Aahz schrieb: > >>> this one is fairly simple. if `m' is a match object, i'd like to be > >>> able to write m[1] instead of m.group(1). (similarly, m[:] should return > >>> the same as list(m.groups()).) this would remove some of

Re: [Python-Dev] Virtual Python (was Re: Python and the Linux Standard Base (LSB))

At 11:38 AM 12/4/2006 -0800, Mike Orr wrote: >The other approaches work fine for giving each user a private install >dir, but don't address the case of the same user wanting different >install dirs for different projects. For instance, when exploring >Pylons or TurboGears which install a lot of pa

Re: [Python-Dev] LSB: pyc stability

Neil Toronto <[EMAIL PROTECTED]> wrote: > compresses quite well. Can Python import modules from encrypted ZIP > files? That'd be an interesting way to protect a trade secret, and > probably safer (in the courts) than distributing bytecode. An import hook would do it. - Josiah ___

Re: [Python-Dev] LSB: pyc stability

On 12/4/06, Neil Toronto <[EMAIL PROTECTED]> wrote: Martin v. Löwis wrote: > Brett Cannon schrieb: > >> Did they say why they wanted to distribute bytecode files? I assume it >> is either for space considerations or they think it will help to protect >> their IP somehow. >> > > It's to protect

Re: [Python-Dev] Polling with Pending Calls?

"Tony Nelson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Is there a right way to get the Python interpreter to poll something, or > should I look for another approach? Usage questions belong on the general python list or comp.lang.python. The development list is mostly abou

Re: [Python-Dev] LSB: pyc stability

Martin v. Löwis wrote: > Brett Cannon schrieb: > >> Did they say why they wanted to distribute bytecode files? I assume it >> is either for space considerations or they think it will help to protect >> their IP somehow. >> > > It's to protect the IP (i.e. for proprietary software). They a

[Python-Dev] Virtual Python (was Re: Python and the Linux Standard Base (LSB))

This may be a bit too FAQ-ish for some people but I'll post it in case anybody benefits from the answer. On 11/30/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 02:46 PM 11/30/2006 -0800, Mike Orr wrote: > >Speaking of Virtual Python [1], I've heard some people recommending it > >as a general

Re: [Python-Dev] Polling with Pending Calls?

At 12:48 PM -0500 12/4/06, Tony Nelson wrote: >I think I have a need to handle *nix signals through polling in a library. >It looks like chaining Pending Calls is almost the way to do it, but I see >that doing so would make the interpreter edgy. ... Bah. Sorry to have put noise on the list. I'm

Re: [Python-Dev] LSB: pyc stability

Brett Cannon schrieb: > Some people (Robert Schweikert) requested byte-code stability at the > LSB meeting: LSB should standardize a certain version of the byte code, > and then future versions of Python should continue to support this > byte code version. > > > Did they say why

[Python-Dev] LSB: Binary compatibility

At the LSB meeting, Jeff Licquia asked whether Python could provide binary compatibility with previous versions by use of ELF symbol versioning. In ELF symbol versioning, you can have multiple definitions for the same symbol; clients (e.g. extension modules) would refer to a specific version. Durin

Re: [Python-Dev] LSB: pyc stability

On 12/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Some people (Robert Schweikert) requested byte-code stability at the LSB meeting: LSB should standardize a certain version of the byte code, and then future versions of Python should continue to support this byte code version. Did they

[Python-Dev] LSB: Selection of a Python version

At the LSB meeting, there was a brief discussion of what Python version should be incorporated into LSB. This is more an issue if ABI compatibility for the C ABI is desired, but even if only script portability is a goal, application developers will need to know what APIs they have available in LSB

Re: [Python-Dev] Polling with Pending Calls?

At 6:07 PM + 12/4/06, Gustavo Carneiro wrote: >This patch may interest you: >http://www.python.org/sf/1564547 > >Not sure it completely solves your case, but it's at least close to >your problem. I don't think that patch is useful in this case. This case is n

[Python-Dev] LSB: pyc stability

Some people (Robert Schweikert) requested byte-code stability at the LSB meeting: LSB should standardize a certain version of the byte code, and then future versions of Python should continue to support this byte code version. I explained that this is currently not supported, but would be technica

[Python-Dev] Python and LSB: Meeting Report

We just had (the first day of) an LSB face-to-face meeting today [1], where Python was discussed. I started with presenting my slides, and stated what I see as main goals: - Allow Python scripts to run unmodified across Linux distributions - Optional: Allow extension modules to be used in binary f

Re: [Python-Dev] Makefile.pre.in Patch

Hasan Diwan schrieb: > The attached patch ensures that the $(DESTDIR) exists before > installing the built binaries. It has been tested on Mac OS X. The > patch is attached. Please post patches to sf.net/projects/python Thanks, Martin ___ Python-Dev mai

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

Ben Wing schrieb: > i do see your point. i was trying to remember what i ended up doing > when i ran into this issue before, and in fact i ended up just making a > new list and appending all the elements i didn't want to delete. i see > you'd get N^2 behavior if you deleted lots of elements fr

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

Brian Harring schrieb: > For dict; it actually *cannot* work. You can't remove keys from a > dict as you're iterating over it (can change the val of a key, but not > remove the key). I think this is incorrect. The implementation could well support it, putting a dummy object into the deleted key

Re: [Python-Dev] Polling with Pending Calls?

This patch may interest you: http://www.python.org/sf/1564547 Not sure it completely solves your case, but it's at least close to your problem. On 12/4/06, Tony Nelson <[EMAIL PROTECTED]> wrote: I think I have a need to handle *nix signals through polling in a library. It looks like chaining

[Python-Dev] Polling with Pending Calls?

I think I have a need to handle *nix signals through polling in a library. It looks like chaining Pending Calls is almost the way to do it, but I see that doing so would make the interpreter edgy. The RPM library takes (steals) the signal handling away from its client application. It has good rea

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

Hi Martin, On Sun, Dec 03, 2006 at 07:56:34PM +0100, "Martin v. L?wis" wrote: > People use distutils for other purposes today as well, and these > purposes might be supported now. OK, makes some kind of sense. I suppose (as you point out in another thread) that the issue is that distros generall

Re: [Python-Dev] features i'd like [Python 3000] ... #3: fix super()

Ben Wing wrote: > i don't like the current super() at all. having to type super(Foo, > self).__init__(...) is messy, hard to remember, and error-prone. Yup. > it > also introduces an unfortunate dependency in that the name of the class > (Foo) has to be hard-coded in the call, and if you cha

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

Ben Wing wrote: > the only strangeness here is the numbering of groups starting at 1, and > making 0 be a special case. this isn't any more (or less) of a problem > for the indexing form than it is for m.group(), and it's well known from > various other languages. we could always consider maki

Re: [Python-Dev] features i'd like [Python 3000?] ... #4: interpolated strings ala perl

Ben Wing <[EMAIL PROTECTED]> wrote: > > sorry to be casting multiple ideas at once to the list. i've been > looking into other languages recently and reading the recent PEP's and > such and it's helped crystallize ideas about what could be better about > python. > > i see in PEP 3101 that th

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

Fredrik Lundh wrote: > Martin v. Löwis wrote: > > >>> it can quickly become rather confusing if you also interpret m[:] as >>> m.groups(), not to mention if you add len() and arbitrary slicing to >>> the mix. what about m[] and m[i,j,k], btw? >>> >> I take it that you are objecting to