a Fred <[EMAIL PROTECTED]> wrote:
>
> I'm looking for advice on stripping down Python for an SBC to run Numpy
> and Scipy. I have the following notes on the system
>
> We have code that requires recent versions of Numpy and Scipy.
> The processor is a 32 bit Sharp ARM Sharp LH7A404 32 bit ARM9
Talin wrote:
> The original proposal was to make m[n] a synonym for m.group(n).
> "group()" is clearly map-like in its behavior.
so have you checked what exception m.group(n) raises when you try to
access a group that doesn't exist ?
frankly, speaking as the original SRE author, I will now fli
I'm looking for advice on stripping down Python for an SBC to run Numpy
and Scipy. I have the following notes on the system
We have code that requires recent versions of Numpy and Scipy.
The processor is a 32 bit Sharp ARM Sharp LH7A404 32 bit ARM922TDMI with
32MB of SDRAM.
512 MB flash di
"Kurt B. Kaiser" <[EMAIL PROTECTED]> writes:
> Don't ever do that!
Ahhh... sorry about that!!
--
KBK
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
"Karen Treanor" <[EMAIL PROTECTED]> writes:
> More and more people seem to be having a selection of email addresses,
> some for general contact, some for business, and one private one for
> only a select few contacts. This isn't possible in business, as your
> email address is by necessity public
"Karen Treanor" <[EMAIL PROTECTED]> writes:
> Unfortunately this won't work for me, not by clicking on it or by
> cutting and pasting it.
The url below is wrapped, I assume you fixed the wrap?
>
> -Original Message- From: Kurt B. Kaiser [mailto:[EMAIL PROTECTED]
>Sent: Friday, 8 December
Martin v. Löwis wrote:
> Also, if the interpreter invokes, say, threading._shutdown():
> that's also "user-screwable", as a user may put something else
> into threading._shutdown.
Although it would require being somewhat more deliberate,
since threading._shutdown clearly has something to do
with
"Alexey Borzenkov" <[EMAIL PROTECTED]> wrote:
> It can even be simpler and more powerful:
>
> class evallookup:
>def __init__(self, nsg, nsl):
> self.nsg = nsg
> self.nsl = nsl
>def __getitem__(self, name):
> return eval(name, self.nsg, self.nsl)
Never use eval in any c
"Michael Urman" <[EMAIL PROTECTED]> wrote:
> On 12/6/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Special cases aren't special enough to break the rules.
>
> Sure, but where is this rule that would be broken? I've seen it
> invoked, but I've never felt it myself. I seriously thought of slici
Alastair Houghton <[EMAIL PROTECTED]> wrote:
> On 7 Dec 2006, at 02:01, Josiah Carlson wrote:
> > Alastair Houghton <[EMAIL PROTECTED]> wrote:
> >> On 7 Dec 2006, at 01:01, Josiah Carlson wrote:
> >>> If we don't want
> >>> slicing, or if prodicing a slice would produce a semantically
> >>> questi
Martin v. Löwis schrieb:
> #1610575 suggests to introduce the 't' code to support the _Bool
> type where available, and uses char if it isn't available.
>
> Any objections to adding it?
Not from me, although the patch should probably be extended to add a
ctypes.c99_bool
(or how it would be named
On 12/4/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
With the proper mapping, this is trivial...
class namelookup:
[...snip...]
foo = foo()
>>> print "%(foo.b)i + %(foo.a)i"%namelookup(locals())
2 + 1
>>>
It can even be simpler and more powerful:
class evallookup:
def __init__(self
#1610575 suggests to introduce the 't' code to support the _Bool
type where available, and uses char if it isn't available.
Any objections to adding it?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
On 7 Dec 2006, at 18:54, Martin v. Löwis wrote:
> Alastair Houghton schrieb:
>> How about we remove the word "foolish" from the debate?
>
> We should table the debate. If you really want that feature,
> write a PEP. You want it, some people are opposed; a PEP is
> the procedure to settle the diffe
On Thu, Dec 07, 2006, Alastair Houghton wrote:
>
> An example where it might be useful:
>
> m = re.match('(?:([0-9]+) ([0-9]+) ([0-9]+) ([0-9]+) (?Prect)'
>'|([0-9]+) ([0-9]+) ([0-9]+) (?Pcircle))',
>lineFromFile)
>
> if m['rect']:
> drawRectangle(m[1:5])
Alastair Houghton schrieb:
> How about we remove the word "foolish" from the debate?
We should table the debate. If you really want that feature,
write a PEP. You want it, some people are opposed; a PEP is
the procedure to settle the difference.
Regards,
Martin
___
Fredrik Lundh wrote:
> Talin wrote:
>
>> Maybe instead of considering a match object to be a sequence, a match
>> object should be considered a map?
>
> sure, except for one small thing. from earlier in this thread:
>
> > Ka-Ping Yee wrote:
> >
> >> I'd say, don't pretend m is a sequence.
> Maybe instead of considering a match object to be a sequence, a match
> object should be considered a map? After all, we do have named, as well
> as numbered, groups...?
To me, that makes a lot more sense.
Bill
___
Python-Dev mailing list
Python-Dev
Talin wrote:
> Maybe instead of considering a match object to be a sequence, a match
> object should be considered a map?
sure, except for one small thing. from earlier in this thread:
> Ka-Ping Yee wrote:
>
>> I'd say, don't pretend m is a sequence. Pretend it's a mapping.
>> Then the co
Fredrik Lundh wrote:
> Michael Urman wrote:
>
>> The idea that slicing a match object should produce a match object
>> sounds like a foolish consistency to me.
>
> well, the idea that adding m[x] as a convenience alias for m.group(x)
> automatically turns m into a list-style sequence that also h
"Michael Urman" <[EMAIL PROTECTED]> wrote:
> On 12/7/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > (and while you guys are waiting, I suggest you start a new thread where
> > you discuss some other inconsistency that would be easy to solve with
> > more code in the interpreter, like why "-", "/
On 12/6/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Special cases aren't special enough to break the rules.
Sure, but where is this rule that would be broken? I've seen it
invoked, but I've never felt it myself. I seriously thought of slicing
as returning a list of elements per range(start,sto
On 12/7/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> (and while you guys are waiting, I suggest you start a new thread where
> you discuss some other inconsistency that would be easy to solve with
> more code in the interpreter, like why "-", "/", and "**" doesn't work
> for strings, lists don't
On 7 Dec 2006, at 07:15, Fredrik Lundh wrote:
> Michael Urman wrote:
>
>> The idea that slicing a match object should produce a match object
>> sounds like a foolish consistency to me.
>
> well, the idea that adding m[x] as a convenience alias for m.group(x)
> automatically turns m into a list-sty
On 7 Dec 2006, at 02:01, Josiah Carlson wrote:
> Alastair Houghton <[EMAIL PROTECTED]> wrote:
>> On 7 Dec 2006, at 01:01, Josiah Carlson wrote:
>>> If we don't want
>>> slicing, or if prodicing a slice would produce a semantically
>>> questionable state, then lets not do it.
>>
>> ...if you return
25 matches
Mail list logo
