Re: [Python-Dev] [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects
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 match objects from slicing, you have problems like m
>> [::-1].groups(). *I* don't know what that should return.
>
> I would argue that any 'step' != 1 has no semantically correct result
> for slicing on a match object, so we shouldn't support it.
OK, but even then, if you're returning a match object, how about the
following:
>>> m = re.match('(A)(B)(C)(D)(E)', 'ABCDE')
>>> print m[0]
ABCDE
>>> n = m[2:5]
>>> print list(n)
['B', 'C', 'D']
>>> print n[0]
B
>>> print n.group(0)
B
The problem I have with it is that it's violating the invariant that
match objects should return the whole match in group(0).
It's these kinds of things that make me think that slices shouldn't
have all of the methods of a match object. I think that's probably
why various others have suggested not supporting slicing, but I don't
think it's necessary to avoid it as long as it has clearly specified
behaviour.
>> If you're worried about types, you could do something like this:
>>
>>generic match object
>> |
>> +--+-+
>> ||
>>real match objectmatch object slice
>
> I believe the above is unnecessary. Slicing a match could produce
> another match. It's all internal data semantics.
Sure. My point, though, was that you could view (from an external
perspective) all results as instances of "generic match object",
which might not have as many methods.
Interestingly, at present, the match object type itself is an
implementation detail; e.g. for SRE, it's an _sre.SRE_Match object.
It's only the API that's documented, not the type.
Kind regards,
Alastair.
--
http://alastairs-place.net
___
Python-Dev mailing list
[email protected]
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
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-style sequence that also has to
> support full slicing sounds like an utterly foolish consistency to me.
How about we remove the word "foolish" from the debate?
> the OP's original idea was to make a common use case slightly
> easier to
> use. if anyone wants to argue for other additions to the match object
> API, they should at least come up with use cases based on real
> existing
> code.
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])
elif m['circle']:
drawCircle(m[1:3], m[3])
Is that really so outlandish? I'm not saying that this is
necessarily the best way, but why force people to write
list(m)[1:5]
or
[m[i] for i in xrange(1,5)]
??
If the only reason is that some of the match object APIs, which I
maintain are very unlikely to be wanted on a slice anyway, can't
possibly produce consistent results, then why not just do away with
the APIs and return a tuple or something instead? That way you can
treat the match object as if it were just a tuple (which it could
easily have been).
> (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 have a "copy" method, sets and lists have
> different API:s for adding things, we have hex() and oct() but no
> bin(),
> str.translate and unicode.translate take different arguments, etc.
> get
> to work!)
Oh come on! Comparing this with exponentiating strings is just not
helpful.
Kind regards,
Alastair.
--
http://alastairs-place.net
___
Python-Dev mailing list
[email protected]
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
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 have a "copy" method, sets and lists have > different API:s for adding things, we have hex() and oct() but no bin(), > str.translate and unicode.translate take different arguments, etc. get > to work!) Personally I'd love a way to get an unbound method that handles either str or unicode instances. Perhaps py3k's unicode realignment will effectively give me that. (And agreed on there being no reason that supporting indexing requires supporting slicing. But also agreed that match slicing could be as useful as indexing. Really I don't use regexps enough in Python to have a position; I was more interested in figuring out where the type(m) == type(m[:]) idea had come from, as I had never formed it.) -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] 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
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,stop,skip), with the special case being str (and then unicode followed)'s type preservation. This is done because a list of characters is a pain to work with in most contexts, so there's an implicit ''.join on the list. And because assuming that the joined string is the desired result, it's much faster to have just built it in the first place. A pure practicality beats purity argument. We both arrive at the same place in that we have a model describing the behavior for list/str/unicode, but they're different models when extended outside. Now that I see the connection you're drawing between your argument and the paper, I don't believe it's directly inspired by the paper. I read the paper to say those who could create and work with a set of rules, could learn to work with the correct rules. Consistency in Python makes things easier on everyone because there's less to remember, not because it makes us better learners of the skills necessary for programming well. The arguments I saw in the paper only addressed the second point. -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] 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
"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 "-", "/", and "**" doesn't work > > for strings, lists don't have a "copy" method, sets and lists have > > different API:s for adding things, we have hex() and oct() but no bin(), > > str.translate and unicode.translate take different arguments, etc. get > > to work!) > > Personally I'd love a way to get an unbound method that handles either > str or unicode instances. Perhaps py3k's unicode realignment will > effectively give me that. Immutable byte strings won't exist in Py3k, and the mutable byte strings (bytes) won't support very many, if any current string/unicode methods. No bytes.replace, bytes.split, bytes.partition, etc. So no, Py3k's unicode change won't get you that. All it will get you is that every string you interact with; literals, file.read, etc., will all be text (equivalent to Python 2.x unicode). - Josiah ___ Python-Dev mailing list [email protected] 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 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 has to > support full slicing sounds like an utterly foolish consistency to me. 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...? -- Talin ___ Python-Dev mailing list [email protected] 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
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 conceptual issues go away. to which I replied: > 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. ___ Python-Dev mailing list [email protected] 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
> 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 [email protected] 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 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. Pretend it's a mapping. > >> Then the conceptual issues go away. > > to which I replied: > > > 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. I think the confusion lies between the difference between 'group' (which takes either an integer or string argument, and behaves like a map), and 'groups' (which returns a tuple of the numbered arguments, and behaves like a sequence.) The original proposal was to make m[n] a synonym for m.group(n). "group()" is clearly map-like in its behavior. It seems to me that there's exactly three choices: -- Match objects behave like 'group' -- Match objects behave like 'groups' -- Match objects behave like 'group' some of the time, and like 'groups' some of the time, depending on how you refer to it. In case 1, a match object is clearly a map; In case 2, it's clearly a sequence; In case 3, it's neither, and all talk of consistency with either map or sequence is irrelevant. -- Talin ___ Python-Dev mailing list [email protected] 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 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 ___ Python-Dev mailing list [email protected] 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
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])
> elif m['circle']:
> drawCircle(m[1:3], m[3])
>
> Is that really so outlandish?
Likely; normally I would expect that drawRectangle would break on string
arguments instead of ints. I think that the amount of usefulness
compared to problems doesn't really make this worth it.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
Member of the Groucho Marx Fan Club
___
Python-Dev mailing list
[email protected]
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
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 difference. As I said a couple of e-mails back, I don't really have the time (I have lots of other things to do, most of them more important [to me, anyway]). If someone else agrees and wants to do it, great. If not, as I said before, I'm happy to let whoever do whatever. I might not agree, but that's my problem. Kind regards, Alastair. -- http://alastairs-place.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding C99 bool to struct module
#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 [email protected] 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
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, nsg, nsl): self.nsg = nsg self.nsl = nsl def __getitem__(self, name): return eval(name, self.nsg, self.nsl) class foo: a = 1 b = 2 print "%(foo.a)i + %(foo.b)i = %(foo.a + foo.b)i" % evallookup(globals(), locals()) 1 + 2 = 3 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding C99 bool to struct module
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) type - see also the comments that I posted to the tracker. Thomas ___ Python-Dev mailing list [email protected] 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 <[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
> >>> questionable state, then lets not do it.
> >>
> >> ...if you return match objects from slicing, you have problems like m
> >> [::-1].groups(). *I* don't know what that should return.
> >
> > I would argue that any 'step' != 1 has no semantically correct result
> > for slicing on a match object, so we shouldn't support it.
>
> OK, but even then, if you're returning a match object, how about the
> following:
>
>>>> m = re.match('(A)(B)(C)(D)(E)', 'ABCDE')
>>>> print m[0]
>ABCDE
>>>> n = m[2:5]
>>>> print list(n)
>['B', 'C', 'D']
>>>> print n[0]
>B
>>>> print n.group(0)
>B
>
> The problem I have with it is that it's violating the invariant that
> match objects should return the whole match in group(0).
If we were going to go with slicing, then it would be fairly trivial to
include the whole match range. Some portion of the underlying structure
knows where the start of group 2 is, and knows where the end of group 5
is, so we can slice or otherwise use that for subsequent sliced groups.
> Interestingly, at present, the match object type itself is an
> implementation detail; e.g. for SRE, it's an _sre.SRE_Match object.
> It's only the API that's documented, not the type.
I believe that is the case with all built in cPython structures.
- Josiah
___
Python-Dev mailing list
[email protected]
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
"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 slicing > as returning a list of elements per range(start,stop,skip), with the > special case being str (and then unicode followed)'s type > preservation. Tuple slicing doesn't return lists. Array slicing doesn't return lists. None of Numarray, Numeric, or Numpy array slicing returns lists. Only list slicing returns lists in current stdlib and major array package Python. Someone please correct me if I am wrong. > This is done because a list of characters is a pain to work with in > most contexts, so there's an implicit ''.join on the list. And because > assuming that the joined string is the desired result, it's much > faster to have just built it in the first place. A pure practicality > beats purity argument. Python returns strings from string slices not because of a "practicality beats purity" argument, but because not returning a string from string slicing is *insane*. The operations on strings tend to not be of the kind that is done with lists (insertion, sorting, etc.), they are typically linguistic, parsing, or data related (chop, append, prepend, scan for X, etc.). Also, typically, each item in a list is a singular item. Whereas in a string, typically _blocks of characters_ represent a single item: spaces, words, short, long, float, double, etc. (the latter being related to packed representations of data structures, as is the case in some socket protocols). Semantically, lists differ from strings in various *substantial* ways, which is why you will never see a typical user of Python asking for list.partition(lst). Strings have the sequence interface out of *convenience*, not because strings are like a list. Don't try to combine the two ideas. Also, when I said that strings/unicode were special and "has already been discussed ad-nauseum", I wasn't kidding. Take string and unicode out of the discussion and search google for the thousands of other threads that talk about why string and unicode are the way they are. They don't belong in this conversation. > We both arrive at the same place in that we have a model describing > the behavior for list/str/unicode, but they're different models when > extended outside. But this isn't about str/unicode (or buffer). For all other types available in Python with a slice operation, slicing them returns the same type as the original sequence. Expand that to 3rd party modules, and the case still holds for every package (at least those that I have seen and used). If you can point out an example (not str/unicode/buffer) for which this rule is broken in the stdlib or even any *major* 3rd party library, I'll buy you a cookie if we ever meet. > Now that I see the connection you're drawing between your argument and > the paper, I don't believe it's directly inspired by the paper. I read > the paper to say those who could create and work with a set of rules, > could learn to work with the correct rules. Consistency in Python > makes things easier on everyone because there's less to remember, not > because it makes us better learners of the skills necessary for > programming well. The arguments I saw in the paper only addressed the > second point. Right, but if you have a set of rules: 1. RULE 1 2. RULE 2 3. RULE 3 The above will be easier to understand than: 1. RULE 1 2. a. RULE 2 if X b. RULE 2a otherwise 3. RULE 3 This is the case even ignoring the paper. Special cases are more difficult to learn than no special cases. Want a real world example? English. The english language is so fraught with special cases that it is the only language for which dyslexia is known to exist (or was known to exist for many years, I haven't kept up on it). In the context of the paper, their findings suggested that those who could work with a *consistent* set of rules could be taught the right consistent rules. Toss in an inconsistency? Who knows if in this case it will make *any* difference in Python; regular expressions are already confusing for many people. This is a special case. There's a zen. Does practicality beat purity zen apply? I don't know. At this point I've just about stopped caring. Make the slice return a list, don't allow slicing, or make it a full on group variant. I don't really care at this point. Someone write a patch and lets go with it. Adding slicing producing a list should be easy after the main patch is done, and we can emulate it in Python if necessary. - Josiah ___ Python-Dev mailing list [email protected] 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
"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 code where you don't have 100% control of the content of what is being evaluated. And even then, never use eval. It doesn't make a difference in the earlier example, but I'm sure there are ways of breaking the above in nasty ways. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Threading, atexit, and logging
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 threading, whereas the atexit mechanism could get screwed up by someone who wasn't even thinking about what effect it might have on threading. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RealClearPolitics - Articles - Exit Rumsfeld, Smiling
"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 2006 4:57 AM To: [EMAIL PROTECTED]; Karen >Treanor Subject: RealClearPolitics - Articles - Exit Rumsfeld, Smiling > > http://www.realclearpolitics.com/articles/2006/12/exit_rumsfeld_smilin > g.html >> -- KBK ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Spam and semi-spam and neo-spam
"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, it has to be. > > I recently tried replying to a piece of spam and clicked on the opt > out button, but the sent item just bounced back as undeliverable. > Yahoo has a Spam tag facility but that only works for 'fixed' sites, > these random rotating ones each come in as discreet items and there's > no way to block them at source. Don't ever do that! 1. The majority of these links are bogus. 2. The majority of the rest use your click to verify you are a working email address. Then they sell the 'verified' list and you get even more spam. 3. Some of the links are fraudulent: they are phishing links which don't go where you expect, i.e. they use special characters to fool you. The result is you are directed to a site which infects your computer. -- KBK ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Spam and semi-spam and neo-spam
"Kurt B. Kaiser" <[EMAIL PROTECTED]> writes: > Don't ever do that! Ahhh... sorry about that!! -- KBK ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] help for a noob - version for a sharp ARM
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 disk - but 400 MB is reserved for data The OS is Linux only a tty interface is used. Does anyone have a feel as to whether Python for Arm is the correct starting point? What modules can I safely add/strip out? Will Python take more than 5-6 seconds to load? Will old Python releases, like 1.5.x, work with newer Numpy and Scipy? Thanks! a Fred ___ Python-Dev mailing list [email protected] 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
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 flip the bikeshed bit on all contributors to this thread, and consider it closed. I'll post a patch shortly. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] help for a noob - version for a sharp ARM
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 ARM922TDMI with > 32MB of SDRAM. > 512 MB flash disk - but 400 MB is reserved for data > The OS is Linux > only a tty interface is used. > > Does anyone have a feel as to whether Python for Arm is the correct > starting point? Sounds like plenty of muscle to handle Python certain domain number crunching problems. > What modules can I safely add/strip out? Most every C module you don't need. You can also compile without unicode. I believe you can more or less toss everything except for the base python binary and the pythonxy.so (or pythonxy.dll) for your platform, but I am most likely wrong. My (awful) suggestion: start with a Python installation in some user path, like ~/python . Toss everything and start adding things that it complains about until it starts working again. > Will Python take more than 5-6 seconds to load? I have previously gotten dos versions of Python (I think 1.5 or 1.4) to load on a 486 sx 33 with 8 megs of ram in a couple seconds. You shouldn't have issues with startup on an ARM. > Will old Python releases, like 1.5.x, work with newer Numpy and Scipy? I don't know. But you should be able to remove unused portions of Python for your platform. There are somewhat recent posts in this mailing lists about embedded systems and Python. Others may be able to help you more. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
