Re: strip not working on strings?
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'm using Python 2.3.5 and when I type the following in the interactive
> prompt I see that strip() is not working as advertised:
>
> >>>s = 'p p:p'
> >>>s.strip(' :')
> 'p p:p'
>
> Is this just me or does it not work? I want to get rid of all ' ' and
> ':' in the string. I've checked the doc and from what I can tell this
> is what strip() is supposed to do.
In /my/ docs, s.strip return a copy of s where all /leading/ and
/heading/ spaces are removed. s.strip(x) does the same but removing
chars of x.
So, what you're asking for by s.strip(' :') is "remove heading or
leading space or ':' chars", /not/ "remove heading or leading space or
':' chars".
If you want to get rid of ' ' and ':' anywhere in s, i think that
string.maketrans and s.translate will do the job:
>>> import string
>>> s = 'p p:p'
>>> ident = string.maketrans('', '')
>>> s.translate(ident,' :')
'ppp'
--
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
Re: strip not working on strings?
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'm using Python 2.3.5 and when I type the following in the interactive
> prompt I see that strip() is not working as advertised:
>
> >>>s = 'p p:p'
> >>>s.strip(' :')
> 'p p:p'
>
> Is this just me or does it not work? I want to get rid of all ' ' and
> ':' in the string. I've checked the doc and from what I can tell this
> is what strip() is supposed to do.
In /my/ docs, s.strip return a copy of s where all /leading/ and
/heading/ spaces are removed. s.strip(x) does the same but removing
chars of x.
So, what you're asking for by s.strip(' :') is "remove heading or
leading space or ':' chars", /not/ "remove or leading or
':' chars".
If you want to get rid of ' ' and ':' anywhere in s, i think that
string.maketrans and s.translate will do the job:
>>> import string
>>> s = 'p p:p'
>>> ident = string.maketrans('', '')
>>> s.translate(ident,' :')
'ppp'
--
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
Re: strip not working on strings?
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'm using Python 2.3.5 and when I type the following in the interactive
> prompt I see that strip() is not working as advertised:
>
> >>>s = 'p p:p'
> >>>s.strip(' :')
> 'p p:p'
>
> Is this just me or does it not work? I want to get rid of all ' ' and
> ':' in the string. I've checked the doc and from what I can tell this
> is what strip() is supposed to do.
In /my/ docs, s.strip return a copy of s where all /leading/ and
/heading/ spaces are removed. s.strip(x) does the same but removing
chars of x.
So, what you're asking for by s.strip(' :') is "remove heading or
leading space or ':' chars", /not/ "remove space or
':' chars".
If you want to get rid of ' ' and ':' anywhere in s, i think that
string.maketrans and s.translate will do the job:
>>> import string
>>> s = 'p p:p'
>>> ident = string.maketrans('', '')
>>> s.translate(ident,' :')
'ppp'
--
Jaco
--
http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Shi Mu <[EMAIL PROTECTED]> writes: > #why c can not append the sorted b?? Because sort() doesn't return anything? According to the library reference: 7) The sort() and reverse() methods modify the list in place for economy of space when sorting or reversing a large list. To remind you that they operate by side effect, they don't return the sorted or reversed list. -- Eric Jacoboni, ne il y a 1435934131 secondes -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
Mike Meyer <[EMAIL PROTECTED]> writes: > I've seen at least one language (forget which one) that allowed such > separators, but only for groups of three. So 123_456 would be valid, > but 9_1 would be a syntax error. Ada allows underscores in numeric literals since 1983, without enforcing any grouping. The Ruby language allows also this notation. You may write 1_000_001 or 1000_001 or 10_00_001, etc. (the same for real numbers...). When you have the habit to represent literals like that, all other big numeric literals or workarounds to create grouping seem cryptic. -- Eric Jacoboni, ne il y a 1435938104 secondes -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
[EMAIL PROTECTED] (Bengt Richter) writes: >>Eric Jacoboni, ne il y a 1435938104 secondes > Um, about your sig ... ;-) Well, i confess it's Ruby code... Maybe, one day, i will try to write a Python Version (with DateTime, i guess?) but i'm afraid it doesn't change the result. -- Eric Jacoboni, ne il y a 1436041406 secondes -- http://mail.python.org/mailman/listinfo/python-list
Python3, __slots__ and serialization
Hi, Say i want create a class with a __slots__ tuple in order to prevent creation of new attributes from outside the class. Say i want to serialize instances of this class... With pickle, all is ok : i can dump an object to a file, then reload it. With PyYAML, i can dump an object to a file, but trying to reload it fails. If i comment out the __slots__ tuple, all is fine but, then, the class is "open"... Is there some magic to have both a __slots__ tuple and a working yaml.load() ? -- https://mail.python.org/mailman/listinfo/python-list
Tuples and immutability
Hi,
I'm using Python 3.3 and i have a problem for which i've still not found
any reasonable explanation...
>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1] += [20]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'tuple' object does not support item assignment
Ok... I accept this message as += is a reassignment of a_tuple[1] and a
tuple is immutable...
But, then, why a_tuple is still modified?
>>> a_tuple
('spam', [10, 30, 20], 'eggs')
I get a TypeError for an illegal operation, but this operation is still
completed?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
Le 27/02/2014 17:13, Zachary Ware a écrit : > > You're not the first person to have this question :) > > http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works > Oh yes, i was aware of this explanation (thanks to Chris for his answer, too)... and that's why i wrote "reasonable" :) I know i should use append() or extend() and i understand the tricky implications of += in this context. But, imho, it's far from being a intuitive result, to say the least. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
Le 01/03/2014 01:22, Mark H. Harris a écrit : > I'll address the second first by asking a question... should an immutable > type (object) be able to hold (contain) mutable objects ... should tuples be > allowed to hold lists? > > lists within a tuple should be converted to tuples.If you want a tuple to > hold a list, make it a list in the first place. You're perfectly right and that why i've corrected my code to use a list of lists instead of tuple of list. I was hoping Python would prevent me for such a mistake (because such a situation can't be cleary intentional, isn't ?). Now, i will use tuple only with immutable items. IMHO it should be an error to use += with an immutable type and that means not at all. In other words, the list should not even be considered, because we're talking about changing a tuple... which should not be changed (nor should its members be changed). I agree with that too... My error was to first consider the list, then the tuple... I should have considered the tuple first... Anyway, the TypeError should rollback, not commit the mistake. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
Le 01/03/2014 22:21, Mark H. Harris a écrit : > The point I'm trying to make with this post is that s[2]+=[46] and > s[2]=s[2]+[46] are handled inconsistently. For my own, the fact that, in Python, a_liste += e_elt gives a different result than a_list = a_list + e_elt is a big source of trouble... I don't really find a good reason to justify that : a_list += "spam" gives a valid result, when a_list = a_list + "spam" is not allowed. Why the former is like a_list.extend() in the first place ? (well, it's not exactly an extend() as extend returns None, not +=). And if both operations were equivalent, i think my initial question about tuples will be clear and the behavio(u)r would me more consistent for me : tu = (10, [10, 30]) tu[1] = tu[1] + [20]<-- Big mistake! TypeError: 'tuple' object does not support item assignment <-- ok tu (10, [10, 30]) <-- ok too... In fact, i think i'm gonna forget += on lists :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
Le 02/03/2014 13:32, Ian Kelly a écrit : > On Sat, Mar 1, 2014 at 7:04 PM, Eric Jacoboni wrote: >> In fact, i think i'm gonna forget += on lists :) > > Well, do what you want, but I think you're taking the wrong lesson > from this. Don't forget about using += on lists. Instead, forget > about using assignments, augmented or otherwise, on tuple elements. > Would you expect this to work? Well, the thing about += on lists that makes me forget it, like i said in my previous post, is that its behaviour is not consistent with +. Don't get me wrong: i don't expect that modifying a tuple element works. That's exactly my point: my initial question was, why it "half works : it should not work at all". I was thinking that += on lists worked like update() or extend() : modifying lists in place... It was my mistake So, yes, i still don't get the point using a += operation, which is not even consistent with the + operation (see my exemple on "spam" in my previous post). The + operator to return the modified list and the update() or extend() methods to do in place replacements are well enough for my present needs. Maybe, in the future, i will find a use case of += for lists which is not covered by others methods, though... Who knows? I don't doubt that Python designers have made this choice and this behavior for a good reason: i've just not get it yet. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
Le 02/03/2014 15:05, Mark Lawrence a écrit : > The behaviour is consistent except when you try to modify a tuple. > Not in my opinion... li = [10, 30] li = li + "spam" --> TypeError: can only concatenate list (not "str") li += "spam" --> Ok So, not, that's not what i call consistent. And it's not related to tuples... > I'd like to see you get update to work on a list. This shows how > confused you are over this issue. Well, sorry, i wanted to write .append() -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Le 20/03/2014 16:21, Marko Rauhamaa a écrit : > All tutorials will tell you to start it with > >#!/usr/bin/env python > > which will start python2 on all (?) existing linux distros, but is > expected to start python3 within the next decade. With Arch-Linux, python is python3... -- https://mail.python.org/mailman/listinfo/python-list
Question about struct.unpack
Hi,
To experiment with unpacking, i've written a little C code which
stores one record in a file. Then, i try to reread this file to unpack
the record.
Here's the struct of a record:
typedef struct {
char nom[30];
double taille;
int age;
char plop;
} enreg_t;
The whole size, as given by sizeof() is 48, due to byte alignment.
I was first thinking that "32sdic" would make the job, but calcsize()
reports only 45 for this format. So, without knowing what, i've tried
"32sdicxxx" to reach the 48 expected... Now it works...
The same file, re-read with a Ruby script needs a
str.unpack("Z32dIc").
So, i don't know why i need to pad the format string in Python. Any
clue?
BTW: how to get rid of all this stuff after the \0 in the first field
in Python? (Ruby has Z and A, but it seems that the Python 's'
specifier is like 'A' and there is no 'Z' equivalent)
--
Eric Jacoboni, ne il y a 1444057108 secondes
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about struct.unpack
Scott David Daniels <[EMAIL PROTECTED]> writes:
Thanks for your explanations.
But :
> nom = nomz.rstrip('\0')
doesn't work for me:
>>> nomz
'Dupont\x00\x80\xbf\xff\xf70\x8f\xe0u\xa4\x00\x00.8\xfe\xfe\xfe\xff\x80\x80\x80\x80'
>>> nom = nomz.rstrip('\0')
>>> nom
'Dupont\x00\x80\xbf\xff\xf70\x8f\xe0u\xa4\x00\x00.8\xfe\xfe\xfe\xff\x80\x80\x80\x80'
--
Eric Jacoboni, ne il y a 1444080064 secondes
--
http://mail.python.org/mailman/listinfo/python-list
