Re: myths about python 3
Benjamin Kaplan, 27.01.2010 22:25: > On Wed, Jan 27, 2010 at 3:56 PM, John Nagle wrote: >> 2. Python 3 is supported by multiple Python implementations. >> >>FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow, >>PyPy, and Jython have all stayed with 2.x versions of Python. >> > When Python 2.6 came out, Jython was still on 2.2. The difference > between 2.2 and 2.6 is almost as big of a difference as between 2.6 > and 3.0. >From an implementors point of view, it's actually quite the opposite. Most syntax features of Python 3 can be easily implemented on top of an existing Py2 Implementation (we have most of them in Cython already, and I really found them fun to write), and the shifting-around in the standard library can hardly be called non-trivial. All the hard work that went into the design of CPython 3.x (and into its test suite) now makes it easy to just steal from what's there already. The amount of work that the Jython project put into catching up from 2.1 to 2.5/6 (new style classes! generators!) is really humongous compared to the adaptations that an implementation needs to do to support Python 3 code. I have great respect for the Jython project for what they achieved in the last couple of years. (I also have great respect for the IronPython project for fighting the One Microsoft Way into opening up, but that's a different kind of business.) If there was enough interest from the respective core developers, I wouldn't be surprised if we had more than one 'mostly compatible' alternative Python 3 implementation in a couple of months. But it's the obvious vicious circle business. As long as there aren't enough important users of Py3, alternative implementations won't have enough incentives to refocus their scarce developer time. Going for 2.6/7 first means that most of the Py3 work gets done anyway, so it'll be even easier then. That makes 2.6->2.7->3.2/3 the most natural implementation path. (And that, again, makes it a *really* good decision that 2.7 will be the last 2.x release line.) >> 3. Python 3 is supported by most 3rd party Python packages. >> >>FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc. >> >> Arguably, Python 3 has been rejected by the market. Instead, there's >> now Python 2.6, Python 2.7, and Python 2.8. Python 3 has turned into >> a debacle like Perl 6, now 10 years old. > > Give the package maintainers time to update. There were some pretty > big changes to the C API. Most of the major 3rd party packages like > numpy and MySQLdb have already commited to having a Python 3 version. > They just haven't gotten them out yet. I second that. NumPy has already announced that they'll rewrite some of their code in Cython to make it more maintainable and portable (and to simplify the port to Py3, I guess). Other projects will equally well find their ways to get their code ready. It's just a matter of time. I think there's enough pressure on the maintainers by now (both from users and from personal pride) to consider their packages tainted if they aren't portable enough to run on all major (C)Python versions (and Py3.1 certainly is one of them), even if they don't use them themselves. That appears to be an impressively good incentive. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Data exchange between Delphi and Python (Win)
Hi! I have an exotic db, with exotic drivers, and it have buggy ODBC driver. But I have native driver - under Delphi. I need to access this DB under Pylons (or mod_python). I wrote one solution that working with XML. But I search for easier way to transform and move data between apps. I saw Python for Delphi, but the installer is showing only Python 2.3 as selectable engine. I think to COM/OLE, because it is accessable from all program, and I think to DLL (but DLL have problematic parameterisation). The input data (what Delphi got) are SQL commands, and the output are the rows (if got). What do you thinking about it? Have anyone experience in this theme? Thanks for it! dd -- http://mail.python.org/mailman/listinfo/python-list
Re: Library support for Python 3.x
David Cournapeau writes: > Unstable may be strong - every minor version of python has a lifespan > of several years. But yes, that's an hindrance for packagers: you need > to package binaries for every minor version of python It's important to note that this is mitigated, ironically enough, by intentionally targeting a minimum Python minor version because the code base makes use of Python features not available in older versions. That is, any minor version of Python that doesn't have the features your code base uses can be ignored (given the set of supported versions is explicitly declared) — and hence one doesn't need to package binaries for every minor version. -- \ “Our products just aren't engineered for security.” —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__)development, 2002 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
Ben Finney, 27.01.2010 22:50: > Christian Heimes writes: > >> John Nagle wrote: >>> 1. Python 3 is supported by major Linux distributions. >>> >>> FALSE - most distros are shipping with Python 2.4, or 2.5 at best. >> You are wrong. Modern versions of Debian / Ubuntu are using Python >> 2.6. > > Only if by “modern” you mean “not released yet”. > > The latest stable Debian (Debian 5.0, Lenny) has only Python 2.4 and > Python 2.5. It does not have Python 2.6 at all, and until this month > Python 2.6 was not even in the in-development suite of Debian. 'Stable Debian' has a long tradition of being late and outdated on arrival. That doesn't mean you can't use existing Debian packages on it. And there certainly are .deb packages available for Py3.1.1 - Ubuntu uses them, and other Debian based distributions do, too. And Ubuntu Karmic definitely uses Py2.6 as 'python'. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Library support for Python 3.x
David Cournapeau, 28.01.2010 06:58: > On Thu, Jan 28, 2010 at 7:38 AM, Terry Reedy wrote: > >> For a windows user who depends on pre-built binaries, every new release >> breaks *every* library that is not pure Python and needs to be compiled. > > That's not windows specific - most packages which distribute binary > packages need to package binaries for every minor version (2.4, 2.5, > etc...). That's certainly the case for numpy and scipy. Python does > not have a stable ABI across minor releases, only micro releases. That doesn't completely match my experience. It's true that there is no guarantee that the ABI will stay compatible, but when you compile lxml against Py2.4 on a 32bit machine, it will continue to import in Py2.5 and (IIRC) Py2.6. It won't be as fast and it won't use some newer features, but it will work. Don't remember my experience with 2.3, though. It obviously can't work the other way round, i.e. when compiling against 2.6, it will never work in 2.5 or earlier. But there is definitely a certain degree of ABI compatibility available. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
Jonathan Gardner writes: > If you're going to have statements, you're going to need the null > statement. That's "pass". Why? Expressions are statements, so you could just say "pass" (in quotes, denoting a string literal), or 0, or None, os anything else like that, instead of having a special statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
Stefan Behnel writes: > The amount of work that the Jython project put into catching up from 2.1 to > 2.5/6 (new style classes! generators!) is really humongous compared to the > adaptations that an implementation needs to do to support Python 3 code. I wonder whether Jython could borrow code from Clojure for some of this stuff, to save a little work. Cross-fertilization between free software projects is usually a good thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Library support for Python 3.x
On Thu, Jan 28, 2010 at 5:08 PM, Ben Finney wrote: > > It's important to note that this is mitigated, ironically enough, by > intentionally targeting a minimum Python minor version because the code > base makes use of Python features not available in older versions. > > That is, any minor version of Python that doesn't have the features your > code base uses can be ignored (given the set of supported versions is > explicitly declared) — and hence one doesn't need to package binaries > for every minor version. This has nothing to do whatsoever with feature, since we are talking about ABI issues. David -- http://mail.python.org/mailman/listinfo/python-list
Re: Library support for Python 3.x
On Thu, Jan 28, 2010 at 5:40 PM, Stefan Behnel wrote: > > That doesn't completely match my experience. It's true that there is no > guarantee that the ABI will stay compatible, but when you compile lxml > against Py2.4 on a 32bit machine, it will continue to import in Py2.5 and > (IIRC) Py2.6. It won't be as fast and it won't use some newer features, but > it will work. Don't remember my experience with 2.3, though. Importing fine is a very low expectation for ABI compatibility :) Since python does not make ABI guarantees between minor releases, you don't know whether some structures layouts are changed between versions, and in general, tracking crashes due to those is no fun. It really depends on how much you depend on the C API, but for something extensive like NumPy, I don't think it would ever work. So yes, you could say "just try and if it crashes, check that it is not ABI-related". In practice, this is very poor engineering in my book... David -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
* Steven D'Aprano: On Wed, 27 Jan 2010 18:29:25 +0100, Alf P. Steinbach wrote: The main problem with the incompatibility is for porting code, not for writing code from scratch. Correct. It's a trivial problem, but still a problem. It's also a problem wrt. learning the language. This makes no sense. Why is it harder to learn print(x, y, z) than this? print x, y, z I think it's actually easier to learn just the 3.x form. But it's more difficult to learn that there are /two different/ syntactic forms, depending on which version of Python you're using and in addition depending on __future__ declarations! E.g., picking up some example code from the web, and it does not work... The first case is like the other functions you have to learn, like len(). In fact, many newbies to Python put unneeded parentheses around arguments to print simply because they assume it is a function. I would argue that the new print function is *simpler* to learn. It is more consistent with other built-ins, and has fewer magic idioms to learn. Yes, yes, yes, I agree. Instead of: print >>fileObj, x, y, z you use regular function syntax with a meaningful keyword: print(x, y, z, file=fileObj) If you want suppress the newline at the end of each print: print x, y, z, # note the final comma compared to: print(x, y, z, end='') Actually I thought the final comma thing was nice. It was like Basic. I think the 2.x 'print' must have been modeled on Basic's 'print'. If you want to change the space between elements, instead of: sys.stdout.write(str(x) + "*" + str(y) + "*" + str(z) + '\n') you use: print(x, y, z, sep='*') If you want to override the behaviour of print in a module, instead of having to edit the source code of the module (which might not even be available), all you need to do is monkey-patch it: import module module.print = myprint >>> import builtins >>> >>> org_print = print >>> builtins.print = 666 >>> >>> print( "trallala" ) Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not callable >>> org_print( "but is that really so smart?" ) but is that really so smart? >>> _ Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Library support for Python 3.x
David Cournapeau, 28.01.2010 09:54: > On Thu, Jan 28, 2010 at 5:40 PM, Stefan Behnel wrote: > >> That doesn't completely match my experience. It's true that there is no >> guarantee that the ABI will stay compatible, but when you compile lxml >> against Py2.4 on a 32bit machine, it will continue to import in Py2.5 and >> (IIRC) Py2.6. It won't be as fast and it won't use some newer features, but >> it will work. Don't remember my experience with 2.3, though. > > Importing fine is a very low expectation for ABI compatibility :) Ok, I should have said "imports and runs its test suite successfully". I just wanted to add a "works for me" to counter your rather pessimistic comments. > Since python does not make ABI guarantees between minor releases, you > don't know whether some structures layouts are changed between > versions, and in general, tracking crashes due to those is no fun. It > really depends on how much you depend on the C API, but for something > extensive like NumPy, I don't think it would ever work. I wouldn't be so sure that NumPy is so much more "extensive" in C-API usage than lxml. > So yes, you could say "just try and if it crashes, check that it is > not ABI-related". In practice, this is very poor engineering in my > book... Well, I don't know if there is any 'official' core developer statement regarding ABI compatibility, but I know that Guido doesn't take it easy to break it for a release. He tried pretty hard to keep it up for 2.5->2.6, at least, even if he was aware that it would be futile for 2.x->3.x. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Library support for Python 3.x
David Cournapeau writes: > So yes, you could say "just try and if it crashes, check that it is > not ABI-related". In practice, this is very poor engineering in my > book... I just looked at PEP 384 and I don't see anything in it about version numbers in the interfaces. I certainly think something like that should be added if it's not too late. Basically any extension module should check that the CPython loading it is new enough, and CPython should (when feasible) continue to support old interfaces when changes are made. This is pretty standard stuff as done in COM, Java, and presumably .NET, along with many communications protocols. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ad hoc lists vs ad hoc tuples
Terry Reedy wrote:
> Constant tuples (a tuple whose members are all seen as constants by the
> compiler) are now pre-compiled and constructed once and put into the
> code object as such rather than re-constructed with each run of the code.
Sadly that's not entirely accurate.
Tuples whose members are all simple constants are pre-compiled, but here's
an example of a tuple whose members are all constants but doesn't get
optimised:
>>> def foo():
data = (
('hello', 42),
('world', 24),
)
return data
>>> import dis
>>> dis.dis(foo)
3 0 LOAD_CONST 5 (('hello', 42))
4 3 LOAD_CONST 6 (('world', 24))
6 BUILD_TUPLE 2
9 STORE_FAST 0 (data)
6 12 LOAD_FAST0 (data)
15 RETURN_VALUE
--
Duncan Booth http://kupuguy.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
> Please don't post more noise and ad hominem attacks to the group, Steve. "Ad hominem"? Please, operor non utor lingua non notus per vulgaris populus. Gratias ago vos... -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
Luis M. González wrote: Please don't post more noise and ad hominem attacks to the group, Steve. "Ad hominem"? Please, operor non utor lingua non notus per vulgaris populus. Gratias ago vos... "ad hominem" is "lingua notus per vulgaris populus", the vulgar pop of these parts, anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: Total maximal size of data
On Jan 25, 8:05 pm, Alexander Moibenko wrote: > I have a simple question to which I could not find an answer. > What is the [total maximal] size of list including size of its elements? Beware, sys.getsizeof(alist) is 4*len(alist) + a bit, regardless of alists's contents ?! See http://stackoverflow.com/questions/2117255/python-deep-getsizeof-list-with-contents cheers -- denis -- http://mail.python.org/mailman/listinfo/python-list
Re: List weirdness - what the heck is going on here?
Owen Jacobson wrote: On 2010-01-27 21:06:28 -0500, Rotwang said: Hi all, I've been trying to make a class with which to manipulate sound data, and have run into some behaviour I don't understand which I hope somebody here can explain. The class has an attribute called data, which is a list with two elements, one for each audio channel, each of which is a list containing the audio data for that channel. It also has various methods to write data such as sine waves and so on, and a method to insert data from one sound at the start of data from another. Schematically, the relevant bits look like this: class sound: def f(self): self.data = [[0]]*2 Consider that this is equivalent to def f(self): x = [0] self.data = [x, x] self.data is now a list containing two references to the list referenced by x -- so changes via either of the elements of self.data will affect both elements. Your comprehension version creates a list containing two distinct list objects, so this doesn't happen. Thanks, and likewise to everyone else who replied. -- http://mail.python.org/mailman/listinfo/python-list
interaction of mode 'r+', file.write(), and file.tell(): a bug or undefined behavior?
In the code:
"""
f = open('input.txt', 'r+')
for line in f:
s = line.replace('python', 'PYTHON')
# f.tell()
f.write(s)
"""
When f.tell() is commented, 'input.txt' does not change; but when
uncommented, the f.write() succeeded writing into the 'input.txt'
(surprisingly, but not entirely unexpected, at the end of the file).
$ #
$
$ cp orig.txt input.txt
$ cat input.txt
abcde
abc python abc
python abc python
$ python
Python 2.6.4 (r264:75706, Jan 12 2010, 05:24:27)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('input.txt', 'r+')
>>> for line in f:
... s = line.replace('python', 'PYTHON')
... f.write(s)
...
>>>
$ cat input.txt
abcde
abc python abc
python abc python
$
$ #
$
$ cp orig.txt input.txt
$ cat input.txt
abcde
abc python abc
python abc python
$ python
Python 2.6.4 (r264:75706, Jan 12 2010, 05:24:27)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('input.txt', 'r+')
>>> for line in f:
... s = line.replace('python', 'PYTHON')
... f.tell()
... f.write(s)
...
39
45
60
>>>
$ cat input.txt
abcde
abc python abc
python abc python
abcde
abc PYTHON abc
$
$ #
Do you think this should be a bug or undefined behavior governed by the
underlying OS and C library? Shouldn't file.tell() be purely
informational, and not have side effect?
The machine is Gentoo (amd64, gcc-4.3.4, glibc-2.10.1-r1), Linux
(2.6.31-gentoo-r6), and Python 2.6.4
--
http://mail.python.org/mailman/listinfo/python-list
is there any alternative to savefig?
Hi all,
I wonder if anyone knows any alternative function in pylab (or
otherwise) that could be used to save an image. My problem is as
follows:
---
from pylab import *
...
figure(1)
fig1 = gca()
figure(2)
fig2 = gca()
figure(3)
fig3 = gca()
for i,data_file in enumerate(data_file_list):
time,x, y,x2, y2 = read_csv_file_4(open
(data_file),elements=num_of_elements)
fig1.plot(-x,-y,color=colours[i],label=labellist[i])
fig2.plot(time,-y,color=colours[i],label=labellist[i])
fig3.plot(time,-x,color=colours[i],label=labellist[i])
fig1.legend(loc='best')
fig1.set_title("y1 - x1")
fig1.set_ylabel("y1")
fig1.set_xlabel("x1")
#savefig("y1-x1.png")
fig2.legend(loc='best')
fig2.set_title("y1 - time")
fig2.set_ylabel("y1")
fig2.set_xlabel("time[s]")
#savefig("y1-time.png")
fig3.legend(loc='best')
fig3.set_title("x1 - time")
fig3.set_ylabel("x1")
fig3.set_xlabel("time[s]")
#savefig("x1-time.png")
show()
---
In the above code, I read multiple data files and plot three separate
figures. Now I would like to save each of the figures to a file as the
commented savefig satements suggest. The trouble is that if I
uncomment all those savefig statements, I get three saved images all
containing the plot belonging to figure(3), which was the last figure
declared.
I understand this to be happening because savefig will save the
"current" figure, which in this case happens to be the last one
declared.
If I could do something like fig1.savefig("y1-x1.png") or savefig("y1-
x1.png").fig1, this would solve the problem but I'm not aware of any
such methods or modules to enable this. This is thus a flaw in the
general design/implementation of the savefig function, but is there an
alternative function to enable me achieve what I need? Is there
perhaps a possible tweak to savefig to make it do the same?
Thanks in advance,
Robert
--
http://mail.python.org/mailman/listinfo/python-list
Re: Library support for Python 3.x
>> I'm going to be starting some new Python projects in Python 2.6, but am >> concerned that at least three of the libraries I will be >> using--pycrypto, paramiko and feedparser--are not currently supported in >> Python 3.x. The authors of these programs have not given any indication >> that work is underway to support Python 3.x. Eventually I plan to >> migrate to Python 3.x. > > Maybe by 2015 or so, that might be feasible. Wait until Python 3.x > ships as standard with major Linux distros. Right now, 2.4 or 2.5 is > the production version of Python. You keep repeating this nonsense even though it has been pointed out to you in a neighbouring thread that many (most?) of the main linux distros ship python 2.6 and not 2.5 or 2.4. For example Fedora 11 and 12 both ship python 2.6, others mentioned lots of other examples in said other thread, anyone can look them up. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: Generic proxy (that proxies methods like __iter__)
On Jan 27, 3:07 pm, Arnaud Delobelle wrote: > On 27 Jan, 14:41, D HANNEY wrote: > [...] > > See [1] for an explanation. Here is an idea: you could get round that > by generating a class on the fly, if you don't mind changing the class > of the object (untested): > > def noguardproxy(obj): > class NoGuardProxy(type(obj)): > def __enter__(self): > return self > def __exit__(self, type, value, traceback): > return False > obj.__class__ = NoGuardProxy > return obj > > If you want to keep obj untouched, you could add the line > > obj = copy(obj) > > before changing the class. > > -- > Arnaud > > [1]http://docs.python.org/reference/datamodel.html#new-style-special-lookup Thank you! Your solution works if I change "type(obj)" to say "obj.__class__". If I don't make this change Python complains "TypeError: Error when calling the metaclass bases type 'instance' is not an acceptable base type". So, I've got something that works but I don't understand why it works. I've read your docs.python reference but that hasn't helped yet. It might come to me but in the meantime, can you (or anyone) offer an explanation for this? Thanks in advance, David -- http://mail.python.org/mailman/listinfo/python-list
Re: Stuck on a three word street name regex
> > [snip]
> > Regex doesn't gain you much. I'd split the string and then fix the parts
> > as necessary:
>
> > >>> def parse_address(address):
> > ... parts = address.split()
> > ... if parts[-2] == "S":
> > ... parts[1 : -1] = [parts[-2]] + parts[1 : -2]
> > ... parts[1 : -1] = [" ".join(parts[1 : -1])]
> > ... return parts
> > ...
> > >>> print parse_address("1000 RAMPART S ST")
> > ['1000', 'S RAMPART', 'ST']
> > >>> print parse_address("100 JOHN CHURCHILL CHASE ST")
> > ['100', 'JOHN CHURCHILL CHASE', 'ST']
>
> This is a nice approach I wouldn't have thought to pursue. I've never
> seen this referencing of list elements in reverse order with negative
> values, so that certainly expands my knowledge of Python. Of course,
> I'd want to check for other directionals -- probably with a list
> check, e.g.,
>
> if parts[-2] in ('E', 'W', 'N', 'S'):
>
> Thanks for sharing your approach.
After studying this again today, I realized the ingeniousness of
reverse slicing the list (or perhaps right slicing) -- that one
doesn't have to worry about the number of words in the string.
To translate for those who may follow, the expression "parts[1 : -1]"
means gather list items from position one in the list (index position
2) to one index position before the end of the list. The value in this
is that we already know the first list element after a split() will be
the street number. The last element will be the street type.
Everything in between, no matter how many words, will be the street
name -- excepting, of course, the instances where there's a street
direction added in, as captured in example above.
A very nice solution. Thanks again!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Stuck on a three word street name regex
On Jan 28, 7:40 am, Brian D wrote:
> > > [snip]
> > > Regex doesn't gain you much. I'd split the string and then fix the parts
> > > as necessary:
>
> > > >>> def parse_address(address):
> > > ... parts = address.split()
> > > ... if parts[-2] == "S":
> > > ... parts[1 : -1] = [parts[-2]] + parts[1 : -2]
> > > ... parts[1 : -1] = [" ".join(parts[1 : -1])]
> > > ... return parts
> > > ...
> > > >>> print parse_address("1000 RAMPART S ST")
> > > ['1000', 'S RAMPART', 'ST']
> > > >>> print parse_address("100 JOHN CHURCHILL CHASE ST")
> > > ['100', 'JOHN CHURCHILL CHASE', 'ST']
>
> > This is a nice approach I wouldn't have thought to pursue. I've never
> > seen this referencing of list elements in reverse order with negative
> > values, so that certainly expands my knowledge of Python. Of course,
> > I'd want to check for other directionals -- probably with a list
> > check, e.g.,
>
> > if parts[-2] in ('E', 'W', 'N', 'S'):
>
> > Thanks for sharing your approach.
>
> After studying this again today, I realized the ingeniousness of
> reverse slicing the list (or perhaps right slicing) -- that one
> doesn't have to worry about the number of words in the string.
>
> To translate for those who may follow, the expression "parts[1 : -1]"
> means gather list items from position one in the list (index position
> 2) to one index position before the end of the list. The value in this
> is that we already know the first list element after a split() will be
> the street number. The last element will be the street type.
> Everything in between, no matter how many words, will be the street
> name -- excepting, of course, the instances where there's a street
> direction added in, as captured in example above.
>
> A very nice solution. Thanks again!
Correction:
[snip] the expression "parts[1 : -1]" means gather list items from the
second element in the list (index value 1) to one index position
before the end of the list. [snip]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Generic proxy (that proxies methods like __iter__)
On Jan 28, 1:31 pm, D HANNEY wrote:
>
> Your solution works if I change "type(obj)" to say "obj.__class__".
> If I don't make this change Python complains "TypeError: Error when
> calling the metaclass bases type 'instance' is not an acceptable base
> type".
> So, I've got something that works but I don't understand why it works.
> I've read your docs.python reference but that hasn't helped yet. It
> might come to me but in the meantime, can you (or anyone) offer an
> explanation for this?
>
> Thanks in advance,
>
> David
Oh it looks like this is py3K thing.
Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22)
>>> from io import StringIO
>>> type(StringIO("x"))
>>> StringIO("x").__class__
>>>
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
>>> from StringIO import StringIO
>>> type(StringIO("x"))
>>> StringIO("x").__class__
>>>
I was using 2.6.2. Your suggestion would have been fine in py3k.
Even if I stuck with 2.6.2 and StringIO was a "new style class" there
then it would have been fine ... but it isn't.
As it stands __class__ seems the only way that works on both 3k and
2k.
Bit weird, but I get it now.
Thanks again!
David
--
http://mail.python.org/mailman/listinfo/python-list
Re: Portable way to tell if a process is still alive
Suppose we have a program that writes its process id into a pid file. Usually the program deletes the pid file when it exists... But in some cases (for example, killed with kill -9 or TerminateProcess) pid file is left there. I would like to know if a process (given with its process id) is still running or not. I know that this can be done with OS specific calls. But that is not portable. It can also be done by executing "ps -p 23423" with subprocess module, but that is not portable either. Is there a portable way to do this? If not, would it be a good idea to implement this (I think very primitive) function in the os module? Not only is there no way to do it portably, there is no way to do it reliably for the general case. The problem is that processes do not have unique identifiers. A PID only uniquely identifies a running process; once the process terminates, its PID becomes available for re-use. Non-general case: the process is a service and only one instance should be running. There could be a pid file left on the disk. It is possible to e.g. mount procfs, and check if the given PID belongs to a command line / executed program that is in question. It cannot be guaranteed that a service will always delete its pid file when it exists. It happens for example, somebody kills it with "kill -9" or exits on signal 11 etc. It actually did happened to me, and then the service could not be restarted because the PID file was there. (It is an error to run two instances of the same service, but it is also an error to not run it) Whan I would like to do upon startup is to check if the process is already running. This way I could create a "guardian" that checks other services, and (re)starts them if they stopped working. And no, it is not a solution to write "good" a service that will never stop, because: 1. It is particulary not possible in my case - there is a software bug in a third party library that causes my service exit on various wreid signals. 2. It is not possible anyway. There are users killing processes accidentally, and other unforeseen bugs. 3. In a mission critical environment, I would use a guardian even if guarded services are not likely to stop I understand that this is a whole different question now, and possibly there is no portable way to do it. Just I wonder if there are others facing a similar problem here. Any thoughs or comments - is it bad that I would like to achieve? Is there a better approach? Thanks, Laszlo -- http://mail.python.org/mailman/listinfo/python-list
Re: Stuck on a three word street name regex
On 01/28/10 11:28, Brian D wrote: > I've tackled this kind of problem before by looping through a patterns > dictionary, but there must be a smarter approach. > > Two addresses. Note that the first has incorrectly transposed the > direction and street name. The second has an extra space in it before > the street type. Clearly done by someone who didn't know how to > concatenate properly -- or didn't care. > > 1000 RAMPART S ST > > 100 JOHN CHURCHILL CHASE ST > > I want to parse the elements into an array of values that can be > inserted into new database fields. > > Anyone who loves solving these kinds of puzzles care to relieve my > frazzled brain? > > The pattern I'm using doesn't keep the "CHASE" with the "JOHN > CHURCHILL": How does the following perform? pat = re.compile(r'(?P\d+)\s+(?P[A-Z\s]+)\s+(?PN|S|W|E|)\s+(?PST|RD|AVE?|)$') or more legibly: pat = re.compile( r''' (?P \d+ ) #M series of digits \s+ (?P [A-Z\s]+ ) #M one-or-more word \s+ (?P S?E|SW?|N?W|NE?| ) #O direction or nothing \s+ (?P ST|RD|AVE? ) #M street type $ #M END ''', re.VERBOSE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Portable way to tell if a process is still alive
On 10:50 am, gand...@shopzeus.com wrote: Suppose we have a program that writes its process id into a pid file. Usually the program deletes the pid file when it exists... But in some cases (for example, killed with kill -9 or TerminateProcess) pid file is left there. I would like to know if a process (given with its process id) is still running or not. I know that this can be done with OS specific calls. But that is not portable. It can also be done by executing "ps -p 23423" with subprocess module, but that is not portable either. Is there a portable way to do this? If not, would it be a good idea to implement this (I think very primitive) function in the os module? Not only is there no way to do it portably, there is no way to do it reliably for the general case. The problem is that processes do not have unique identifiers. A PID only uniquely identifies a running process; once the process terminates, its PID becomes available for re-use. Non-general case: the process is a service and only one instance should be running. There could be a pid file left on the disk. It is possible to e.g. mount procfs, and check if the given PID belongs to a command line / executed program that is in question. It cannot be guaranteed that a service will always delete its pid file when it exists. It happens for example, somebody kills it with "kill -9" or exits on signal 11 etc. It actually did happened to me, and then the service could not be restarted because the PID file was there. (It is an error to run two instances of the same service, but it is also an error to not run it) Whan I would like to do upon startup is to check if the process is already running. This way I could create a "guardian" that checks other services, and (re)starts them if they stopped working. And no, it is not a solution to write "good" a service that will never stop, because: 1. It is particulary not possible in my case - there is a software bug in a third party library that causes my service exit on various wreid signals. 2. It is not possible anyway. There are users killing processes accidentally, and other unforeseen bugs. 3. In a mission critical environment, I would use a guardian even if guarded services are not likely to stop I understand that this is a whole different question now, and possibly there is no portable way to do it. Just I wonder if there are others facing a similar problem here. Any thoughs or comments - is it bad that I would like to achieve? Is there a better approach? I've been pondering using a listening unix socket for this. As long as the process is running, a client can connect to the unix socket. As soon as the process isn't, no matter the cause, clients can no longer connect to it. A drawback of this approach in some cases is probably that the process should be accepting these connections (and then dropping them). This may not always be easy to add to an existing app. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: interaction of mode 'r+', file.write(), and file.tell(): a bug or undefined behavior?
On Jan 28, 7:12 am, Lie Ryan wrote:
> In the code:
>
> """
> f = open('input.txt', 'r+')
> for line in f:
> s = line.replace('python', 'PYTHON')
> # f.tell()
> f.write(s)
> """
> [snip]
My guess is that there are a few possible problems:
1) In this case, writing to file opened with 'r+' without an explicit
f.seek is probably not a good idea. The file iterator (for line in f)
uses a readahead buffer, which means you can't guarantee what the
current file position will be.
2) It may be necessary to do an explicit f.flush or f.close when
writing to an 'r+' file. In your case, the close should automatically
happen when the f object falls out of scope, which tells me that were
still looking at some other problem, like not using f.seek
3) It is possible that f.tell implicitly flushes buffers used by the
file object. That would explain why uncommenting the f.tell causes
the writes to show up.
What are you trying to accomplish? Overwrite the original file, or
append to it? If you want to overwrite the file, it may be better to
generate a new file, delete the old one, then rename the new one. If
you want to append, then it would be better to open the file with
append mode ('a')
--
http://mail.python.org/mailman/listinfo/python-list
Re: interaction of mode 'r+', file.write(), and file.tell(): a bug or undefined behavior?
* Anthony Tolle:
On Jan 28, 7:12 am, Lie Ryan wrote:
In the code:
"""
f = open('input.txt', 'r+')
for line in f:
s = line.replace('python', 'PYTHON')
# f.tell()
f.write(s)
"""
[snip]
My guess is that there are a few possible problems:
1) In this case, writing to file opened with 'r+' without an explicit
f.seek is probably not a good idea. The file iterator (for line in f)
uses a readahead buffer, which means you can't guarantee what the
current file position will be.
2) It may be necessary to do an explicit f.flush or f.close when
writing to an 'r+' file. In your case, the close should automatically
happen when the f object falls out of scope, which tells me that were
still looking at some other problem, like not using f.seek
3) It is possible that f.tell implicitly flushes buffers used by the
file object. That would explain why uncommenting the f.tell causes
the writes to show up.
As far as I understand it the behavior stems from CPython file operations being
implemented fairly directly as forwarding to C library FILE* operations, and the
C standard prescribes Undefined Behavior to the case above.
I think the Python language/library specification should specify the effect
(perhaps just as UB, but anyway, specified).
For as it is, it may/will be different with different Python implementations,
meaning that code that works OK with one implementation may fail with another
implementation.
What are you trying to accomplish? Overwrite the original file, or
append to it? If you want to overwrite the file, it may be better to
generate a new file, delete the old one, then rename the new one. If
you want to append, then it would be better to open the file with
append mode ('a')
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
Need help with a program
Hi folks,
I am a newbie to python, and I would be grateful if someone could
point out the mistake in my program. Basically, I have a huge text
file similar to the format below:
AGACTCGAGTGCGCGGA 0
AGATAAGCTAATTAAGCTACTGG 0
AGATAAGCTAATTAAGCTACTGGGTT 1
AGCTCACAATAT 1
AGGTCGCCTGACGGCTGC 0
The text is nothing but DNA sequences, and there is a number next to
it. What I will have to do is, ignore those lines that have 0 in it,
and print all other lines (excluding the number) in a new text file
(in a particular format called as FASTA format). This is the program I
wrote for that:
seq1 = []
list1 = []
lister = []
listers = []
listers1 = []
a = []
d = []
i = 0
j = 0
num = 0
file1 = open(sys.argv[1], 'r')
for line in file1:
if not line.startswith('\n'):
seq1 = line.split()
if len(seq1) == 0:
continue
a = seq1[0]
list1.append(a)
d = seq1[1]
lister.append(d)
b = len(lister)
for j in range(0, b):
if lister[j] == 0:
listers.append(j)
else:
listers1.append(j)
print listers1
resultsfile = open("sequences1.txt", 'w')
for i in listers1:
resultsfile.write('\n>seq' + str(i) + '\n' + list1[i] + '\n')
But this isn't working. I am not able to find the bug in this. I would
be thankful if someone could point it out. Thanks in advance!
Cheers!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
* evilweasel:
Hi folks,
I am a newbie to python, and I would be grateful if someone could
point out the mistake in my program. Basically, I have a huge text
file similar to the format below:
AGACTCGAGTGCGCGGA 0
AGATAAGCTAATTAAGCTACTGG 0
AGATAAGCTAATTAAGCTACTGGGTT 1
AGCTCACAATAT 1
AGGTCGCCTGACGGCTGC 0
The text is nothing but DNA sequences, and there is a number next to
it. What I will have to do is, ignore those lines that have 0 in it,
and print all other lines (excluding the number) in a new text file
(in a particular format called as FASTA format). This is the program I
wrote for that:
seq1 = []
list1 = []
lister = []
listers = []
listers1 = []
a = []
d = []
i = 0
j = 0
num = 0
file1 = open(sys.argv[1], 'r')
for line in file1:
if not line.startswith('\n'):
seq1 = line.split()
if len(seq1) == 0:
continue
a = seq1[0]
list1.append(a)
d = seq1[1]
lister.append(d)
b = len(lister)
for j in range(0, b):
if lister[j] == 0:
listers.append(j)
else:
listers1.append(j)
print listers1
resultsfile = open("sequences1.txt", 'w')
for i in listers1:
resultsfile.write('\n>seq' + str(i) + '\n' + list1[i] + '\n')
But this isn't working.
What do you mean by "isn't working"?
I am not able to find the bug in this. I would
be thankful if someone could point it out. Thanks in advance!
What do you expect as output, and what do you actually get as output?
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Jan 28, 3:07 pm, evilweasel wrote: > Hi folks, > > I am a newbie to python, and I would be grateful if someone could > point out the mistake in my program. > for j in range(0, b): > if lister[j] == 0: At a guess, this line should be: if lister[j] == '0': ... -- Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Thu, Jan 28, 2010 at 4:07 PM, evilweasel
wrote:
> Hi folks,
>
> I am a newbie to python, and I would be grateful if someone could
> point out the mistake in my program. Basically, I have a huge text
> file similar to the format below:
>
> AGACTCGAGTGCGCGGA 0
> AGATAAGCTAATTAAGCTACTGG 0
> AGATAAGCTAATTAAGCTACTGGGTT 1
> AGCTCACAATAT 1
> AGGTCGCCTGACGGCTGC 0
>
> The text is nothing but DNA sequences, and there is a number next to
> it. What I will have to do is, ignore those lines that have 0 in it,
> and print all other lines (excluding the number) in a new text file
> (in a particular format called as FASTA format). This is the program I
> wrote for that:
>
> seq1 = []
> list1 = []
> lister = []
> listers = []
> listers1 = []
> a = []
> d = []
> i = 0
> j = 0
> num = 0
>
> file1 = open(sys.argv[1], 'r')
> for line in file1:
> if not line.startswith('\n'):
> seq1 = line.split()
> if len(seq1) == 0:
> continue
>
> a = seq1[0]
> list1.append(a)
>
> d = seq1[1]
> lister.append(d)
>
>
> b = len(lister)
> for j in range(0, b):
> if lister[j] == 0:
> listers.append(j)
> else:
> listers1.append(j)
>
>
> print listers1
> resultsfile = open("sequences1.txt", 'w')
> for i in listers1:
> resultsfile.write('\n>seq' + str(i) + '\n' + list1[i] + '\n')
>
> But this isn't working. I am not able to find the bug in this. I would
> be thankful if someone could point it out. Thanks in advance!
>
> Cheers!
I'm not totaly sure what you want to do but try this (python2.6+):
newlines = []
with open(sys.argv[1], 'r') as f:
text = f.read();
for line in text.splitlines():
if not line.strip() and line.strip().endswith('1'):
newlines.append('seq'+line)
with open(sys.argv[2], 'w') as f:
f.write('\n'.join(newlines))
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Thu, Jan 28, 2010 at 4:28 PM, Krister Svanlund
wrote:
> On Thu, Jan 28, 2010 at 4:07 PM, evilweasel
> wrote:
>> Hi folks,
>>
>> I am a newbie to python, and I would be grateful if someone could
>> point out the mistake in my program. Basically, I have a huge text
>> file similar to the format below:
>>
>> AGACTCGAGTGCGCGGA 0
>> AGATAAGCTAATTAAGCTACTGG 0
>> AGATAAGCTAATTAAGCTACTGGGTT 1
>> AGCTCACAATAT 1
>> AGGTCGCCTGACGGCTGC 0
>>
>> The text is nothing but DNA sequences, and there is a number next to
>> it. What I will have to do is, ignore those lines that have 0 in it,
>> and print all other lines (excluding the number) in a new text file
>> (in a particular format called as FASTA format). This is the program I
>> wrote for that:
>>
>> seq1 = []
>> list1 = []
>> lister = []
>> listers = []
>> listers1 = []
>> a = []
>> d = []
>> i = 0
>> j = 0
>> num = 0
>>
>> file1 = open(sys.argv[1], 'r')
>> for line in file1:
>> if not line.startswith('\n'):
>> seq1 = line.split()
>> if len(seq1) == 0:
>> continue
>>
>> a = seq1[0]
>> list1.append(a)
>>
>> d = seq1[1]
>> lister.append(d)
>>
>>
>> b = len(lister)
>> for j in range(0, b):
>> if lister[j] == 0:
>> listers.append(j)
>> else:
>> listers1.append(j)
>>
>>
>> print listers1
>> resultsfile = open("sequences1.txt", 'w')
>> for i in listers1:
>> resultsfile.write('\n>seq' + str(i) + '\n' + list1[i] + '\n')
>>
>> But this isn't working. I am not able to find the bug in this. I would
>> be thankful if someone could point it out. Thanks in advance!
>>
>> Cheers!
>
> I'm not totaly sure what you want to do but try this (python2.6+):
>
> newlines = []
>
> with open(sys.argv[1], 'r') as f:
> text = f.read();
> for line in text.splitlines():
> if not line.strip() and line.strip().endswith('1'):
newlines.append('seq'+line.strip()[:-1].strip())
>
> with open(sys.argv[2], 'w') as f:
> f.write('\n'.join(newlines))
>
Gah, made some errors
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Thu, 28 Jan 2010 07:07:04 -0800 (PST)
evilweasel wrote:
> I am a newbie to python, and I would be grateful if someone could
Welcome.
> point out the mistake in my program. Basically, I have a huge text
> file similar to the format below:
You don't say how it isn't working. As a first step you should read
http://catb.org/~esr/faqs/smart-questions.html.
> The text is nothing but DNA sequences, and there is a number next to
> it. What I will have to do is, ignore those lines that have 0 in it,
Your code doesn't completely ignore them. See below.
> and print all other lines (excluding the number) in a new text file
> (in a particular format called as FASTA format). This is the program I
> wrote for that:
>
> seq1 = []
> list1 = []
> lister = []
> listers = []
> listers1 = []
> a = []
> d = []
> i = 0
> j = 0
> num = 0
This seems like an awful lot of variables for such a simple task.
>
> file1 = open(sys.argv[1], 'r')
> for line in file1:
This is good. You aren't trying to load the whole file into memory at
once. If the file is huge as you say then that would have been bad. I
would have made one small optimization that saves one assignment and
one extra variable.
for line in open(sys.argv[1], 'r'):
> if not line.startswith('\n'):
> seq1 = line.split()
> if len(seq1) == 0:
> continue
This is redundant and perhaps not even correct at the end of the file.
It assumes that the last line ends with a newline. Look at what
'\n'.split() gives you and see if you can't improve the above code.
Another small optimization - "if seq1" is better than "if len(seq1)".
>
> a = seq1[0]
> list1.append(a)
Aha! I may have found your bug. Are you mixing tabs and spaces?
Don't do that. Either always use spaces or always use tabs. My
suggestion is to use spaces and choose a short indent such as three or
even two but that's a religious issue.
>
> d = seq1[1]
> lister.append(d)
You can also do "a, d = seq1". Of course you must be sure that you
have two fields. Perhaps that's guaranteed for your input but a quick
sanity test wouldn't hurt here.
However, I don't understand all of the above. It may also be a source
of problems. You say the files are huge. Are you filling up memory
here? You did the smart thing reading the file but you lose it here.
In any case, see below.
> b = len(lister)
> for j in range(0, b):
Go lookup zip()
> if lister[j] == 0:
I think that you will find that lister[j] is "0", not 0.
> listers.append(j)
> else:
> listers1.append(j)
Why are you collecting the input? Just toss the '0' ones and write the
others lines directly to the output.
Hope this helps with this script and in further understanding the power
and simplicity of Python. Good luck.
--
D'Arcy J.M. Cain | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Thu, Jan 28, 2010 at 4:31 PM, Krister Svanlund
wrote:
> On Thu, Jan 28, 2010 at 4:28 PM, Krister Svanlund
> wrote:
>> On Thu, Jan 28, 2010 at 4:07 PM, evilweasel
>> wrote:
>>> Hi folks,
>>>
>>> I am a newbie to python, and I would be grateful if someone could
>>> point out the mistake in my program. Basically, I have a huge text
>>> file similar to the format below:
>>>
>>> AGACTCGAGTGCGCGGA 0
>>> AGATAAGCTAATTAAGCTACTGG 0
>>> AGATAAGCTAATTAAGCTACTGGGTT 1
>>> AGCTCACAATAT 1
>>> AGGTCGCCTGACGGCTGC 0
>>>
>>> The text is nothing but DNA sequences, and there is a number next to
>>> it. What I will have to do is, ignore those lines that have 0 in it,
>>> and print all other lines (excluding the number) in a new text file
>>> (in a particular format called as FASTA format). This is the program I
>>> wrote for that:
>>>
>>> seq1 = []
>>> list1 = []
>>> lister = []
>>> listers = []
>>> listers1 = []
>>> a = []
>>> d = []
>>> i = 0
>>> j = 0
>>> num = 0
>>>
>>> file1 = open(sys.argv[1], 'r')
>>> for line in file1:
>>> if not line.startswith('\n'):
>>> seq1 = line.split()
>>> if len(seq1) == 0:
>>> continue
>>>
>>> a = seq1[0]
>>> list1.append(a)
>>>
>>> d = seq1[1]
>>> lister.append(d)
>>>
>>>
>>> b = len(lister)
>>> for j in range(0, b):
>>> if lister[j] == 0:
>>> listers.append(j)
>>> else:
>>> listers1.append(j)
>>>
>>>
>>> print listers1
>>> resultsfile = open("sequences1.txt", 'w')
>>> for i in listers1:
>>> resultsfile.write('\n>seq' + str(i) + '\n' + list1[i] + '\n')
>>>
>>> But this isn't working. I am not able to find the bug in this. I would
>>> be thankful if someone could point it out. Thanks in advance!
>>>
>>> Cheers!
I'm trying this again:
newlines = []
with open(sys.argv[1], 'r') as f:
text = f.read();
for line in (l.strip() for l in text.splitlines()):
if line:
line_elem = line.split()
if len(line_elem) == 2 and line_elem[1] == '1':
newlines.append('seq'+line_elem[0])
with open(sys.argv[2], 'w') as f:
f.write('\n'.join(newlines))
--
http://mail.python.org/mailman/listinfo/python-list
Re: is there any alternative to savefig?
On Jan 28, 12:29 pm, kiwanuka wrote:
> Hi all,
>
> I wonder if anyone knows any alternative function in pylab (or
> otherwise) that could be used to save an image. My problem is as
> follows:
>
> ---
> from pylab import *
> ...
>
> figure(1)
> fig1 = gca()
> figure(2)
> fig2 = gca()
> figure(3)
> fig3 = gca()
>
> for i,data_file in enumerate(data_file_list):
> time,x, y,x2, y2 = read_csv_file_4(open
> (data_file),elements=num_of_elements)
> fig1.plot(-x,-y,color=colours[i],label=labellist[i])
> fig2.plot(time,-y,color=colours[i],label=labellist[i])
> fig3.plot(time,-x,color=colours[i],label=labellist[i])
>
> fig1.legend(loc='best')
> fig1.set_title("y1 - x1")
> fig1.set_ylabel("y1")
> fig1.set_xlabel("x1")
> #savefig("y1-x1.png")
>
> fig2.legend(loc='best')
> fig2.set_title("y1 - time")
> fig2.set_ylabel("y1")
> fig2.set_xlabel("time[s]")
> #savefig("y1-time.png")
>
> fig3.legend(loc='best')
> fig3.set_title("x1 - time")
> fig3.set_ylabel("x1")
> fig3.set_xlabel("time[s]")
> #savefig("x1-time.png")
> show()
> ---
>
> In the above code, I read multiple data files and plot three separate
> figures. Now I would like to save each of the figures to a file as the
> commented savefig satements suggest. The trouble is that if I
> uncomment all those savefig statements, I get three saved images all
> containing the plot belonging to figure(3), which was the last figure
> declared.
>
> I understand this to be happening because savefig will save the
> "current" figure, which in this case happens to be the last one
> declared.
>
> If I could do something like fig1.savefig("y1-x1.png") or savefig("y1-
> x1.png").fig1, this would solve the problem but I'm not aware of any
> such methods or modules to enable this. This is thus a flaw in the
> general design/implementation of the savefig function, but is there an
> alternative function to enable me achieve what I need? Is there
> perhaps a possible tweak to savefig to make it do the same?
>
> Thanks in advance,
>
> Robert
Problem solved.
--
http://mail.python.org/mailman/listinfo/python-list
Re: is there any alternative to savefig?
* kiwanuka:
On Jan 28, 12:29 pm, kiwanuka wrote:
Hi all,
I wonder if anyone knows any alternative function in pylab (or
otherwise) that could be used to save an image. My problem is as
follows:
---
from pylab import *
...
figure(1)
fig1 = gca()
figure(2)
fig2 = gca()
figure(3)
fig3 = gca()
for i,data_file in enumerate(data_file_list):
time,x, y,x2, y2 = read_csv_file_4(open
(data_file),elements=num_of_elements)
fig1.plot(-x,-y,color=colours[i],label=labellist[i])
fig2.plot(time,-y,color=colours[i],label=labellist[i])
fig3.plot(time,-x,color=colours[i],label=labellist[i])
fig1.legend(loc='best')
fig1.set_title("y1 - x1")
fig1.set_ylabel("y1")
fig1.set_xlabel("x1")
#savefig("y1-x1.png")
fig2.legend(loc='best')
fig2.set_title("y1 - time")
fig2.set_ylabel("y1")
fig2.set_xlabel("time[s]")
#savefig("y1-time.png")
fig3.legend(loc='best')
fig3.set_title("x1 - time")
fig3.set_ylabel("x1")
fig3.set_xlabel("time[s]")
#savefig("x1-time.png")
show()
---
In the above code, I read multiple data files and plot three separate
figures. Now I would like to save each of the figures to a file as the
commented savefig satements suggest. The trouble is that if I
uncomment all those savefig statements, I get three saved images all
containing the plot belonging to figure(3), which was the last figure
declared.
I understand this to be happening because savefig will save the
"current" figure, which in this case happens to be the last one
declared.
If I could do something like fig1.savefig("y1-x1.png") or savefig("y1-
x1.png").fig1, this would solve the problem but I'm not aware of any
such methods or modules to enable this. This is thus a flaw in the
general design/implementation of the savefig function, but is there an
alternative function to enable me achieve what I need? Is there
perhaps a possible tweak to savefig to make it do the same?
Thanks in advance,
Robert
Problem solved.
That's nice, but would you mind telling the group the solution?
Assuming that you haven't (I don't see all messages posted to the e-mail list,
only what's propagated to Usenet or originating there).
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
I will make my question a little more clearer. I have close to 60,000 lines of the data similar to the one I posted. There are various numbers next to the sequence (this is basically the number of times the sequence has been found in a particular sample). So, I would need to ignore the ones containing '0' and write all other sequences (excluding the number, since it is trivial) in a new text file, in the following format: >seq59902 TTTATTATATAGT >seq59903 TTTATTTCTTGGCGTTGT >seq59904 TTTGGTTGCCCTGCGTGG >seq59905 TTTGTTTATGGG The number next to 'seq' is the line number of the sequence. When I run the above program, what I expect is an output file that is similar to the above output but with the ones containing '0' ignored. But, I am getting all the sequences printed in the file. Kindly excuse the 'newbieness' of the program. :) I am hoping to improve in the next few months. Thanks to all those who replied. I really appreciate it. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Symbols as parameters?
On Jan 22, 2010, at 11:56 AM, Roald de Vries wrote:
Hi Martin,
On Jan 21, 2010, at 8:43 AM, Martin Drautzburg wrote:
Hello all,
When passing parameters to a function, you sometimes need a paramter
which can only assume certain values, e.g.
def move (direction):
...
If direction can only be "up", "down", "left" or "right", you can
solve
this by passing strings, but this is not quite to the point:
- you could pass invalid strings easily
- you need to quote thigs, which is a nuisance
- the parameter IS REALLY NOT A STRING, but a direction
Alternatively you could export such symbols, so when you "import *"
you
have them available in the caller's namespace. But that forces you
to "import *" which pollutes your namespace.
What I am really looking for is a way
- to be able to call move(up)
- having the "up" symbol only in the context of the function
call
So it should look something like this
... magic, magic ...
move(up)
... unmagic, unmagic ...
print up
This should complain that "up" is not defined during the "print"
call,
but not when move() is called. And of course there should be as
little
magic as possible.
Any way to achieve this?
You could do something like this:
class Move(object):
def __call__(self, direction):
print(direction)
return 0
def up(self):
return self('up')
move = Move()
Now move.up() means move('up'), and you can obviously do similar
things for other directions.
Question out of general interest in the language:
If I would want to generate such functions in a for-loop, what would I
have to do? This doesn't work:
class Move(object):
def __call__(self, direction):
return direction
move = Move()
for f in ['up', 'down', 'right', 'left']:
move.__dict__[f] = lambda: move(f)
... because now 'move.up()' returns 'left' because thats the current
value of f. Is there a way to 'expand' f in the loop? Or a reason that
you never should use this?
--
http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
I have been working with Python 3 for over a year. I used it in writing my book "Bioinformatics Programming Using Python" (http://oreilly.com/catalog/9780596154509 ). I didn't see any point in teaching an incompatible earlier version of a language in transition. In preparing the book and its examples I explored a large number of Python modules in some depth and encountered most of the differences between the language and libraries of Python 2 and Python 3. The change was a bit awkward for a while, and there were some surprises, but in the end I have found nothing in Python 3 for which I would prefer Python 2's version. Removal of old-style classes is a big win. Having print as a function provides a tremendous amount of flexibility. I use the sep and end keywords all the time. There is no reason for print to be a statement, and it was an awkward inconsistency in a language that leans towards functional styles. Likewise the elimination of cmp, while shocking, leads to much simpler comparison arguments to sort, since all the function does is return a key; then, sort uses __lt__ (I think) so it automatically uses each class's definition of that. The weird objects returned from things like sorted, dict.keys/values/items, and so on are values that in practice are used primarily in iterations; you can always turn the result into a list, though I have to admit that while developing and debugging I trip trying to pick out a specific element from one of these using indexing (typically [0]); I've learned to think of them as generators, even though they aren't. The rearrangements and name changes in the libraries are quite helpful. I could go on, but basically the language and library changes are on the whole large improvements with little, if any, downside. Conversion of old code is greatly facilitied by the 2to3 tool that comes with Python 3. The big issue in moving from 2 to 3 is the external libraries and development tools you use. Different IDEs have released versions that support Python 3 at different times. (I believe Wing was the first.) If you use numpy, for example, or one of the many libraries that require it, you are stuck. Possibly some important facilities will never be ported to Python 3, but probably most active projects will eventually produce a Python 3 version -- for example, according to its web page, a Python 3 version of PIL is on the way. I was able to cover all the topics in my book using only Python library modules, something I felt would be best for readers -- I used libraries such as elementree, sqlite3, and tkinter. The only disappointment was that I couldn't include a chapter on BioPython, since there is no Python 3 version. By now, many large facilities support both Python 2 and Python 3. I am currently building a complex GUI/Visualization application based on the Python 3 version of PyQt4 and Wing IDE and am delighted with all of it. It may well be that some very important large -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
In article , Steven D'Aprano wrote: >On Wed, 27 Jan 2010 16:25:46 -0500, Benjamin Kaplan wrote: >> >> When Python 2.6 came out, Jython was still on 2.2. The difference >> between 2.2 and 2.6 is almost as big of a difference as between 2.6 and >> 3.0. In that time, you had the introduction of the boolean type, >> generators, list comprehensions, the addition of the "yield" and "with" >> keywords, universal newline support, and decorators in addition to the >> large number of changes to the standard library such as the introduction >> of the subprocess module. > >I believe that, with the possible exception of the change from byte >strings to unicode strings, virtually *all* the hoo-har over Python 3 is >simply due to the tactical mistake of Guido and the Python Dev team of >*calling* Python 3 a backward incompatible release. Python has had >previous major changes in the past (e.g. 1.5 to 2.0 and 2.1 to 2.2) and >hardly anyone made a complaint. But as Steven points out, the difference from 2.2 to 2.6 is roughly the same as 2.6 to 3.1. Python has never before had such a large difference from one release to the next, and I think few people try to support serious apps on the full range from 2.2 to 2.6. Moreover, the task of using a single codebase without 2to3 is much easier in 1.4 through 2.6. Admittedly, it wouldn't be much fun to write 1.4 code these days without all the neat features that have been added, but you can't argue that it's hard. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity -- http://mail.python.org/mailman/listinfo/python-list
Good Book
Many people who want to learn Islam or are new converts find it hard to have a simplified guide that explains to them the basics of Islam in a nutshell; so I decided to collect the basic guidelines and gather them in an e-book I named it "Basic Islam" for Introducing Islam http://www.saaid.net/book/9/2012.doc -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
In article , Mitchell L Model wrote: > I use the sep and end keywords all the time. What are 'sep' and 'end'? I'm looking in http://docs.python.org/3.1/genindex-all.html and don't see those mentioned at all. Am I just looking in the wrong place? -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
In article , Neil Hodgson wrote: >Carl Banks: >> >> There is also no hope someone will fork Python 2.x and continue it in >> perpetuity. Well, someone might try to fork it, but they won't be >> able to call it Python. > > Over time there may be more desire from those unable or unwilling to >upgrade to 3.x to work on improvements to 2.x, perhaps leading to a >version 2.8. One of the benefits of open source is that you are not >trapped into following vendor decisions like Microsoft abandoning >classic VB in favour of VB.NET. > > It would be unreasonable for the core developers to try to block >this. Refusing use of the Python trademark for a version that was >reasonably compatible in both directions would be particularly petty. Agreed, and as a PSF member, I'd certainly be opposed to anyone trying to prevent the release of Python 2.8, and I would actively favor providing PSF and python.org resources to them. OTOH, I would also be likely to push anyone working on Python 2.8 to come up with a solid release plan first. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Jan 28, 10:50 am, evilweasel wrote:
> I will make my question a little more clearer. I have close to 60,000
> lines of the data similar to the one I posted. There are various
> numbers next to the sequence (this is basically the number of times
> the sequence has been found in a particular sample). So, I would need
> to ignore the ones containing '0' and write all other sequences
> (excluding the number, since it is trivial) in a new text file, in the
> following format:
>
> >seq59902
>
> TTTATTATATAGT
>
> >seq59903
>
> TTTATTTCTTGGCGTTGT
>
> >seq59904
>
> TTTGGTTGCCCTGCGTGG
>
> >seq59905
>
> TTTGTTTATGGG
>
> The number next to 'seq' is the line number of the sequence. When I
> run the above program, what I expect is an output file that is similar
> to the above output but with the ones containing '0' ignored. But, I
> am getting all the sequences printed in the file.
>
> Kindly excuse the 'newbieness' of the program. :) I am hoping to
> improve in the next few months. Thanks to all those who replied. I
> really appreciate it. :)
People have already given you some pointers to your problem. In the
end you will have to "tweak the details" because only you have access
to the data not us.
Just as example here is another way to do what you are doing:
with open('dnain.dat') as infile, open('dnaout.dat','w') as outfile:
partgen=(line.split() for line in infile)
dnagen=(str(i+1)+'\n'+part[0]+'\n'
for i,part in enumerate(partgen)
if len(part)>1 and part[1]!='0')
outfile.writelines(dnagen)
--
http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
* Roy Smith: In article , Mitchell L Model wrote: I use the sep and end keywords all the time. What are 'sep' and 'end'? I'm looking in http://docs.python.org/3.1/genindex-all.html and don't see those mentioned at all. Am I just looking in the wrong place? >>> print( print.__doc__ ) print(value, ..., sep=' ', end='\n', file=sys.stdout) Prints the values to a stream, or to sys.stdout by default. Optional keyword arguments: file: a file-like object (stream); defaults to the current sys.stdout. sep: string inserted between values, default a space. end: string appended after the last value, default a newline. >>> _ Cheers & hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Good Book
On Thu, Jan 28, 2010 at 11:09, talal awadh wrote: > Many people who want to learn Islam or are new converts find it hard I just wanted to thank you for reminding me that I needed to write a mail filter to delete this kind of drivel. I appreciate the reminder! Cheers, Jeff -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
On 01/28/10 19:37, Paul Rubin wrote: > Jonathan Gardner writes: >> If you're going to have statements, you're going to need the null >> statement. That's "pass". > > Why? Expressions are statements, so you could just say "pass" (in > quotes, denoting a string literal), or 0, or None, os anything else like > that, instead of having a special statement. or, if the null statement "pass" is removed, you could define: pass = None or pass = object() # sentinel and have essentially the same thing. hmm... on second thought, not special-casing pass means doing a LOAD_GLOBAL or LOAD_CONST for operation that is supposed to be doing nothing. -- http://mail.python.org/mailman/listinfo/python-list
RE: myths about python 3
Stefan wrote: > >From an implementors point of view, it's actually quite the opposite. Most > syntax features of Python 3 can be easily implemented on top of an existing > Py2 Implementation (we have most of them in Cython already, and I really > found them fun to write), and the shifting-around in the standard library > can hardly be called non-trivial. All the hard work that went into the > design of CPython 3.x (and into its test suite) now makes it easy to just > steal from what's there already. > > The amount of work that the Jython project put into catching up from 2.1 to > 2.5/6 (new style classes! generators!) is really humongous compared to the > adaptations that an implementation needs to do to support Python 3 code. I > have great respect for the Jython project for what they achieved in the > last couple of years. (I also have great respect for the IronPython project > for fighting the One Microsoft Way into opening up, but that's a different > kind of business.) > > If there was enough interest from the respective core developers, I > wouldn't be surprised if we had more than one 'mostly compatible' > alternative Python 3 implementation in a couple of months. But it's the > obvious vicious circle business. As long as there aren't enough important > users of Py3, alternative implementations won't have enough incentives to > refocus their scarce developer time. Going for 2.6/7 first means that most > of the Py3 work gets done anyway, so it'll be even easier then. That makes > 2.6->2.7->3.2/3 the most natural implementation path. (And that, again, > makes it a *really* good decision that 2.7 will be the last 2.x release line.) I just want to echo this as I completely agree. Last time I went through the list it looked like there were around 10 major new features (some of them even not so major) that we needed to implement to bring IronPython up to the 3.0 level. It shouldn't be too time consuming, and it greatly improves our compatibility by finally having the same string types, but our users don't yet want us to stop supporting 2.x. -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
Le Thu, 28 Jan 2010 00:19:24 +, Steven D'Aprano a écrit : > 4. Python 3 will make you irresistible to women. > > FALSE - Python 3 coders are no more likely to get a date than any > other programmer. They spend less time coding, so they /can/ get more "dates" (what a strange English word) :-) Those dates don't have to be with women of course. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
On 01/28/10 20:12, Alf P. Steinbach wrote: > * Steven D'Aprano: >> On Wed, 27 Jan 2010 18:29:25 +0100, Alf P. Steinbach wrote:> >> Instead of: >> >> print >>fileObj, x, y, z >> >> you use regular function syntax with a meaningful keyword: >> >> print(x, y, z, file=fileObj) >> >> If you want suppress the newline at the end of each print: >> >> print x, y, z, # note the final comma >> >> compared to: >> >> print(x, y, z, end='') > > Actually I thought the final comma thing was nice. It was like Basic. I > think the 2.x 'print' must have been modeled on Basic's 'print'. if that was true, then python missed the final semicolon >> If you want to change the space between elements, instead of: >> >> sys.stdout.write(str(x) + "*" + str(y) + "*" + str(z) + '\n') >> >> you use: >> >> print(x, y, z, sep='*') >> >> >> If you want to override the behaviour of print in a module, instead of >> having to edit the source code of the module (which might not even be >> available), all you need to do is monkey-patch it: >> >> import module >> module.print = myprint > > >>> import builtins > >>> > >>> org_print = print > >>> builtins.print = 666 > >>> > >>> print( "trallala" ) > Traceback (most recent call last): > File "", line 1, in > TypeError: 'int' object is not callable > >>> org_print( "but is that really so smart?" ) > but is that really so smart? > >>> _ Monkey patching follows (or should follow) the same rule as class inheritance overriding: the overrider's input domain must be a superset of the overriden's input domain and the overrider's output range must be a subset of the overriden's output range. 666 object (int) is not even remotely compatible with function object. -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
Le Wed, 27 Jan 2010 17:36:29 -0800, alex23 a écrit : > > I've been a big supporter of Py3 from the beginning, but this repeated > claim of US becoming the mainline interpreter for 3.x pretty much kills > dead a lot of my interest. As long as the U-S JIT can be disabled at compile-time (and also at runtime), I don't think there's much of a contention actually. The other changes probably aren't controversial, although I haven't looked at them. Antoine. -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
nn writes:
> On Jan 28, 10:50 am, evilweasel wrote:
>> I will make my question a little more clearer. I have close to 60,000
>> lines of the data similar to the one I posted. There are various
>> numbers next to the sequence (this is basically the number of times
>> the sequence has been found in a particular sample). So, I would need
>> to ignore the ones containing '0' and write all other sequences
>> (excluding the number, since it is trivial) in a new text file, in the
>> following format:
>>
>> >seq59902
>>
>> TTTATTATATAGT
>>
>> >seq59903
>>
>> TTTATTTCTTGGCGTTGT
>>
>> >seq59904
>>
>> TTTGGTTGCCCTGCGTGG
>>
>> >seq59905
>>
>> TTTGTTTATGGG
>>
>> The number next to 'seq' is the line number of the sequence. When I
>> run the above program, what I expect is an output file that is similar
>> to the above output but with the ones containing '0' ignored. But, I
>> am getting all the sequences printed in the file.
>>
>> Kindly excuse the 'newbieness' of the program. :) I am hoping to
>> improve in the next few months. Thanks to all those who replied. I
>> really appreciate it. :)
>
> People have already given you some pointers to your problem. In the
> end you will have to "tweak the details" because only you have access
> to the data not us.
>
> Just as example here is another way to do what you are doing:
>
> with open('dnain.dat') as infile, open('dnaout.dat','w') as outfile:
>partgen=(line.split() for line in infile)
>dnagen=(str(i+1)+'\n'+part[0]+'\n'
>for i,part in enumerate(partgen)
>if len(part)>1 and part[1]!='0')
>outfile.writelines(dnagen)
I think that generator expressions are overrated :) What's wrong with:
with open('dnain.dat') as infile, open('dnaout.dat','w') as outfile:
for i, line in enumerate(infile):
parts = line.split()
if len(parts) > 1 and parts[1] != '0':
outfile.write(">seq%s\n%s\n" % (i+1, parts[0]))
(untested)
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On 1/28/2010 10:50 AM, evilweasel wrote: I will make my question a little more clearer. I have close to 60,000 lines of the data similar to the one I posted. There are various numbers next to the sequence (this is basically the number of times the sequence has been found in a particular sample). So, I would need to ignore the ones containing '0' and write all other sequences (excluding the number, since it is trivial) in a new text file, in the following format: seq59902 TTTATTATATAGT seq59903 TTTATTTCTTGGCGTTGT seq59904 TTTGGTTGCCCTGCGTGG seq59905 TTTGTTTATGGG The number next to 'seq' is the line number of the sequence. When I run the above program, what I expect is an output file that is similar to the above output but with the ones containing '0' ignored. But, I am getting all the sequences printed in the file. Kindly excuse the 'newbieness' of the program. :) I am hoping to improve in the next few months. Thanks to all those who replied. I really appreciate it. :) Your program is a good first try. It contains a newbie error (looking for the number 0 instead of the string "0"). But more importantly, you're doing too much work yourself, rather than letting Python do the heavy lifting for you. These practices and tools make life a lot easier: * As others have noted, don't accumulate output in a list. Just write data to the output file line-by-line. * You don't need to initialize every variable at the beginning of the program. But there's no harm in it. * Use the enumerate() function to provide a line counter: for counter, line in enumerate(file1): This eliminates the need to accumulate output data in a list, then use the index variable "j" as the line counter. * Use string formatting. Each chunk of output is a two-line string, with the line-counter and the DNA sequence as variables: outformat = """seq%05d %s """ ... later, inside your loop ... resultsfile.write(outformat % (counter, sequence)) HTH, John -- http://mail.python.org/mailman/listinfo/python-list
Re: Stuck on a three word street name regex
> Correction:
>
> [snip] the expression "parts[1 : -1]" means gather list items from the
> second element in the list (index value 1) to one index position
> before the end of the list. [snip]
MRAB's solution was deserving of a more complete solution:
>>> def parse_address(address):
# Handles poorly-formatted addresses:
# 100 RAMPART S ST -- direction in wrong position
# 45 JOHN CHURCHILL CHASE ST -- two spaces before type
#addresslist = ['num', 'dir', 'name', 'type']
addresslist = ['', '', '', '']
parts = address.split()
if parts[-2] in ('E', 'W', 'N', 'S'):
addresslist[1] = parts[-2]
addresslist[2] = ' '.join(parts[1 : -2])
else:
addresslist[2] = ' '.join(parts[1 : -1])
addresslist[0] = parts[0]
addresslist[3] = parts[-1]
return addresslist
>>> parse_address('45 John Churchill Chase N St')
['45', 'N', 'John Churchill Chase', 'St']
>>> parse_address('45 John Churchill Chase St')
['45', '', 'John Churchill Chase', 'St']
--
http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
* Lie Ryan: On 01/28/10 20:12, Alf P. Steinbach wrote: >>> import builtins >>> >>> org_print = print >>> builtins.print = 666 >>> >>> print( "trallala" ) Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not callable >>> org_print( "but is that really so smart?" ) but is that really so smart? >>> _ Monkey patching follows (or should follow) the same rule as class inheritance overriding: the overrider's input domain must be a superset of the overriden's input domain and the overrider's output range must be a subset of the overriden's output range. 666 object (int) is not even remotely compatible with function object. Yes, that's my point. A 'print' replacement should ideally provide all the guarantees on behavior that standard 'print' does. And with that it's not so easy to put in a /correct/ replacement of 'print'; in particular, it has to honor the 'file' keyword argument. Thus the 3.x design makes it easy to replace 'print' incorrectly. I'd rather still had 'print' as keyword... ;-) Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Stuck on a three word street name regex
On Jan 28, 8:27 am, Lie Ryan wrote: > On 01/28/10 11:28, Brian D wrote: > > > > > I've tackled this kind of problem before by looping through a patterns > > dictionary, but there must be a smarter approach. > > > Two addresses. Note that the first has incorrectly transposed the > > direction and street name. The second has an extra space in it before > > the street type. Clearly done by someone who didn't know how to > > concatenate properly -- or didn't care. > > > 1000 RAMPART S ST > > > 100 JOHN CHURCHILL CHASE ST > > > I want to parse the elements into an array of values that can be > > inserted into new database fields. > > > Anyone who loves solving these kinds of puzzles care to relieve my > > frazzled brain? > > > The pattern I'm using doesn't keep the "CHASE" with the "JOHN > > CHURCHILL": > > How does the following perform? > > pat = > re.compile(r'(?P\d+)\s+(?P[A-Z\s]+)\s+(?PN|S|W|E|)\s+(?PST|RD|AVE?|)$') > > or more legibly: > > pat = re.compile( > r''' > (?P \d+ ) #M series of digits > \s+ > (?P [A-Z\s]+ ) #M one-or-more word > \s+ > (?P S?E|SW?|N?W|NE?| ) #O direction or nothing > \s+ > (?P ST|RD|AVE? ) #M street type > $ #M END > ''', re.VERBOSE) Is that all? That little empty space after the "|" OR metacharacter? Wow. As a test, to create a failure, if I remove that last "|" metacharacter from the "N|S|W|E|" string (i.e., "N|S|W|E"), the match fails on addresses that do not have that malformed direction after the street name (e.g., '45 JOHN CHURCHILL CHASE ST') Very clever. I don't think I've ever seen documentation showing that little trick. Thanks for enlightening me! -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Thu, 28 Jan 2010 18:49:02 +0100 Jean-Michel Pichavant wrote: > Using regexp may increase readability (if you are familiar with it). If you have a problem and you think that regular expressions are the solution then now you have two problems. Regex is really overkill for the OP's problem and it certainly doesn't improve readability. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Library support for Python 3.x
On 1/28/2010 1:37 AM, Paul Rubin wrote: David Cournapeau writes: That's not windows specific - most packages which distribute binary packages need to package binaries for every minor version (2.4, 2.5, etc...) I doubt that's what Paul was referring to, though - he seemed more concern with API/language changes than ABI issues. I didn't realize the ABI situation was that unstable. I thought you could just package up a .so or .dll and people could keep using it. I tend to not want to use extension modules that are not in the stdlib, and I guess this is another reason to keep staying away from them. My impression is that there is something 'special' about Windows (msvc) such that binaries compiled against x.y automatically do not work for x.y+1, even is the ABI is unchanged from Python's viewpoint. The point of my post that David responded to is that most Windows users have always been effectively dependent on 3rd party module/package developers to produce a new binary for each new version, whereas many *nix users could download the source and compile, or at least give it a go. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
evilweasel wrote:
I will make my question a little more clearer. I have close to 60,000
lines of the data similar to the one I posted. There are various
numbers next to the sequence (this is basically the number of times
the sequence has been found in a particular sample). So, I would need
to ignore the ones containing '0' and write all other sequences
(excluding the number, since it is trivial) in a new text file, in the
following format:
seq59902
TTTATTATATAGT
seq59903
TTTATTTCTTGGCGTTGT
seq59904
TTTGGTTGCCCTGCGTGG
seq59905
TTTGTTTATGGG
The number next to 'seq' is the line number of the sequence. When I
run the above program, what I expect is an output file that is similar
to the above output but with the ones containing '0' ignored. But, I
am getting all the sequences printed in the file.
Kindly excuse the 'newbieness' of the program. :) I am hoping to
improve in the next few months. Thanks to all those who replied. I
really appreciate it. :)
Using regexp may increase readability (if you are familiar with it).
What about
import re
output = open("sequences1.txt", 'w')
for index, line in enumerate(open(sys.argv[1], 'r')):
match = re.match('(?P[GATC]+)\s+1')
if match:
output.write('seq%s\n%s\n' % (index, match.group('sequence')))
Jean-Michel
--
http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
On 1/28/2010 3:37 AM, Paul Rubin wrote: Jonathan Gardner writes: If you're going to have statements, you're going to need the null statement. That's "pass". Why? Expressions are statements, so you could just say "pass" (in quotes, denoting a string literal), or 0, or None, os anything else like that, instead of having a special statement. As Python is currently compiled, you are right, pass is not needed. A string becomes the doc attribute, and becomes local var 0, but 0 is just ignored. I actually expected a load_const but that is now optimized away. I am not sure this was always true. Perhaps 'pass' is easier than '0' for mewcomers reading the tutorial, but I have no data. >>> def f(): '' >>> def g(): pass >>> def h(): 0 >>> from dis import dis >>> dis(f) 1 0 LOAD_CONST 1 (None) 3 RETURN_VALUE >>> dis(g) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> dis(h) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> f.__doc__ '' >>> g.__doc__ >>> Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
D'Arcy J.M. Cain wrote: On Thu, 28 Jan 2010 18:49:02 +0100 Jean-Michel Pichavant wrote: Using regexp may increase readability (if you are familiar with it). If you have a problem and you think that regular expressions are the solution then now you have two problems. Regex is really overkill for the OP's problem and it certainly doesn't improve readability. It depends on the reader ability to understand a *simple* regexp. It is also strange to get such answer after taking so much precautions, so let me quote myself: "Using regexp *may* increase readability (*if* you are *familiar* with it)." I honestly find it quite readable in the sample code I provided and spares all the if-len-startwith-strip logic, but If the OP does not agree, fine with me. But there's no need to get certain that I'm completly wrong. JM -- http://mail.python.org/mailman/listinfo/python-list
Wrap a function
I've to call to many functions with the format:
>>> run("cmd")
were "cmd" is a command with its arguments to pass them to the shell
and run it, i.e.
>>> run("pwd")
or
>>> run("ls /home")
Does anybody knows any library to help me to avoid the use of the main
quotes, and brackets?
I would to use anything as:
$ ls /home => run("ls /home")
or, at least
run pwd => run("pwd")
--
http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
On Jan 28, 8:10 am, a...@pythoncraft.com (Aahz) wrote: > In article , > Neil Hodgson wrote: > > >Carl Banks: > > >> There is also no hope someone will fork Python 2.x and continue it in > >> perpetuity. Well, someone might try to fork it, but they won't be > >> able to call it Python. > > > Over time there may be more desire from those unable or unwilling to > >upgrade to 3.x to work on improvements to 2.x, perhaps leading to a > >version 2.8. One of the benefits of open source is that you are not > >trapped into following vendor decisions like Microsoft abandoning > >classic VB in favour of VB.NET. > > > It would be unreasonable for the core developers to try to block > >this. Refusing use of the Python trademark for a version that was > >reasonably compatible in both directions would be particularly petty. > > Agreed, and as a PSF member, I'd certainly be opposed to anyone trying to > prevent the release of Python 2.8, and I would actively favor providing > PSF and python.org resources to them. OTOH, I would also be likely to > push anyone working on Python 2.8 to come up with a solid release plan > first. Well, I'd consider that an official release. Note that I didn't claim there was no hope PSF wouldn't change it's mind on 2.8. All I saying is that if PSF decides to shut down 2.x there's no hope of a rogue Python 2.x series replacing Python 3.x. Regardless of how magnaminous the people of PSF are, the unfortunate reality is that trademark owners are forced by the law to be "particularly petty". PSF's IP lawyer will advise not to allow unsanctioned fork of Python 2.7 to call itself Python 2.8. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Why doesn't "filterwarnings" suppress this message?
Feedparser isn't supported for Python 3.0, so in Python 2.6, many warning messages appear. I'm trying, in Python 2.6, to suppress the warning message: ./feedparser\feedparser.py:69: DeprecationWarning: the sgmllib module has been removed in Python 3.0 import sgmllib, re, sys, copy, urlparse, time, rfc822, types, cgi, urllib, urllib2 with this warning filter: warnings.filterwarnings(action='ignore', category=DeprecationWarning, module='feedparser') The filter suppresses other deprecation warnings associated with the feedparser module, but not that one. How do I get rid of that one? And no, warnings.filterwarnings(action='ignore', category=DeprecationWarning, module='sgmllib') doesn't do it. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On 01/28/2010 09:49 AM, Jean-Michel Pichavant wrote:
evilweasel wrote:
I will make my question a little more clearer. I have close to 60,000
lines of the data similar to the one I posted. There are various
numbers next to the sequence (this is basically the number of times
the sequence has been found in a particular sample). So, I would need
to ignore the ones containing '0' and write all other sequences
(excluding the number, since it is trivial) in a new text file, in the
following format:
seq59902
TTTATTATATAGT
seq59903
TTTATTTCTTGGCGTTGT
seq59904
TTTGGTTGCCCTGCGTGG
seq59905
TTTGTTTATGGG
The number next to 'seq' is the line number of the sequence. When I
run the above program, what I expect is an output file that is similar
to the above output but with the ones containing '0' ignored. But, I
am getting all the sequences printed in the file.
Kindly excuse the 'newbieness' of the program. :) I am hoping to
improve in the next few months. Thanks to all those who replied. I
really appreciate it. :)
Using regexp may increase readability (if you are familiar with it).
What about
import re
output = open("sequences1.txt", 'w')
for index, line in enumerate(open(sys.argv[1], 'r')):
match = re.match('(?P[GATC]+)\s+1')
if match:
output.write('seq%s\n%s\n' % (index, match.group('sequence')))
Jean-Michel
Finally!
After ready 8 or 9 messages about find a line ending with '1', someone
suggests Regex.
It was my first thought.
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
On 1/28/2010 11:03 AM, Mitchell L Model wrote: I have been working with Python 3 for over a year. I used it in writing my book "Bioinformatics Programming Using Python" (http://oreilly.com/catalog/9780596154509). I didn't see any point in teaching an incompatible earlier version of a language in transition. In preparing the book and its examples I explored a large number of Python modules in some depth and encountered most of the differences between the language and libraries of Python 2 and Python 3. The change was a bit awkward for a while, and there were some surprises, but in the end I have found nothing in Python 3 for which I would prefer Python 2's version. Removal of old-style classes is a big win. Having print as a function provides a tremendous amount of flexibility. I use the sep and end keywords all the time. There is no reason for print to be a statement, and it was an awkward inconsistency in a language that leans towards functional styles. Likewise the elimination of cmp, while shocking, leads to much simpler comparison arguments to sort, since all the function does is return a key; then, sort uses __lt__ (I think) so it automatically uses each class's definition of that. The weird objects returned from things like sorted, dict.keys/values/items, and so on are values that in practice are used primarily in iterations; you can always turn the result into a list, though I have to admit that while developing and debugging I trip trying to pick out a specific element from one of these using indexing (typically [0]); I've learned to think of them as generators, even though they aren't. The rearrangements and name changes in the libraries are quite helpful. I could go on, but basically the language and library changes are on the whole large improvements with little, if any, downside. I agree completely. Conversion of old code is greatly facilitied by the 2to3 tool that comes with Python 3. The big issue in moving from 2 to 3 is the external libraries and development tools you use. Different IDEs have released versions that support Python 3 at different times. (I believe Wing was the first.) If you use numpy, for example, or one of the many libraries that require it, you are stuck. Possibly some important facilities will never be ported to Python 3, but probably most active projects will eventually produce a Python 3 version -- for example, according to its web page, a Python 3 version of PIL is on the way. I was able to cover all the topics in my book using only Python library modules, something I felt would be best for readers -- I used libraries such as elementree, sqlite3, and tkinter. The only disappointment was that I couldn't include a chapter on BioPython, since there is no Python 3 version. By now, many large facilities support both Python 2 and Python 3. I am currently building a complex GUI/Visualization application based on the Python 3 version of PyQt4 and Wing IDE and am delighted with all of it. It may well be that some very important large Something got clipped ;-) Anyway, thank you for the report. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Jan 28, 12:28 pm, Steven Howe wrote:
> On 01/28/2010 09:49 AM, Jean-Michel Pichavant wrote:
>
>
>
>
>
> > evilweasel wrote:
> >> I will make my question a little more clearer. I have close to 60,000
> >> lines of the data similar to the one I posted. There are various
> >> numbers next to the sequence (this is basically the number of times
> >> the sequence has been found in a particular sample). So, I would need
> >> to ignore the ones containing '0' and write all other sequences
> >> (excluding the number, since it is trivial) in a new text file, in the
> >> following format:
>
> >>> seq59902
> >> TTTATTATATAGT
>
> >>> seq59903
> >> TTTATTTCTTGGCGTTGT
>
> >>> seq59904
> >> TTTGGTTGCCCTGCGTGG
>
> >>> seq59905
> >> TTTGTTTATGGG
>
> >> The number next to 'seq' is the line number of the sequence. When I
> >> run the above program, what I expect is an output file that is similar
> >> to the above output but with the ones containing '0' ignored. But, I
> >> am getting all the sequences printed in the file.
>
> >> Kindly excuse the 'newbieness' of the program. :) I am hoping to
> >> improve in the next few months. Thanks to all those who replied. I
> >> really appreciate it. :)
> > Using regexp may increase readability (if you are familiar with it).
> > What about
>
> > import re
>
> > output = open("sequences1.txt", 'w')
>
> > for index, line in enumerate(open(sys.argv[1], 'r')):
> > match = re.match('(?P[GATC]+)\s+1')
> > if match:
> > output.write('seq%s\n%s\n' % (index, match.group('sequence')))
>
> > Jean-Michel
>
> Finally!
>
> After ready 8 or 9 messages about find a line ending with '1', someone
> suggests Regex.
> It was my first thought.
And as a first thought, it is, of course, wrong.
You don't want lines ending in '1', you want ANY non-'0' amount.
Likewise, you don't want to exclude lines ending in '0' because
you'll end up excluding counts of 10, 20, 30, etc.
You need a regex that extracts ALL the numeric characters at the end
of the
line and exclude those that evaluate to 0.
>
> Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't "filterwarnings" suppress this message?
John Nagle wrote: > Feedparser isn't supported for Python 3.0, so in Python 2.6, many > warning > messages appear. I'm trying, in Python 2.6, to suppress the warning > message: > > ./feedparser\feedparser.py:69: DeprecationWarning: > the sgmllib module has been removed in Python 3.0 > import sgmllib, re, sys, copy, urlparse, time, rfc822, types, > cgi, urllib, urllib2 > > with this warning filter: > > warnings.filterwarnings(action='ignore', > category=DeprecationWarning, module='feedparser') > > The filter suppresses other deprecation warnings associated with > the feedparser module, but not that one. How do I get rid of that > one? > > And no, > > warnings.filterwarnings(action='ignore', > category=DeprecationWarning, module='sgmllib') > > doesn't do it. > > John Nagle I can't confirm that: $ cat nowarning.py import sys if "--off" in sys.argv: import warnings warnings.filterwarnings(action="ignore", category=DeprecationWarning, module="feedparser") import feedparser $ python nowarning.py $ python -3 nowarning.py /usr/lib/python2.6/site.py:1: DeprecationWarning: The 'new' module has been removed in Python 3.0; use the 'types' module instead. """Append module search paths for third-party packages to sys.path. /usr/lib/pymodules/python2.6/feedparser.py:69: DeprecationWarning: the sgmllib module has been removed in Python 3.0 import sgmllib, re, sys, copy, urlparse, time, rfc822, types, cgi, urllib, urllib2 /usr/lib/pymodules/python2.6/feedparser.py:69: DeprecationWarning: in 3.x, rfc822 has been removed in favor of the email package import sgmllib, re, sys, copy, urlparse, time, rfc822, types, cgi, urllib, urllib2 $ python -3 nowarning.py --off /usr/lib/python2.6/site.py:1: DeprecationWarning: The 'new' module has been removed in Python 3.0; use the 'types' module instead. """Append module search paths for third-party packages to sys.path. $ python -V Python 2.6.4 Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On 2010-01-28, Joan Miller wrote:
> I've to call to many functions with the format:
>
run("cmd")
Check the docs on os.system().
--
Josh "dutchie" Holland
http://www.joshh.co.uk/
http://twitter.com/jshholland
http://identi.ca/jshholland
--
http://mail.python.org/mailman/listinfo/python-list
Great example of a python module/package following up to date conventions.
I'm hoping someone on here can point me to an example of a python package that is a great example of how to put it all together. I'm hoping for example code that demonstrates: -Strict adherence to PEP 8 -thorough use of Docstrings -Conventional directory structure/package layout -Appropriate use of the latest accepted coding guidelines in the python community (e.g., new classes versus old classes, Python 3000 compatibility, newer language features, etc. etc.) -Some amount of object oriented design Bonus: -Unit tests -Logging mechanism I can't imagine a package that's been around longer than a few years will hit upon all these things well unless the maintainer went back and did some serious refactoring and re-tooling. Is this question possible to answer? -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On 28 ene, 19:16, Josh Holland wrote:
> On 2010-01-28, Joan Miller wrote:
>
> > I've to call to many functions with the format:
>
> run("cmd")
>
> Check the docs on os.system().
No. I've a function that uses subprocess to run commands on the same
shell and so substitute to bash scrips. But a script full of run
("shell_command --with --arguments") is too verbose.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Great example of a python module/package following up to date conventions.
On 2010-01-28, Big Stu wrote: > I'm hoping someone on here can point me to an example of a python > package that is a great example of how to put it all together. I'm > hoping for example code that demonstrates: Surely most of the Standard Library should satisfy all your requirements? -- Josh "dutchie" Holland http://www.joshh.co.uk/ http://twitter.com/jshholland http://identi.ca/jshholland -- http://mail.python.org/mailman/listinfo/python-list
Re: python 3's adoption
On 2010-01-28 17:03, Mitchell L Model wrote: I have been working with Python 3 for over a year. I used it in writing my book "Bioinformatics Programming Using Python" (http://oreilly.com/catalog/9780596154509). That book sounds very interesting, even though I am more interested in the bioinformatic parts, I already know some python. I'll show my boss the link, thanks! - Fencer -- http://mail.python.org/mailman/listinfo/python-list
Re: Great example of a python module/package following up to date conventions.
On 07:28 pm, j...@joshh.co.uk wrote: On 2010-01-28, Big Stu wrote: I'm hoping someone on here can point me to an example of a python package that is a great example of how to put it all together. I'm hoping for example code that demonstrates: Surely most of the Standard Library should satisfy all your requirements? Have you actually looked at any of the standard library? Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Great example of a python module/package following up to date conventions.
On Jan 28, 2:28 pm, Josh Holland wrote: > On 2010-01-28, Big Stu wrote: > > > I'm hoping someone on here can point me to an example of a python > > package that is a great example of how to put it all together. I'm > > hoping for example code that demonstrates: > > Surely most of the Standard Library should satisfy all your > requirements? > > -- > Josh "dutchie" Holland > http://www.joshh.co.uk/http://twitter.com/jshhollandhttp://identi.ca/jshholland That's definitely a place I've started to poke around, but the standard library stuff always comes to me by way of my standard python installation. I was hoping to have a template of a 3rd party package to follow. Complete with conventions to follow for easily packaging and distributing via the usual python channels (pypi, easy_install, egg, etc.). -- http://mail.python.org/mailman/listinfo/python-list
Re: Great example of a python module/package following up to date conventions.
On 28 ene, 19:17, Big Stu wrote: > I'm hoping someone on here can point me to an example of a python > package that is a great example of how to put it all together. I'm > hoping for example code that demonstrates: > > -Strict adherence to PEP 8 > -thorough use of Docstrings > -Conventional directory structure/package layout > -Appropriate use of the latest accepted coding guidelines in the > python community (e.g., new classes versus old classes, Python 3000 > compatibility, newer language features, etc. etc.) > -Some amount of object oriented design > > Bonus: > -Unit tests > -Logging mechanism > > I can't imagine a package that's been around longer than a few years > will hit upon all these things well unless the maintainer went back > and did some serious refactoring and re-tooling. > > Is this question possible to answer? Look here: http://bitbucket.org/ares/scripy/src/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Great example of a python module/package following up to date conventions.
On 2010-01-28, exar...@twistedmatrix.com wrote: > Have you actually looked at any of the standard library? Not recently or in depth, no. I would have thought that it would be of high quality. I must have been mistaken. -- Josh "dutchie" Holland http://www.joshh.co.uk/ http://twitter.com/jshholland http://identi.ca/jshholland -- http://mail.python.org/mailman/listinfo/python-list
Re: Great example of a python module/package following up to date conventions.
> Have you actually looked at any of the standard library? > > Jean-Paul I'm looking at urllib2 right now and it is covering a bunch of the bases I'm looking for. And grepping in the /usr/lib/python2.5/ folder for import statements on various things I'm interested in is bringing up some good examples to check out as well. Given that I'm still fairly novice to this I'm not yet in the position to make a good judgment on what is and isn't a good python practice so I was hoping someone on here might be able to point at a module or 2 that has really done a good job of following best practices. Seems like a reasonable question with an answer that others in a similar position to me might find useful. -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
Carl Banks wrote: > On Jan 28, 8:10 am, a...@pythoncraft.com (Aahz) wrote: >> In article , >> Neil Hodgson wrote: >> >>> Carl Banks: There is also no hope someone will fork Python 2.x and continue it in perpetuity. Well, someone might try to fork it, but they won't be able to call it Python. >>> Over time there may be more desire from those unable or unwilling to >>> upgrade to 3.x to work on improvements to 2.x, perhaps leading to a >>> version 2.8. One of the benefits of open source is that you are not >>> trapped into following vendor decisions like Microsoft abandoning >>> classic VB in favour of VB.NET. >>> It would be unreasonable for the core developers to try to block >>> this. Refusing use of the Python trademark for a version that was >>> reasonably compatible in both directions would be particularly petty. >> Agreed, and as a PSF member, I'd certainly be opposed to anyone trying to >> prevent the release of Python 2.8, and I would actively favor providing >> PSF and python.org resources to them. OTOH, I would also be likely to >> push anyone working on Python 2.8 to come up with a solid release plan >> first. > > Well, I'd consider that an official release. Note that I didn't claim > there was no hope PSF wouldn't change it's mind on 2.8. All I saying > is that if PSF decides to shut down 2.x there's no hope of a rogue > Python 2.x series replacing Python 3.x. > > Regardless of how magnaminous the people of PSF are, the unfortunate > reality is that trademark owners are forced by the law to be > "particularly petty". PSF's IP lawyer will advise not to allow > unsanctioned fork of Python 2.7 to call itself Python 2.8. > But if it were sanctioned ... ? We *are* pretty magnanimous ;-) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
Joan Miller wrote:
> On 28 ene, 19:16, Josh Holland wrote:
>> On 2010-01-28, Joan Miller wrote:
>>
>>> I've to call to many functions with the format:
>> run("cmd")
>> Check the docs on os.system().
> No. I've a function that uses subprocess to run commands on the same
> shell and so substitute to bash scrips. But a script full of run
> ("shell_command --with --arguments") is too verbose.
So rewrite the script to read the commands from a file and execute them
one by one?
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
--
http://mail.python.org/mailman/listinfo/python-list
Why am I getting this Error message
Why am I getting the following error message. Area has been declared as an attribute of Circle. Thanks, Ray class Circle: def __init__(self): self.radius = 1 def area(self): return self.radius * self.radius * 3.14159 c = Circle() c.radius = 3 print c.area() Traceback (most recent call last): File "", line 1, in class Circle: File "", line 8, in Circle print c.area() AttributeError: Circle instance has no attribute 'area' -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
Steven Howe wrote:
On 01/28/2010 09:49 AM, Jean-Michel Pichavant wrote:
evilweasel wrote:
I will make my question a little more clearer. I have close to 60,000
lines of the data similar to the one I posted. There are various
numbers next to the sequence (this is basically the number of times
the sequence has been found in a particular sample). So, I would need
to ignore the ones containing '0' and write all other sequences
(excluding the number, since it is trivial) in a new text file, in the
following format:
seq59902
TTTATTATATAGT
seq59903
TTTATTTCTTGGCGTTGT
seq59904
TTTGGTTGCCCTGCGTGG
seq59905
TTTGTTTATGGG
The number next to 'seq' is the line number of the sequence. When I
run the above program, what I expect is an output file that is similar
to the above output but with the ones containing '0' ignored. But, I
am getting all the sequences printed in the file.
Kindly excuse the 'newbieness' of the program. :) I am hoping to
improve in the next few months. Thanks to all those who replied. I
really appreciate it. :)
Using regexp may increase readability (if you are familiar with it).
What about
import re
output = open("sequences1.txt", 'w')
for index, line in enumerate(open(sys.argv[1], 'r')):
match = re.match('(?P[GATC]+)\s+1')
if match:
output.write('seq%s\n%s\n' % (index, match.group('sequence')))
Jean-Michel
Finally!
After ready 8 or 9 messages about find a line ending with '1', someone
suggests Regex.
It was my first thought.
I'm a great fan of regexes, but I never though of using them for this
because it doesn't look like a regex type of problem to me.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On 1/28/2010 2:24 PM, Joan Miller wrote:
On 28 ene, 19:16, Josh Holland wrote:
On 2010-01-28, Joan Miller wrote:
I've to call to many functions with the format:
run("cmd")
Check the docs on os.system().
No. I've a function that uses subprocess to run commands on the same
shell and so substitute to bash scrips. But a script full of run
("shell_command --with --arguments") is too verbose.
I'm suspicious of your original intent. Essentially, you want to write
code in which a literal string, such as ...
ls -l
... is *not* enclosed in quotes. Why run the risk of creating confusion
(in other people who look at your code, in syntax-checking tools, etc.)
between variables and literals?
But I'm in sympathy with your desire to make the code as clean as
possible and to minimize the number of times you have to type a quote
character. My suggestions:
1. Create a function (say, "Run") that encapsulates as much of the
syntax as possible: os.system(), subprocess.call(), string-splitting,
whatever. So an invocation would look like this:
Run("ls -l *.txt")
(I think you've already done this step.)
2. Find a text editor that supports keyboard macros, so that a single
keystroke turns this text line:
ls -l *.txt
... into this one:
Run("ls -l *.txt")
HTH,
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On 28 ene, 19:54, Steve Holden wrote:
> Joan Miller wrote:
> > On 28 ene, 19:16, Josh Holland wrote:
> >> On 2010-01-28, Joan Miller wrote:
>
> >>> I've to call to many functions with the format:
> >> run("cmd")
> >> Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> So rewrite the script to read the commands from a file and execute them
> one by one?
>
I had thinked about that but the problem is that I would that were
mixed with python code, so can be get the output from a system command
and manipulate it from python
--
http://mail.python.org/mailman/listinfo/python-list
Re: Great example of a python module/package following up to date conventions.
On 07:49 pm, stu.dohe...@gmail.com wrote: Have you actually looked at any of the standard library? Jean-Paul I'm looking at urllib2 right now and it is covering a bunch of the bases I'm looking for. And grepping in the /usr/lib/python2.5/ folder for import statements on various things I'm interested in is bringing up some good examples to check out as well. Given that I'm still fairly novice to this I'm not yet in the position to make a good judgment on what is and isn't a good python practice so I was hoping someone on here might be able to point at a module or 2 that has really done a good job of following best practices. Seems like a reasonable question with an answer that others in a similar position to me might find useful. You're right. I was actually wondering if Josh had looked before suggesting it. :) The stdlib varies wildly in quality, with much of it not serving as a particular good example of most of the points you mentioned. urllib2 is probably better than a lot, but, for example, even it only manages about 75% line coverage by its test suite. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On 28 ene, 19:58, John Posner wrote:
> On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > On 28 ene, 19:16, Josh Holland wrote:
> >> On 2010-01-28, Joan Miller wrote:
>
> >>> I've to call to many functions with the format:
>
> >> run("cmd")
>
> >> Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> I'm suspicious of your original intent. Essentially, you want to write
> code in which a literal string, such as ...
>
> ls -l
>
> ... is *not* enclosed in quotes. Why run the risk of creating confusion
> (in other people who look at your code, in syntax-checking tools, etc.)
> between variables and literals?
Yes but to that code could be prepend a sign as '$' to be identified
and so be parsed.
>
> But I'm in sympathy with your desire to make the code as clean as
> possible and to minimize the number of times you have to type a quote
> character. My suggestions:
>
> 1. Create a function (say, "Run") that encapsulates as much of the
> syntax as possible: os.system(), subprocess.call(), string-splitting,
> whatever. So an invocation would look like this:
>
> Run("ls -l *.txt")
>
> (I think you've already done this step.)
Yes, I made a funtion very cool to call to system commands, that works
well with pipes and passes the variables (i.e. "LANG=C grep -e 'foo' /
home")
> 2. Find a text editor that supports keyboard macros, so that a single
> keystroke turns this text line:
>
> ls -l *.txt
>
> ... into this one:
>
> Run("ls -l *.txt")
This is not what I'm looking for. I'm supposing that could be solved
with a DSL or a macro library, any?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why am I getting this Error message
On Thu, Jan 28, 2010 at 11:57 AM, Ray Holt wrote: > Why am I getting the following error message. Area has been declared as an > attribute of Circle. Thanks, Ray > > class Circle: > def __init__(self): > self.radius = 1 > def area(self): > return self.radius * self.radius * 3.14159 > c = Circle() > c.radius = 3 > print c.area() > > Traceback (most recent call last): > File "", line 1, in > class Circle: > File "", line 8, in Circle > print c.area() > AttributeError: Circle instance has no attribute 'area' Unable to reproduce: Python 2.6.4 (r264:75706, Dec 20 2009, 15:52:35) [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin >>> class Circle: ... def __init__(self): ... self.radius = 1 ... def area(self): ... return self.radius * self.radius * 3.14159 ... >>> c = Circle() >>> c.radius = 3 >>> print c.area() 28.27431 Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On Jan 28, 12:13 pm, Joan Miller wrote:
> On 28 ene, 19:58, John Posner wrote:
>
>
>
> > On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > > On 28 ene, 19:16, Josh Holland wrote:
> > >> On 2010-01-28, Joan Miller wrote:
>
> > >>> I've to call to many functions with the format:
>
> > >> run("cmd")
>
> > >> Check the docs on os.system().
> > > No. I've a function that uses subprocess to run commands on the same
> > > shell and so substitute to bash scrips. But a script full of run
> > > ("shell_command --with --arguments") is too verbose.
>
> > I'm suspicious of your original intent. Essentially, you want to write
> > code in which a literal string, such as ...
>
> > ls -l
>
> > ... is *not* enclosed in quotes. Why run the risk of creating confusion
> > (in other people who look at your code, in syntax-checking tools, etc.)
> > between variables and literals?
>
> Yes but to that code could be prepend a sign as '$' to be identified
> and so be parsed.
>
>
>
> > But I'm in sympathy with your desire to make the code as clean as
> > possible and to minimize the number of times you have to type a quote
> > character. My suggestions:
>
> > 1. Create a function (say, "Run") that encapsulates as much of the
> > syntax as possible: os.system(), subprocess.call(), string-splitting,
> > whatever. So an invocation would look like this:
>
> > Run("ls -l *.txt")
>
> > (I think you've already done this step.)
>
> Yes, I made a funtion very cool to call to system commands, that works
> well with pipes and passes the variables (i.e. "LANG=C grep -e 'foo' /
> home")
>
> > 2. Find a text editor that supports keyboard macros, so that a single
> > keystroke turns this text line:
>
> > ls -l *.txt
>
> > ... into this one:
>
> > Run("ls -l *.txt")
>
> This is not what I'm looking for. I'm supposing that could be solved
> with a DSL or a macro library, any?
Python is not perl.
Thank God/Guido.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On Jan 29, 6:58 am, John Posner wrote:
> On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > On 28 ene, 19:16, Josh Holland wrote:
> >> On 2010-01-28, Joan Miller wrote:
>
> >>> I've to call to many functions with the format:
>
> >> run("cmd")
>
> >> Check the docs on os.system().
> > No. I've a function that uses subprocess to run commands on the same
> > shell and so substitute to bash scrips. But a script full of run
> > ("shell_command --with --arguments") is too verbose.
>
> I'm suspicious of your original intent. Essentially, you want to write
> code in which a literal string, such as ...
>
> ls -l
>
> ... is *not* enclosed in quotes. Why run the risk of creating confusion
> (in other people who look at your code, in syntax-checking tools, etc.)
> between variables and literals?
>
> But I'm in sympathy with your desire to make the code as clean as
> possible and to minimize the number of times you have to type a quote
> character. My suggestions:
>
> 1. Create a function (say, "Run") that encapsulates as much of the
> syntax as possible: os.system(), subprocess.call(), string-splitting,
> whatever. So an invocation would look like this:
>
> Run("ls -l *.txt")
>
> (I think you've already done this step.)
>
> 2. Find a text editor that supports keyboard macros, so that a single
> keystroke turns this text line:
>
> ls -l *.txt
>
> ... into this one:
>
> Run("ls -l *.txt")
>
> HTH,
> John
I can't see you avoiding quotes etc, but extending on John's comment,
the obvious next step would be to run everything in a loop i.e. place
all the commands into a list and create a loop that ran each command
in the list.
Almost all editors support macros - most editors support some form of
language sensitive editing (NOT the prompt call parameters style but
rather help with the syntax via a 'form' style of fill-in) that will
allow you to reduce typing effort. But macros would be the first and
easiest choice for this activity.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why am I getting this Error message
Ray Holt wrote: > Why am I getting the following error message. Area has been declared as > an attribute of Circle. Thanks, Ray > > > class Circle: > def __init__(self): > self.radius = 1 > def area(self): > return self.radius * self.radius * 3.14159 > c = Circle() > c.radius = 3 > print c.area() > > > > Traceback (most recent call last): > File "", line 1, in > class Circle: > File "", line 8, in Circle > print c.area() > AttributeError: Circle instance has no attribute 'area' > Because you have indented the last three lines to make them a part of the Circle definition. Generally four spaces makes a better indent, and that kind of problem is then much more obvious. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Why am I getting this Error message
Ray Holt wrote: Why am I getting the following error message. Area has been declared as an attribute of Circle. Thanks, Ray class Circle: def __init__(self): self.radius = 1 def area(self): return self.radius * self.radius * 3.14159 c = Circle() c.radius = 3 print c.area() Traceback (most recent call last): File "", line 1, in class Circle: File "", line 8, in Circle print c.area() AttributeError: Circle instance has no attribute 'area' Probably incorrect indentation. This works: class Circle: def __init__(self): self.radius = 1 def area(self): return self.radius * self.radius * 3.14159 c = Circle() c.radius = 3 print c.area() -- http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On 28 ene, 20:20, Peter wrote:
> On Jan 29, 6:58 am, John Posner wrote:
>
>
>
> > On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > > On 28 ene, 19:16, Josh Holland wrote:
> > >> On 2010-01-28, Joan Miller wrote:
>
> > >>> I've to call to many functions with the format:
>
> > >> run("cmd")
>
> > >> Check the docs on os.system().
> > > No. I've a function that uses subprocess to run commands on the same
> > > shell and so substitute to bash scrips. But a script full of run
> > > ("shell_command --with --arguments") is too verbose.
>
> > I'm suspicious of your original intent. Essentially, you want to write
> > code in which a literal string, such as ...
>
> > ls -l
>
> > ... is *not* enclosed in quotes. Why run the risk of creating confusion
> > (in other people who look at your code, in syntax-checking tools, etc.)
> > between variables and literals?
>
> > But I'm in sympathy with your desire to make the code as clean as
> > possible and to minimize the number of times you have to type a quote
> > character. My suggestions:
>
> > 1. Create a function (say, "Run") that encapsulates as much of the
> > syntax as possible: os.system(), subprocess.call(), string-splitting,
> > whatever. So an invocation would look like this:
>
> > Run("ls -l *.txt")
>
> > (I think you've already done this step.)
>
> > 2. Find a text editor that supports keyboard macros, so that a single
> > keystroke turns this text line:
>
> > ls -l *.txt
>
> > ... into this one:
>
> > Run("ls -l *.txt")
>
> > HTH,
> > John
>
> I can't see you avoiding quotes etc, but extending on John's comment,
> the obvious next step would be to run everything in a loop i.e. place
> all the commands into a list and create a loop that ran each command
> in the list.
Yes, but could be necessary that were mixed with python code.
> Almost all editors support macros - most editors support some form of
> language sensitive editing (NOT the prompt call parameters style but
> rather help with the syntax via a 'form' style of fill-in) that will
> allow you to reduce typing effort. But macros would be the first and
> easiest choice for this activity.
The goal of my program is substitute to bash scripts, so the macros in
editors are irrelevant fo this one.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Wrap a function
On 28 ene, 20:34, Joan Miller wrote:
> On 28 ene, 20:20, Peter wrote:
>
> > On Jan 29, 6:58 am, John Posner wrote:
>
> > > On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > > > On 28 ene, 19:16, Josh Holland wrote:
> > > >> On 2010-01-28, Joan Miller wrote:
>
> > > >>> I've to call to many functions with the format:
>
> > > >> run("cmd")
>
> > > >> Check the docs on os.system().
> > > > No. I've a function that uses subprocess to run commands on the same
> > > > shell and so substitute to bash scrips. But a script full of run
> > > > ("shell_command --with --arguments") is too verbose.
>
> > > I'm suspicious of your original intent. Essentially, you want to write
> > > code in which a literal string, such as ...
>
> > > ls -l
>
> > > ... is *not* enclosed in quotes. Why run the risk of creating confusion
> > > (in other people who look at your code, in syntax-checking tools, etc.)
> > > between variables and literals?
>
> > > But I'm in sympathy with your desire to make the code as clean as
> > > possible and to minimize the number of times you have to type a quote
> > > character. My suggestions:
>
> > > 1. Create a function (say, "Run") that encapsulates as much of the
> > > syntax as possible: os.system(), subprocess.call(), string-splitting,
> > > whatever. So an invocation would look like this:
>
> > > Run("ls -l *.txt")
>
> > > (I think you've already done this step.)
>
> > > 2. Find a text editor that supports keyboard macros, so that a single
> > > keystroke turns this text line:
>
> > > ls -l *.txt
>
> > > ... into this one:
>
> > > Run("ls -l *.txt")
>
> > > HTH,
> > > John
>
> > I can't see you avoiding quotes etc, but extending on John's comment,
> > the obvious next step would be to run everything in a loop i.e. place
> > all the commands into a list and create a loop that ran each command
> > in the list.
>
> Yes, but could be necessary that were mixed with python code.
>
> > Almost all editors support macros - most editors support some form of
> > language sensitive editing (NOT the prompt call parameters style but
> > rather help with the syntax via a 'form' style of fill-in) that will
> > allow you to reduce typing effort. But macros would be the first and
> > easiest choice for this activity.
>
> The goal of my program is substitute to bash scripts, so the macros in
> editors are irrelevant fo this one.
I think that the best solution that I've is to build a program that
parses the script to convert *$ command* to run("command") before of
be called by python.
--
http://mail.python.org/mailman/listinfo/python-list
mix statically typed with dynamically typed
We all know that Python is dynamically typed, and dynamically typed languages are generally slower than statically typed ones. I wonder if it is possible at all for Python to mix statically-typed-ness with dynamically-typed-ness to boost up its speed a little bit, especially when speed is needed. For example, you define a function like this: def speed(float dist, float time): return dist/time then the compiler would generate code to first check parameter types (or even do some casts if appropriate, say cast an int into float) in the beginning of this function. and the rest of the function would then be compiled with the assumption that 'dist' and 'time' are of the type float. Of course, dynamically-typed-ness is still the same as before. Python is well known for providing multiple programming paradigms, I wonder if we could also sneak this in nicely. Any thoughts? -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
On 1/28/2010 2:51 PM, Steve Holden wrote: Carl Banks wrote: Regardless of how magnaminous the people of PSF are, the unfortunate reality is that trademark owners are forced by the law to be "particularly petty". PSF's IP lawyer will advise not to allow unsanctioned fork of Python 2.7 to call itself Python 2.8. But if it were sanctioned ... ? We *are* pretty magnanimous ;-) I think it foolish to speculate in the absence of specifics. If some people wanted to coninue bug-fix maintainance of 2.7 after the main group of developers is done with it, in 5 years, then no new name is needed. If some people wanted to backport additional 3.x features, while still keeping the old, obsolete stuff around, then '2.8' would be appropriate. If some people wanted to add a collection of incompatible new features, perhaps some that Guido has rejected for 'Python', so that they were producing a real fork, then a new name should be used. I consider the first option possible, assuming that significant bugs still remain in 5 years. The second seems more dubious, as the developers have already backported most of what they thought sensible. The third has always been possible, and has been done, and there would be nothing really special about using 2.7 as a base. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
Arnaud Delobelle wrote:
> nn writes:
>
> > On Jan 28, 10:50 am, evilweasel wrote:
> >> I will make my question a little more clearer. I have close to 60,000
> >> lines of the data similar to the one I posted. There are various
> >> numbers next to the sequence (this is basically the number of times
> >> the sequence has been found in a particular sample). So, I would need
> >> to ignore the ones containing '0' and write all other sequences
> >> (excluding the number, since it is trivial) in a new text file, in the
> >> following format:
> >>
> >> >seq59902
> >>
> >> TTTATTATATAGT
> >>
> >> >seq59903
> >>
> >> TTTATTTCTTGGCGTTGT
> >>
> >> >seq59904
> >>
> >> TTTGGTTGCCCTGCGTGG
> >>
> >> >seq59905
> >>
> >> TTTGTTTATGGG
> >>
> >> The number next to 'seq' is the line number of the sequence. When I
> >> run the above program, what I expect is an output file that is similar
> >> to the above output but with the ones containing '0' ignored. But, I
> >> am getting all the sequences printed in the file.
> >>
> >> Kindly excuse the 'newbieness' of the program. :) I am hoping to
> >> improve in the next few months. Thanks to all those who replied. I
> >> really appreciate it. :)
> >
> > People have already given you some pointers to your problem. In the
> > end you will have to "tweak the details" because only you have access
> > to the data not us.
> >
> > Just as example here is another way to do what you are doing:
> >
> > with open('dnain.dat') as infile, open('dnaout.dat','w') as outfile:
> >partgen=(line.split() for line in infile)
> >dnagen=(str(i+1)+'\n'+part[0]+'\n'
> >for i,part in enumerate(partgen)
> >if len(part)>1 and part[1]!='0')
> >outfile.writelines(dnagen)
>
> I think that generator expressions are overrated :) What's wrong with:
>
> with open('dnain.dat') as infile, open('dnaout.dat','w') as outfile:
> for i, line in enumerate(infile):
> parts = line.split()
> if len(parts) > 1 and parts[1] != '0':
> outfile.write(">seq%s\n%s\n" % (i+1, parts[0]))
>
> (untested)
>
> --
> Arnaud
Nothing really,
After posting I was thinking I should have posted a more
straightforward version like the one you wrote. Now there is! It
probably is more efficient too. I just have a tendency to think in
terms of pipes: "pipe this junk in here, then in here, get output".
Probably damage from too much Unix scripting.Since I can't resist the
urge to post crazy code here goes the bonus round (don't do this at
work):
open('dnaout.dat','w').writelines(
'seq%s\n%s\n'%(i+1,part[0])
for i,part in enumerate(line.split() for line in open('dnain.dat'))
if len(part)>1 and part[1]!='0')
--
http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
Steven D'Aprano wrote: 4. Python 3 will make you irresistible to women. FALSE What?!? Drat!!! Guess I'll have to learn Lisp... ;) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: mix statically typed with dynamically typed
Am 28.01.10 22:12, schrieb Yingjie Lan: We all know that Python is dynamically typed, and dynamically typed languages are generally slower than statically typed ones. I wonder if it is possible at all for Python to mix statically-typed-ness with dynamically-typed-ness to boost up its speed a little bit, especially when speed is needed. For example, you define a function like this: def speed(float dist, float time): return dist/time then the compiler would generate code to first check parameter types (or even do some casts if appropriate, say cast an int into float) in the beginning of this function. and the rest of the function would then be compiled with the assumption that 'dist' and 'time' are of the type float. Of course, dynamically-typed-ness is still the same as before. Python is well known for providing multiple programming paradigms, I wonder if we could also sneak this in nicely. There are various attempts to achieve this. The most generic one, which is most promising in the long run is PyPy, the implementation of Python in itself, with the added benefit of making code-generators that emit e.g. C based on Python-code. Then there is Cython, which blends Python with C & integrates very nicely. Last but not least, for you actual example, psyco is the easiest thing to use, it's a JIT aimed to especially optimize numeric operations as the one you present. Diez -- http://mail.python.org/mailman/listinfo/python-list
