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

[Ben Wing]

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 that feature, then?
>> 
>
> I haven't seen a complete and self-consistent proposal yet, so that's 
> not easy to say.
>
> 
>
>   
my current proposal can be summarized:

1. m[x] == m.group(x) for x an integer >= 0.
2. all other sequence properties should be consistent with this 
numbering and with the view of `m' as basically an array.
3. m[name] == m.group(name) for name a string; names are aliases for 
group numbers.

this implies, for example, that negative indices count from the end, 
that len(m) == 1 + m.lastindex, that the expression `m[1:]' should be 
the same as `m.groups()', that `foo in m' is true if `foo' is equal to 
any group in m or to the whole string, etc.  property 3 should also 
probably imply that names should be allowed as slice indices -- a name 
is just an alias for a group number, and should behave the same way.

an alternative would be to view a match object as a hash table.  then, 
slices would presumably be disallowed, and `foo in m' would be true if 
`foo' is a group number in range, or a name of a group.  but i don't 
like this as much; for example, it's not clear what len(m) should return 
in the case of a named group -- does it count the group once (since a 
name is just an alias), or twice?

(btw i never really thought until now about the inconsistency in the 
'in' operator between arrays and hash tables.)

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] features i'd like [Python 3000?] ... #4: interpolated strings ala perl

[Josiah Carlson]

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 there's some work going on to fix up the string 
> formatting capabilities of python.  it looks good to me but it still 
> doesn't really address the lack of a simple interpolated string 
> mechanism, as in perl or ruby.  i find myself constantly writing stuff like
> 
> text="Family: %s" % self.name
[snip]
> maybe_errout(i"[title], line [lineno]: [errstr]\n")

This can be done now via:
maybe_errout("%(title)s, line %(lineno)i: %(errstr)s\n"%locals())


> def __str__(self):
> return i"CCGFeatval([self.name], parents=[self.parents], 
> licensing=[self.licensing])"

With the proper mapping, this is trivial...

class namelookup:
def __init__(self, namespace):
self.ns = namespace
def __getitem__(self, name):
ns = self.ns
names = name.split('.')
try:
if names[0] in ns:
ns = ns[names[0]]
names = names[1:]
except IndexError:
raise KeyError("bad namespace")

for n in names:
if hasattr(ns, n):
ns = getattr(ns, n)
else:
return ""
return ns

>>> class foo:
... a = 1
... b = 2
...
>>> foo = foo()
>>> print "%(foo.b)i + %(foo.a)i"%namelookup(locals())
2 + 1
>>>


While I understand the desire for better string interpolation, many of
your needs can be covered with pre-existing string formatting.  You can
even write a handler for "{2} and {1} or {3}" as "%(2)s and %(1)s or %
(3)s"%positional(a, b, c). Toss it into site.py, and you can use it
whenever.

If you want this to be fully in regards to Py3k, post on the py3k
mailing list: python-3000@python.org


 - Josiah

___
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

[Nick Coghlan]

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 making groups start 
> at 0 for python 3000, but this seems to me like a gratuitous 
> incompatibility with the rest of the world.

As Greg pointed out, this is just a special case of the fact that subgroups 
can be nested with the ordering governed by the location of the left 
parenthesis:

.>>> import re
.>>> m = re.match("a(b(c))", "abc")
.>>> m.group(0)
'abc'
.>>> m.group(1)
'bc'
.>>> m.group(2)
'c'

That said, I like the definitions in your last message:

   len(m) == 1 + len(m.groups())
   m[:] == [m.group(0)] + m.groups()
   all(m[i] == m.group(i) for i in range(len(m)))
   all(m[k] == m.group(k) for k in m.groupdict().keys())

The internally inconsistent* m.group() and m.groups() methods could even be 
slated for removal in Py3k (replaced by the subscript operations).

Cheers,
Nick.

*The inconsistency being that group() considers the whole match to be group 0, 
while groups() does not.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] features i'd like [Python 3000] ... #3: fix super()

[Nick Coghlan]

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 change the class name 
> you also have to go and change all super() calls -- more chances for 
> errors.  as a result, i imagine there's a strong urge to just hardcode 
> the name of the parent -- a bad idea, and the reason why super() was 
> introduced in the first place.

Also yup.

The fact that these drawbacks are fairly obvious, yet nothing has been done 
about them should suggest something to you about the difficulty of actually 
solving this problem in a reliable fashion ;)

The Python Cookbook has a few interesting approaches to making cooperative 
super calls easier to write, but they all tend to have some kind of drawback 
that makes them inappropriate for making part of the language core.

> instead, `super' should work like in other languages.  a couple of ideas:
> 
> -- super.meth(args) calls the superclass method `meth', in the same way 
> that super(Foo, self).meth(args) currently works. (this is the same 
> syntax as in java.  this probably requires making `super' be a keyword, 
> although it might be possible to hack this by examining the current call 
> stack.)

It's the implementation that's the real sticking point here, so without code 
this idea isn't likely to go anywhere.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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 and the Linux Standard Base (LSB)

[Armin Rigo]

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 generally don't have a way to say
that if a machine has both, say, tcl/tk and python installed, then
_tkinter.so would be a natural thing to have as well.  Similarly, if it
has got both python and gcc (which is quite common nowadays) then
'config' is a minor addition that would be quite handy -- even more so
than _tkinter.so, because unless you go and hack, it's not obvious to me
how you can install a 'config' in your home dir and have the system
python pick it up.


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] Polling with Pending Calls?

[Tony Nelson]

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 reason to be so paranoid, but it breaks the
handling keyboard interrupts, especially if rpmlib is used in the normal
way:  opened at the beginning, various things are done by the app, closed
at the end.  If there is an extended period in the middle where no calls
are made to rpmlib (say, in yum during the downloading of packages or
package headers), then responst to a keyboard interrupt can be delayed for
/minutes/!  Yum is presently doing something awful to work around that
issue.

It is possible to poll rpmlib to find if there is a pending keyboard
interrupt.  Client applications could have such polls sprinkled throughout
them.  I think getting yum, for example, to do that might be politically
difficult.  I'm hoping to propose a patch to rpmlib's Python bindings to do
the polling automagically.

Looking at Python's normal signal handling, I see that Py_AddPendingCall()
and Py_MakePendingCalls(), and  PyEvel_EvalFrameEx()'s ticker check are how
signals and other async events are done.  I could imagine making rpmlib's
Python bindings add a Pending Call when the library is loaded (or some
such), and that Pending Call would make a quick check of rpmlib's caught
signals flags and then call Py_AddPendingCall() on itself.  It appears that
this would work, and is almost the expected thing to do, but unfortunately
it would cause the ticker check to think that Py_MakePendingCalls() had
failed and needed to be called again ASAP, which would drastically slow
down the interpreter.

Is there a right way to get the Python interpreter to poll something, or
should I look for another approach?

[I hope this message doesn't spend too many days in the grey list limbo.]
-- 

TonyN.:'The Great Writ 
  '  is no more. 
___
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] Polling with Pending Calls?

[Gustavo Carneiro]

 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 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 reason to be so paranoid, but it breaks the
handling keyboard interrupts, especially if rpmlib is used in the normal
way:  opened at the beginning, various things are done by the app, closed
at the end.  If there is an extended period in the middle where no calls
are made to rpmlib (say, in yum during the downloading of packages or
package headers), then responst to a keyboard interrupt can be delayed for
/minutes/!  Yum is presently doing something awful to work around that
issue.

It is possible to poll rpmlib to find if there is a pending keyboard
interrupt.  Client applications could have such polls sprinkled throughout
them.  I think getting yum, for example, to do that might be politically
difficult.  I'm hoping to propose a patch to rpmlib's Python bindings to
do
the polling automagically.

Looking at Python's normal signal handling, I see that Py_AddPendingCall()
and Py_MakePendingCalls(), and  PyEvel_EvalFrameEx()'s ticker check are
how
signals and other async events are done.  I could imagine making rpmlib's
Python bindings add a Pending Call when the library is loaded (or some
such), and that Pending Call would make a quick check of rpmlib's caught
signals flags and then call Py_AddPendingCall() on itself.  It appears
that
this would work, and is almost the expected thing to do, but unfortunately
it would cause the ticker check to think that Py_MakePendingCalls() had
failed and needed to be called again ASAP, which would drastically slow
down the interpreter.

Is there a right way to get the Python interpreter to poll something, or
should I look for another approach?

[I hope this message doesn't spend too many days in the grey list limbo.]
--

TonyN.:'The Great Writ 
  '  is no more. 
___
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/gjcarneiro%40gmail.com





--
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."
___
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: better iteration control

[Martin v. Löwis]

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 (which deletion needs
to do, anyway).

> So iter.delete would require fair bit of changes 
> internally to dict, either tracking what it's yielded already, or 
> forcing iterkeys to actually be iter(keys()) (creating an intermediate 
> list), which is worse for memory usage and general performance.

I don't think either is necessary; deletion could occur "directly".

> Set's suffer the same thing; can't change what it contains while 
> iterating, have to restart the iteration after a removal/addition.

Again, I think that's incorrect.

> Tuples are immutable, so end of discusion there.

True.

> Now... occasionally, have to do it admittedly.  But it's not something 
> you actaully want to be doing in your code all that much- admittedly 
> generating a new list to avoid that hit also sucks somewhat, but the 
> worst case there is far more behaved, a temp trade of space vs 
> runtime.

Also true.

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] a feature i'd like to see in python #1: better iteration control

[Martin v. Löwis]

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 from a list, but 
> you get the same thing currently if you call `del list[i]' a lot; it's 
> not obvious that iter.delete() actually "papers over" the cost any more 
> than `del list[i]' does.

No, it wouldn't. OTOH, copying into a new list and then performing
slice-assignment is O(N). So performance-wise, it is (surprisingly)
asymptotically better to create a new list.

> however, for hash tables there's no reason to use iter.delete().  you 
> should just be able to write `del hash[x]'.  is this disallowed 
> currently?  

Try for yourself:

py> x={1:2,3:4}
py> for k in x:
...   if k < 2:
... del x[k]
...
Traceback (most recent call last):
  File "", line 1, in ?
RuntimeError: dictionary changed size during iteration

> if so, it seems like something that should be fixed.

It's difficult to fix: deleting an item may cause a resizing/rehashing
of the entire dictionary, hence the dictionary is looked while being
iterated over. I *think* that one could support deletion (but not
addition); this would need further investigation.

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] Makefile.pre.in Patch

[Martin v. Löwis]

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 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] Python and LSB: Meeting Report

[Martin v. Löwis]

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 form across
  distributions
- Optional: Allow extension modules to be used in binary form across
  distributions

During the discussion, Robert Schweikert proposed another goal, from
the view of a proprietary software vendor:

- Allow .pyc files to run unmodified across Linux distributions

The discussion evolved around backwards compatibility. I'll start
separate threads for these; here is the summary:
- LSB attempts to guarantee backwards compatibility with previous
  versions (starting with 4.0; currently, 3.2 is targeted). Linux
  distributions implementing future LSB versions should be
  backwards-compatible with previous LSB versions.
- Removal of features can only occur after three major LSB releases;
  this means all features will stay for about 6 years
- If LSB integrated a specific version now, that version will have
  to be supported by vendors for those 6 years
- given that the Python ABI changes frequently over time, this
  makes standardization of the ABI difficult
- even for API (i.e. library interfaces), backwards-compatibility
  would be difficult: for those packages/classes/modules/functions
  that become part of the LSB API, stability would be desirable.

Regards,
Martin

[1] http://www.freestandards.org/en/LSB_face-to-face_(December_2006)
[2]http://www.freestandards.org/images/6/66/Lsb-f2f-200612-python.pdf
___
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] LSB: pyc stability

[Martin v. Löwis]

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
technically possible; somebody would have to implement it.

What do you think?

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] Polling with Pending Calls?

[Tony Nelson]

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 not stuck in
some extension module's poll() call.  The signal handler is not Python's
nor is it under my control (so no chance that it would look at some new
pipe), though the rpmlib Python bindings can look at the state bits it
sets.  The Python interpreter is running full-bore when the secret rpmlib
SIGINT state is needed.  I think the patch is for the exact /opposite/ of
my problem.
-- 

TonyN.:'The Great Writ 
  '  is no more. 
___
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] LSB: Selection of a Python version

[Martin v. Löwis]

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 3.2 and which they
don't.

LSB codifies existing practice, rather than defining "anticipating"
standards, so things get only into LSB if they are already
commonplace in distributions. Currently, Python 2.4 is widely
available in Linux distributions; Python 2.5 is not and (apparently)
will not be included in the next RHEL release (which apparently
is coming soon).

So it looks like LSB will standardize on Python 2.4 (which will also
be the default version in the next Debian release).

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: pyc stability

[Brett Cannon]

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 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.

I explained that this is currently not supported, but would be

technically possible; somebody would have to implement it.



I guess we just don't remove opcodes and have import allow bytecode files
within a range of magic numbers instead of having  to match a specific one.

What do you think?


I am personally -0.  I would prefer not to start supporting people pushing
bytecode files around, but I am not going to throw a fit we do end up going
down that road.

-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

[Python-Dev] LSB: Binary compatibility

[Martin v. Löwis]

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. During static linking, the most
recent (?) version of the symbol is coded into the client object.

With symbol versioning, you can change the implementation of a
function and even its interface, and it will be compatible as
long as you keep the original version around.

My first reaction is that this is difficult due to the usage of
function-like macros. However, if we replaced those with C functions
(perhaps has a compile-time choice), and if we would also hide
the layout of structures, I think providing binary compatibility
(with a certain baseline version, or multiple of these) would
be possible.

Of course, several things need to be considered, e.g.
- making Py_INCREF/Py_DECREF functions is likely a bad idea
  for performance reasons. OTOH, it seems safe that
  Py_INCREF/Py_DECREF can remain as-is for the rest of 2.x.
- hiding PyTypeObject is a bad idea for source compatibility.
  OTOH, we already try to make only compatible changes to
  it (except when we don't :-), so exposing this as stable
  ABI might actually work.
- certain kinds of modules likely need to be ruled out, e.g.
  modules that extend the layout of existing types (it would
  fail to compile because the base struct becomes an
  incomplete type).

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

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: pyc stability

[Martin v. Löwis]

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 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 are aware
of decompyle, but still consider byte-code only distribution of their
code necessary for protection.

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] Polling with Pending Calls?

[Tony Nelson]

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 obviously too close to the
problem to see the simple solution of threading.Timer.  Checking once or
twice a second should be good enough.  Sorry to bother you all.
-- 

TonyN.:'The Great Writ 
  '  is no more. 
___
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] Virtual Python (was Re: Python and the Linux Standard Base (LSB))

[Mike Orr]

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 solution to the "this library breaks that other
> >application" problem and "this app needs a different version of X
> >library than that other app does".
>
> It was actually created to help people who don't have root access (e.g. in
> shared web hosting accounts) get their "own" Python.  It does work for
> other things, but I haven't been especially recommending it for anything
> besides that, since eggs take care of multi-version app/library support
> quite nicely.
>
> Indeeed, the virtual-python approach is itself unnecessary now, as
> easy_install has much better PYTHONPATH support now, than when
> virtual-python was created.

What does this last part mean?  Virtual Python is still one of the
four recommended ways to set up a custom install location in the
EasyInstall docs.
http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations

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 packages I may not
otherwise want, I create a Virtual Python for each of them.  If I'm
developing an application under Virtual Python, I can see at a glance
which packages my project needs installed.  I can't think of any other
way except Virtual Python to do this.

Another point.  Setuptools seems to have Two Ways To Do Things
regarding package activiation.  easy_install puts the latest-installed
egg version in its .pth file so it's automatically available via a
naive "import".  This happens to  clutters sys.path with a more
entries than some people desire.  Meanwhile, programs can use
pkg_resources to activate a package or version that may not already be
in sys.path.  Is this the Way Of The Future?  Should people start
using pkg_resources for all packages they import?  (That would also
allow one to remove little-used packages from easy-install.pth.)

Finally, one can use ~/.pydistutils.cfg to specify an install
location, but that again allows only one location per user. And in the
case of root, it can't distinguish between manually-installed packages
and OS-installed packages, which the admin might want in different
directories (/usr/local/lib/python vs /usr/lib/pythonVERSION).  This
hasn't been an issue because OSes haven't been using easy_install or
eggs, but it will be when they start doing so.

Do the PYTHONPATH improvements make it possible to just put a
directory on your PYTHONPATH and have Python process .pth files in it
without using the site.addsitedir() hack?  That would probably be my
biggest wishlist item.

-- 
Mike Orr <[EMAIL PROTECTED]>
___
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: pyc stability

[Neil Toronto]

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 are aware
> of decompyle, but still consider byte-code only distribution of their
> code necessary for protection.

It sounds like a trade secret issue. You have to take reasonable 
measures to protect trade secrets in order for them to be legally 
recognized as such. I wouldn't be surprised if compiling to bytecode 
counts. There are similar provisions in copyright due to the DMCA (which 
seems to require nothing stronger than, say, ROT26), but I don't think 
this is the right context for that.

Space considerations shouldn't be much of an issue, since you can (and 
should in many cases) distribute your code in a ZIP file, and code 
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.

Neil


___
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] Polling with Pending Calls?

[Terry Reedy]

"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 about developing the next Python releases. 



___
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: pyc stability

[Brett Cannon]

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 the IP (i.e. for proprietary software). They are aware
> of decompyle, but still consider byte-code only distribution of their
> code necessary for protection.

It sounds like a trade secret issue. You have to take reasonable
measures to protect trade secrets in order for them to be legally
recognized as such. I wouldn't be surprised if compiling to bytecode
counts. There are similar provisions in copyright due to the DMCA (which
seems to require nothing stronger than, say, ROT26), but I don't think
this is the right context for that.

Space considerations shouldn't be much of an issue, since you can (and
should in many cases) distribute your code in a ZIP file, and code
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.



No.  Part of the issue is there is no way to syntactically support entering
the password to decrypt the zip file.  One solution, though, would be to
write an importer/loader object for zip files that was instantiated with a
password and that could then handle the decryption.

-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] LSB: pyc stability

[Josiah Carlson]

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

___
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] Virtual Python (was Re: Python and the Linux Standard Base (LSB))

[Phillip J. Eby]

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 packages I may not
>otherwise want, I create a Virtual Python for each of them.  If I'm
>developing an application under Virtual Python, I can see at a glance
>which packages my project needs installed.  I can't think of any other
>way except Virtual Python to do this.

Simply install the packages to an arbitrary directory using -m 
(--multi-version), and allow the scripts to be installed to the same 
directory.  When the scripts are run, they'll find their eggs in the script 
directory.  Neither PYTHONPATH manipulation nor virtual Pythons are needed 
to achieve this - it's a self-contained single-application directory.  (It 
will still have to import pkg_resources from a copy of setuptools installed 
somewhere else, e.g. on PYTHONPATH or in site-packages, or someday perhaps 
the stdlib.)


>Another point.  Setuptools seems to have Two Ways To Do Things
>regarding package activiation.  easy_install puts the latest-installed
>egg version in its .pth file so it's automatically available via a
>naive "import".  This happens to  clutters sys.path with a more
>entries than some people desire.

Using -m (--multi-version) suppresses this behavior.  The "just works" 
behavior of automatically adding to sys.path is just the default.


>   Meanwhile, programs can use
>pkg_resources to activate a package or version that may not already be
>in sys.path.  Is this the Way Of The Future?  Should people start
>using pkg_resources for all packages they import?

No.  Setuptools automatically wraps generated scripts with 
pkg_resources-based activation, so there's almost never a need to request 
packages.  So, if you need dynamic access for a project, just create 
yourself a setup.py for it and put the requirements in there.  Then run 
"setup.py develop" to generate wrappers for your scripts.  The wrappers 
will do all the activation for you when they're run.


>Finally, one can use ~/.pydistutils.cfg to specify an install
>location, but that again allows only one location per user.

One *default* location per user... per current directory.  Since it's based 
on distutils, easy_install always reads setup.cfg from the current 
directory, which can set the defaults.  And of course, using -d 
(--install-dir) on the command line lets you specify a one-off target.


>Do the PYTHONPATH improvements make it possible to just put a
>directory on your PYTHONPATH and have Python process .pth files in it
>without using the site.addsitedir() hack?  That would probably be my
>biggest wishlist item.

Yes, it does -- but it only works for packages installed by easy_install; a 
special 'site.py' is added to the directory that adds the necessary hooks 
around the "real" 'site' module's processing.

___
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 #2: indexing of match objects

[Gregory P. Smith]

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 the verbosity
> >>> of regexp code, with probably a net gain in readability; certainly no 
> >>> loss.
> >> Please post a patch to sf.net/projects/python (or its successor).
> > 
> > Given the list of issues and subsequent discussion so far, I think a PEP
> > will be required.  This needs more documentation than the typical patch.
> 
> I disagree. So far, nobody has spoken against the proposed feature. It's
> really a small addition of a new method to an existing type. Entire
> classes have been added to the standard library without a PEP. People
> can still criticize the patch when its posted (and it's not clear that
> the OP is even willing to produce a patch).

Agreed.  Just implement it including test cases testing and demoing
the corner cases.  Making match objects have sequence and dict
behaviour for groups is imnsho just common sense.

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

[Greg Ewing]

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.

   m.range --> the whole match

   m.subgroups[i] --> another match object with its
  own range and subgroups attributes

--
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] a feature i'd like to see in python #1: better iteration control

[Brian Harring]

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 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)- point was that it 
does not support iteration over a dict that's being deleted from 
*currently* though.

One thing to note; delitem is the easy case.  Allowing for mutating 
the mapping as you're iterating via delitem implies that setitem 
should work also; setitem however can trigger a resize.

Finally, if dicts were ever modified to shrink based on load, the 
resize there would be an issue.  Mind you I've not seen proposals of 
that sort, just pointing out the potential.


> > So iter.delete would require fair bit of changes 
> > internally to dict, either tracking what it's yielded already, or 
> > forcing iterkeys to actually be iter(keys()) (creating an intermediate 
> > list), which is worse for memory usage and general performance.
> 
> I don't think either is necessary; deletion could occur "directly".
> 
> > Set's suffer the same thing; can't change what it contains while 
> > iterating, have to restart the iteration after a removal/addition.
> 
> Again, I think that's incorrect.

Again, was refering to existing implementation (and long standing 
rules/conventions regarding it).  Set suffers the same issue with 
setitem meanwhile.

In my opinion, no point in doing the deltitem modification without a 
matching setitem.  Not saying I think the modification is worth it 
mind you, just that there should be symmetry ;)


~harring


pgp90qcXtW5fT.pgp
Description: PGP signature
___
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 #2: indexing of match objects

[Ka-Ping Yee]

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 you add len() and arbitrary slicing to
> the mix.  what about m[] and m[i,j,k], btw?

I'd say, don't pretend m is a sequence.  Pretend it's a mapping.
Then the conceptual issues go away.


-- ?!ng
___
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 and LSB: Meeting Report

[Martin v. Löwis]

> [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
> 
> Was this duplication of last two points cut'n'paste error or what?

Oops, yes, it should have read

- Optional: Allow installation of binary foreign Python add-on
  packages

Thanks,
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: Selection of a Python version

[Neal Norwitz]

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 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 3.2 and which they
> don't.
>
> LSB codifies existing practice, rather than defining "anticipating"
> standards, so things get only into LSB if they are already
> commonplace in distributions. Currently, Python 2.4 is widely
> available in Linux distributions; Python 2.5 is not and (apparently)
> will not be included in the next RHEL release (which apparently
> is coming soon).
>
> So it looks like LSB will standardize on Python 2.4 (which will also
> be the default version in the next Debian release).
>
> 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/nnorwitz%40gmail.com
>
___
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: better iteration control

[Martin v. Löwis]

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 object
(called the dummy object, see dictobject.c:140 in the trunk) to
fill put in for deleted objects. You can't use NULL here because
then the open addressing would break. NULL is used as a sentinel
for the open addressing; the dummy object indicates that you have
to continue searching.

> point was that it 
> does not support iteration over a dict that's being deleted from 
> *currently* though.

Yes, but I believe that's out of fear that you have to do resizing;
iteration cannot be supported in the presence of resizing. Deletion
does not involve resizing, instead, ma_fill won't decrease during
deletion, so the next addition may trigger resizing if the fill
level goes above 2/3.

> One thing to note; delitem is the easy case.  Allowing for mutating 
> the mapping as you're iterating via delitem implies that setitem 
> should work also; setitem however can trigger a resize.

So that implication is wrong, no?

Of course, setitem for an existing key could be allowed; that's
also a meaningful operation while you are iterating over a
dictionary.

> Finally, if dicts were ever modified to shrink based on load, the 
> resize there would be an issue.  Mind you I've not seen proposals of 
> that sort, just pointing out the potential.

You'd have to defer the resizing while the dictionary is locked.

> In my opinion, no point in doing the deltitem modification without a 
> matching setitem.  Not saying I think the modification is worth it 
> mind you, just that there should be symmetry ;)

IMO, it is clear that this symmetry is *not* necessary, for the
reason that we are discussing: if iterators where to support a
delete operation, then it would be possible to provide that for
dict iterators. It wouldn't be necessary to support any other updates;
it wouldn't even be necessary to support del d[k], even if k is
the key returned from the iterator's .next().

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

[Martin v. Löwis]

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 maintain a
software package if they know that their upstream source doesn't provide
security patches anymore.

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).

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.

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

[Neal Norwitz]

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 (e.g. extension modules)
> would refer to a specific version. During static linking, the most
> recent (?) version of the symbol is coded into the client object.
>
> With symbol versioning, you can change the implementation of a
> function and even its interface, and it will be compatible as
> long as you keep the original version around.

[in a separate message that Python 2.4 is the first targetted version]

> 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.

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?  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.

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); }

I'm not arguing against the LSB at all.  I think it's a good thing,
but I'm trying to understand what work needs to be done and how we can
acheive it in the face of apparent competing requirements.  I also
realize this is a one time cost and we don't need to address the
details right 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

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

[Fredrik Lundh]

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.



___
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