Re: gdb unable to read python frame information
Wesley writes: > ... > [root@localhost ~]# gdb python > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) > This GDB was configured as "x86_64-redhat-linux-gnu". > Reading symbols from /usr/bin/python...Reading symbols from > /usr/lib/debug/usr/bin/python2.6.debug...done. > done. > (gdb) run > Starting program: /usr/bin/python > warning: the debug information found in > "/usr/lib/debug//usr/lib64/libpython2.6.so.1.0.debug" does not match > "/usr/lib64/libpython2.6.so.1.0" (CRC mismatch). > > warning: the debug information found in > "/usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug" does not match > "/usr/lib64/libpython2.6.so.1.0" (CRC mismatch). This indicates that there is a problem between the executed code and the debug information. Apparently, they do not match. An installation problem might be the cause - maybe, a packaging problem. Have you not told us that you have build your own Python from source? Usually, such a Python would not reside under "/usr/bin" but more likely under "/usr/local/bin" (of course, doing special things, you can force a build from source to install unter "/usr/bin", but this usually is not advicable -- it is potentially interfering with system installed components). If you have generated your own Python, you must ensure that it is consistently used (for all the cases you are concerned by). -- https://mail.python.org/mailman/listinfo/python-list
Re: gdb unable to read python frame information
Wesley writes: > Now, I fixed the problem... > > Instead of python2.6.6, for python 2.7 it's OK.. > > Why? gdb does not support python 2.6.6? gdb supports python 2.6.6 as well (it is a C level debugger with very few dependencies on Python). Your reports seem to suggest that your Python 2.6.6 installation is somehow screwed up - for whatever reason. > Is it related to python-gdb.py? Very unlikely. -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On 10/03/2014 21:57, Terry Reedy wrote: I'd like to be able to serve the rest of the web api using a pyramid wsgi app if possible, and I'd like to be able to write the things that process requests in and validation out in a synchronous fashion, most likely spinning off a thread for each one. If you are writing 'standard' blocking, synchronous code, I am not sure why you would use any of the above. The idea I have is to do all the networking async based on a declarative set of messages in and recording all messages out and then hand that set of messages off to a syncronous layer to make assertions, record into a database, etc. The protocols are all financial (do we really not have a pure-python FIX library?!) but none are likely to have existing python implementations. How should I pick between the options? What would people recommend and why? I know nothing of tornado. I personally would use asyncio over twisted if I could because it is simpler, in the stdlib, has the option to write 'untwisted' non-blocking code similar to blocking code, and the docs easier for me to read. Thanks. Guess I was expecting more of a response. I suspect I'll just end up cross-posting to the various mailing lists, which I hope won't cause too much offence or kick off any flame wars. I'm faced with a difficult choice that I suspect many in our community are, just trying to find out how to make the best decision :-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Testing interactive code using raw_input
On Mon, 10 Mar 2014 17:57:19 +0100, Peter Otten wrote: > Steven D'Aprano wrote: >> what are my options for *automatically* supplying input to raw_input? > > https://pypi.python.org/pypi/mock > > In Python 3 this is part of the standard library: Nice! Thanks to everyone who responded. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Balanced trees
On Mon, 10 Mar 2014 19:24:07 -0400, Roy Smith wrote: > In article <[email protected]>, > Marko Rauhamaa wrote: > >> Anyway, this whole debate is rather unnecessary since every developer >> is supposed to have both weapons in their arsenal. > > The problem with having a choice is that it opens up the possibility of > making the wrong one :-) > > As this discussion has shown, figuring out whether a hash table or a > tree is better for a given problem is non-trivial. My guess is that if > you gave 1000 typical developers both data structures and let them pick > freely, the number of cases where it really mattered and the developer > picked the right one would be approximately equal to the number of cases > where they picked the wrong one. Perhaps you are not familiar with the 50/50/90 rule? Given any 50/50 choice you are 90% certain to pick the wrong one :-) -- I hold it, that a little rebellion, now and then, is a good thing... -- Thomas Jefferson -- https://mail.python.org/mailman/listinfo/python-list
Re: Balanced trees
Steven D'Aprano : > On Mon, 10 Mar 2014 19:24:07 -0400, Roy Smith wrote: > >> In article <[email protected]>, >> Marko Rauhamaa wrote: >> >>> Anyway, this whole debate is rather unnecessary since every developer >>> is supposed to have both weapons in their arsenal. >> >> The problem with having a choice is that it opens up the possibility of >> making the wrong one :-) > > [...] > > In my experience, the average developer has an amazing talent for > pessimising code when they think they are optimising it. Java is the straitjacket that prevents the "average developer" from shooting himself in the foot. Python should let skilled professionals do their work. Thankfully, for the most part, it does. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Chris Withers wrote: > Hi All, > > I see python now has a plethora of async frameworks and I need to try > and pick one to use from: > > - asyncio/tulip > - tornado > - twisted Looking at Tornado's examples on the web I find this: tornado.ioloop.IOLoop.instance().start() This single line of code says more than thousand words. But it boils down to: (1) This was written by some Java guys. (2) Someone used Python to write Java. And that's all I need to know about Tornado. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing wrote: > As far as observable effects are concerned, it's > quite clear: mutable objects can *always* be updated > in-place, and immutable objects can *never* be. Hm. Consider the circle-ellipse problem. Briefly, a circle is-an ellipse, so in an inheritance hierarchy it is natural to make Circle a subclass of Ellipse. Now suppose the Ellipse has a stretch method that mutates the ellipse by changing the length of one of its axes while preserving the other. To avoid violating LSP, the Circle class must support all the methods of its ancestor. However it cannot, because the stretch method would invalidate the invariant of the Circle class that both of its axes must always be equal. There are a number of possible solutions. One possibility would be to copy the Circle as an Ellipse and return the new object instead of mutating it. Then you have the situation where, given a mutable object x that satisfies isinstance(x, Ellipse), the stretch method *may* be able to update the object in-place, or it *may* not. I can't think of a reasonable example that would replace the stretch method here with an augmented assignment, but then it is rather late. > It might be the obvious way for that particular operation on > that particular type. But what about all the others? > What's the obvious way to spell in-place set intersection, > for example? (Quickly -- no peeking at the docs!) You mean set.intersection_update? The in-place set methods are not hard to remember, because they all end in _update. -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Chris Withers wrote: > Hi All, > > I see python now has a plethora of async frameworks and I need to try > and pick one to use from: > > - asyncio/tulip > - tornado > - twisted I'd go for using iocp, epoll and kqueue/kevent directly. Why bother to learn a framework? You will find epoll and kqueue/kevent in the select module and iocp in pywin32. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Sturla Molden : > Looking at Tornado's examples on the web I find this: > > [...] > > (1) This was written by some Java guys. I have written several Python async "frameworks" starting from select.epoll(). It's only a handful of lines of code (plus an AVL tree implementation for timers). Then, I've had to implement the protocols myself because the standard library implementations aren't amenable to async processing. Now, I've taken a brief look at the new asyncio and it looks as if it has everything one would hope for (and then some). You'd still need to supply the protocol implementations yourself. Since the async framework is such a small piece of the puzzle and since the edge-triggered mode of select.epoll() is a nicer programming model than asyncio provides, I might stick with epoll. (Yes, it is specific to linux.) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Sturla Molden : > I'd go for using iocp, epoll and kqueue/kevent directly. Why bother to > learn a framework? You will find epoll and kqueue/kevent in the select > module and iocp in pywin32. You beat me to it. However, I'm hoping asyncio will steer the Python faithful away from blocking threads to the "right way" of doing networking. The Java people came to their senses with the advent of NIO. I think one of the main remaining sticking points is database access. I barely do any database stuff, but last I checked it's all done with synchronous APIs. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Marko Rauhamaa wrote: > Now, I've taken a brief look at the new asyncio and it looks as if it > has everything one would hope for (and then some). You'd still need to > supply the protocol implementations yourself. Tulip (the new async module) is nice. But I am a bit confused as to how it combines the IOCP model on Windows with the "readyness" signalling (epoll, kqueue) on Linux, *BSD and Apple. Because these paradigms are so inherently different, I don't see how both can be used effectively with the same client code. But Guido/BDFL is a smart guy and probably knows this better than me :) Another thing is that there is no IOCP support on Solaris, AIX and z/OS using Tulip, only Windows. But Windows is not the only OS with IOCP. I'd prefer that over /dev/poll any day (does Tulip use /dev/poll by the way?) Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On Tue, Mar 11, 2014 at 4:58 AM, Marko Rauhamaa wrote: > Sturla Molden : > >> I'd go for using iocp, epoll and kqueue/kevent directly. Why bother to >> learn a framework? You will find epoll and kqueue/kevent in the select >> module and iocp in pywin32. > > You beat me to it. > > However, I'm hoping asyncio will steer the Python faithful away from > blocking threads to the "right way" of doing networking. eventlet has 115k downloads from PyPI over the last month. gevent has 143k. Twisted has 147k. Tornado has 173k. I'd say that a lot of Python users are already doing non-blocking network I/O, in one form or another. -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Ian Kelly : > eventlet has 115k downloads from PyPI over the last month. gevent has > 143k. Twisted has 147k. Tornado has 173k. > > I'd say that a lot of Python users are already doing non-blocking > network I/O, in one form or another. There aren't so many network developers in the world. That must be some web crawlers getting more than they bargained for. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On 11 March 2014 11:54, Marko Rauhamaa wrote: > Ian Kelly : > >> eventlet has 115k downloads from PyPI over the last month. gevent has >> 143k. Twisted has 147k. Tornado has 173k. >> >> I'd say that a lot of Python users are already doing non-blocking >> network I/O, in one form or another. > > There aren't so many network developers in the world. That must be some > web crawlers getting more than they bargained for. I have no idea how many network developers there are in the world but: 1) Many people may be installing this from pypi as a dependency of some other application that they use. So you should think that it counts something closer to "users" rather than developers. 2) There are problems with the download counts on PyPI but the numbers above are sufficiently high that they should indicate a wide level of usage of the libraries. Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Closure/method definition question for Python 2.7
On 2014-03-10, Marko Rauhamaa wrote: > "Brunick, Gerard:(Constellation)" : > >> class Test(object): >> x = 10 >> >> def __init__(self): >> self.y = x >> >> t = Test() >> --- >> >> raises >> >> NameError: global name 'x' is not defined. > > In the snippet, x is neither local to __init__() nor global to > the module. It is in the class scope. You can refer to it in > one of two ways: > >Test.x > > or: > >self.x The latter will work only to read the class variable. If you assign to self.x you'll create a new instance variable that hides the class variable. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: golang OO removal, benefits. over python?
On 2014-03-10, flebber wrote: > I was wondering if a better programmer than I could explain if > the removal of OO features in golang really does offer an great > benefit over python. > > An article I was reading ran through a brief overview of golang > in respect of OO features > http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/ > . > > maybe removing OO features would be a benefit to c++ users or > Java users but python? > > As I have seen an interesting reddit or two of people trying to > figure out go today it was a ruby user, totally lost with > structs. > > So anecdotally is actually python and ruby users changing to > Go, here is a blog and reddit from Rob Pike. > http://www.reddit.com/comments/1mue70 > > Why would a Python user change to go except for new and > interesting? Static typing combined with duck typing and simple distribution of applications is a draw. Go's tools are pretty awesome, and are scheduled for improvements. If you can get by with its built in types (or simple aggregates of them) it feels quite expressive. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Chris Withers simplistix.co.uk> writes: > > The protocols are all financial (do we really not have a pure-python FIX > library?!) but none are likely to have existing python implementations. If you are mostly writing protocol implementations (aka parsers and serializers), then you should consider writing them in a way that's framework-agnostic. See as an example: https://pypi.python.org/pypi/obelus/0.1 (if you really want to settle on a single framework and don't mind supporting old Python versions, then I recommend asyncio) Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Sturla Molden gmail.com> writes: > > Chris Withers simplistix.co.uk> wrote: > > Hi All, > > > > I see python now has a plethora of async frameworks and I need to try > > and pick one to use from: > > > > - asyncio/tulip > > - tornado > > - twisted > > I'd go for using iocp, epoll and kqueue/kevent directly. Why bother to > learn a framework? You will find epoll and kqueue/kevent in the select > module and iocp in pywin32. Yes, why use a library when you can rewrite it all yourself? Actually, you should probably issue system calls to the kernel directly, the libc is overrated (as is portability, I suppose). Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Oddity using sorted with key
I am running into a strange behavior using the sorted function in Python 2.7.
The key parameter is not behaving as the docs say it does:
Here is a snippet of code, simplified from my full program:
#begin code
class Thing(object):
def __init__(self, name):
self.name = name
def __repr__(self):
return "Thing %s" % self.name
stuff = [Thing('a'), Thing('C'), Thing('b'), Thing('2')]
more_stuff = [Thing('d'), Thing('f')]
all_the_stuff = stuff + more_stuff
print list(sorted(all_the_stuff, key=lambda x: x.name.lower))
print list(sorted(all_the_stuff, key=lambda x: x.name.lower()))
# END
The output is:
[Thing d, Thing f, Thing 2, Thing a, Thing b, Thing C]
[Thing 2, Thing a, Thing b, Thing C, Thing d, Thing f]
The second call to sorted works as expected. Just using the method doesn't sort
properly.
Any ideas why I'm seeing two different results? Especially as the correct form
is giving me the wrong results?
Josh English
--
https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On Tue, Mar 11, 2014 at 11:17 AM, Sturla Molden wrote: > Chris Withers wrote: > > Hi All, > > > > I see python now has a plethora of async frameworks and I need to try > > and pick one to use from: > > > > - asyncio/tulip > > - tornado > > - twisted > > Looking at Tornado's examples on the web I find this: > > tornado.ioloop.IOLoop.instance().start() > > This single line of code says more than thousand words. But it boils down > to: > > (1) This was written by some Java guys. > (2) Someone used Python to write Java. > > And that's all I need to know about Tornado. Tornado is actually very Pythonic and has a very well written and modern code base. I think "tornado.ioloop.IOLoop.instance().start()" is the way it is in order to let you use multiple IO loops in different threads but I can't think of other places where such an idiom is used. What one might find a little Java-esque at a first glance is Twisted, because of zope.interface and the camelCase notation, but definitively not Tornado. -- Giampaolo - http://grodola.blogspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Oddity using sorted with key
On Tue, Mar 11, 2014 at 9:13 AM, Josh English wrote: > print list(sorted(all_the_stuff, key=lambda x: x.name.lower)) > In this case, the key being sorted on is the function object x.name.lower, not the result of the call. It might make more sense if you break the lambda out into a separate def statement, like this: def myKeyFunc(x): return x.name.lower # Return the function that produces the lower-cased name. print list(sorted(all_the_stuff, key=myKeyFunc)) > print list(sorted(all_the_stuff, key=lambda x: x.name.lower())) > In this case, you are calling x.name.lower, and the key being used is the result of that call. And heres what this one looks like broken down: def myKeyFunc(x): return x.name.lower() # Return the lower-cased name. print list(sorted(all_the_stuff, key=myKeyFunc)) Chris -- https://mail.python.org/mailman/listinfo/python-list
Re: Oddity using sorted with key
On 03/11/2014 09:13 AM, Josh English wrote:
I am running into a strange behavior using the sorted function in Python 2.7.
The key parameter is not behaving as the docs say it does:
Here is a snippet of code, simplified from my full program:
#begin code
class Thing(object):
def __init__(self, name):
self.name = name
def __repr__(self):
return "Thing %s" % self.name
stuff = [Thing('a'), Thing('C'), Thing('b'), Thing('2')]
more_stuff = [Thing('d'), Thing('f')]
all_the_stuff = stuff + more_stuff
print list(sorted(all_the_stuff, key=lambda x: x.name.lower))
in this case everything sorts by the same value of the bound method of
name.lower. You could have used "".lower, which has the same value as
x.name.lower, and gotten the same results.
print list(sorted(all_the_stuff, key=lambda x: x.name.lower()))
in this case you're sorting by the lower case value of x.name, which is
what you want.
Emile
# END
The output is:
[Thing d, Thing f, Thing 2, Thing a, Thing b, Thing C]
[Thing 2, Thing a, Thing b, Thing C, Thing d, Thing f]
The second call to sorted works as expected. Just using the method doesn't sort
properly.
Any ideas why I'm seeing two different results? Especially as the correct form
is giving me the wrong results?
Josh English
--
https://mail.python.org/mailman/listinfo/python-list
Re: Oddity using sorted with key
In <[email protected]> Josh English writes: > print list(sorted(all_the_stuff, key=lambda x: x.name.lower)) > print list(sorted(all_the_stuff, key=lambda x: x.name.lower())) > # END > The output is: > [Thing d, Thing f, Thing 2, Thing a, Thing b, Thing C] > [Thing 2, Thing a, Thing b, Thing C, Thing d, Thing f] > Any ideas why I'm seeing two different results? Especially as the correct > form is giving me the wrong results? Why do you say that 'key=lambda x: x.name.lower' is the correct form? That returns the str.lower() function object, which is a silly thing to sort on. Surely you want to sort on the *result* of that function, which is what your second print does. -- John Gordon Imagine what it must be like for a real medical doctor to [email protected] 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Re: Oddity using sorted with key
Josh English wrote: > I am running into a strange behavior using the sorted function in Python > print list(sorted(all_the_stuff, key=lambda x: x.name.lower)) > print list(sorted(all_the_stuff, key=lambda x: x.name.lower())) Let's simplify your example some more: >>> items = ["B", "2", "a"] >>> sorted(items, key=lambda x: x.lower()) ['2', 'a', 'B'] That certainly works. Let's have a look at the keys used for the sorting: >>> for item in items: ... print item, "-->", (lambda x: x.lower())(item) ... B --> b 2 --> 2 a --> a Now on to your first example. What are the keys in this case? >>> for item in items: ... print item, "-->", (lambda x: x.lower)(item) ... B --> 2 --> a --> Just a bunch of bound methods. These compare by id(), basically the memory address of the bound method object, not something that makes a lot of sense as a sort key. > 2.7. The key parameter is not behaving as the docs say it does: You may be misled by the mention of key=str.lower str.lower is an unbound method, and if you pass it to sorted() together with a list of strings, it results in a call str.lower(item) # item is a string which is equivalent to item.lower() # item is a string So while it doesn't work for a list of Thing instances, if you have bare strings you can do >>> sorted(items, key=str.lower) ['2', 'a', 'B'] -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Tue, 11 Mar 2014 04:39:39 -0600, Ian Kelly wrote:
> On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing
> wrote:
>> As far as observable effects are concerned, it's quite clear: mutable
>> objects can *always* be updated in-place, and immutable objects can
>> *never* be.
>
> Hm. Consider the circle-ellipse problem.
Oh, not that old chestnut! The circle-ellipse problem demonstrates one
limitation of OOP (specifically "subtype polymorphism"), as well as a
general difficulty with hierarchical taxonomies. Mammals have hair --
what do you make of hairless[1] dolphins? Circle/Ellipse is not a good
place to start from in order to critic augmented assignment in Python.
You're starting from a place where inheritance itself is problematic, so
naturally you're going to find problems.
> Briefly, a circle is-an ellipse, so in an inheritance hierarchy it is
> natural to make Circle a subclass of Ellipse.
Natural and wrong. It's only natural if you don't think through the
consequences. As you go on to say:
> Now suppose the Ellipse has a stretch method that
> mutates the ellipse by changing the length of one of its axes while
> preserving the other. To avoid violating LSP, the Circle class must
> support all the methods of its ancestor. However it cannot, because the
> stretch method would invalidate the invariant of the Circle class that
> both of its axes must always be equal.
Right. So *Circles cannot be Ellipses*, not without violating the Liskov
Substitution Principle. If I think that they are, I haven't thought it
through. Nor can Ellipses be Circles. That's the problem of the Circle/
Ellipse relationship.
(Aside: the LSP is not a Law Of Physics that cannot be touched. There are
other OOP models that don't require LSP.)
Even in the case of immutable shapes, one might not wish to inherit
Circle from Ellipsis. Ellipses have five degrees of freedom:
2 x position
size (scale)
orientation
shape
while circles only have three:
2 x position
size
Orientation and shape are meaningless for circles! So they should not
inherit from a class where they are meaningful: given the LSP, a subclass
cannot be more restrictive than a superclass.
> There are a number of possible solutions. One possibility would be to
> copy the Circle as an Ellipse and return the new object instead of
> mutating it. Then you have the situation where, given a mutable object
> x that satisfies isinstance(x, Ellipse), the stretch method *may* be
> able to update the object in-place, or it *may* not.
That is a really lousy design. Of course we are free to create classes
with ugly, inconsistent, stupid or unworkable APIs if we like. Python
won't stop us:
class MyList(list):
def append(self, obj):
if len(self) % 17 == 3:
return self + [obj]
super(MyList, self).append(obj)
> I can't think of a reasonable example that would replace the stretch
> method here with an augmented assignment, but then it is rather late.
>
>> It might be the obvious way for that particular operation on that
>> particular type.
Um, yes? Nobody suggests that a method of type X has to be the most
obvious way for *any operation* on *any type*. What's your point?
> But what about all the others? What's the obvious way
>> to spell in-place set intersection, for example?
I would expect it to be &=, let's find out if I'm right:
py> a = set("abcde")
py> b = a # save a reference to it
py> c = set("cdefg")
py> a &= c
py> a, b
({'c', 'd', 'e'}, {'c', 'd', 'e'})
py> a is b
True
>> (Quickly -- no peeking at the docs!)
The only reason I'd need to look at the docs is because I always forget
whether & is intersection and | is union, or the other way around. But
having remembered which is which, going from & to &= was easy.
> You mean set.intersection_update? The in-place set methods are not hard
> to remember, because they all end in _update.
And hard to spell.
[1] Technically they aren't *entirely* hairless. They may have a few
hairs around the blowhole, and baby dolphins are born with whiskers which
they soon lose. But from a functional perspective, they are hairless.
--
Steven D'Aprano
--
https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On 2014-03-11, Antoine Pitrou wrote: > Sturla Molden gmail.com> writes: >> >> Chris Withers simplistix.co.uk> wrote: >> > Hi All, >> > >> > I see python now has a plethora of async frameworks and I need to try >> > and pick one to use from: >> > >> > - asyncio/tulip >> > - tornado >> > - twisted >> >> I'd go for using iocp, epoll and kqueue/kevent directly. Why bother to >> learn a framework? You will find epoll and kqueue/kevent in the select >> module and iocp in pywin32. > > Yes, why use a library when you can rewrite it all yourself? > Actually, you should probably issue system calls to the kernel directly, > the libc is overrated (as is portability, I suppose). And don't bother with device drivers for the network adapters either. Just map their PCI regions in to user-space and twiddle the reigisters directly! ;) [I do that when testing PCI boards with C code, and one of these days I'm going to figure out how to do it with Python.] -- Grant Edwards grant.b.edwardsYow! It's a hole all the at way to downtown Burbank! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Oddity using sorted with key
A comprehensive and educational answer, Peter. Thank you. Josh -- https://mail.python.org/mailman/listinfo/python-list
Re: Oddity using sorted with key
On Tuesday, March 11, 2014 9:25:29 AM UTC-7, John Gordon wrote: > > > > > Why do you say that 'key=lambda x: x.name.lower' is the correct form? That > > returns the str.lower() function object, which is a silly thing to sort > > on. Surely you want to sort on the *result* of that function, which is > > what your second print does. > >From http://docs.python.org/2/library/functions.html: key specifies a function of one argument that is used to extract a comparison key from each list element: key=str.lower. The default value is None (compare the elements directly). And from https://wiki.python.org/moin/HowTo/Sorting/: The value of the key parameter should be a function that takes a single argument and returns a key to use for sorting purposes. This technique is fast because the key function is called exactly once for each input record. ... Of course, now that I re-read that, I was mistaking the lambda function with the definition of the lambda function. Stupid me. -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Hi Grant On Tuesday, 11 March 2014 16:52:18 UTC, Grant Edwards wrote: [...] > > And don't bother with device drivers for the network adapters either. > Just map their PCI regions in to user-space and twiddle the reigisters > directly! ;) > > [I do that when testing PCI boards with C code, and one of these days > I'm going to figure out how to do it with Python.] Heh - just about the first 'real' thing I did in Python, back around 2001 or so, was to write a 'Device Driver' library to allow direct access to memory-mapped I/O via Python. It compiled under both Windows and Linux and I proved it using an ISA I/O board with loads of 8255s and LEDs hanging off it. As well as a learning exercise it was sort-of intended as a first step toward robotic control using Python. I hopen to rework it for similar PCI-based I/O boards (to do the sort of thing you mention), but never got a round tuit... Cheers jon N -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On Wed, Mar 12, 2014 at 3:01 AM, Antoine Pitrou wrote: > Yes, why use a library when you can rewrite it all yourself? > Actually, you should probably issue system calls to the kernel directly, > the libc is overrated (as is portability, I suppose). It's a trade-off, of course. I am fluent in over six million forms of TCP socket communication (give or take), so I'll often skip the libraries and just directly connect a socket. But on the flip side, some protocols are just way more convenient to let a library handle. An HTTP POST request, for instance, requires - potentially - a whole lot of escaping and merging and stuff, or a simple call to one function with a dictionary of form data. But I like to retain close familiarity with the actual protocols, in case I'm trying to transfer a file onto a target system that provides something buggy or incomplete... most notably, the innumerable platforms whose FTP clients don't support passive mode. (RFC 959 specified it in 1985, why doesn't the default WinXP client support it??) I've written a good few FTP clients for that reason. There's a huge difference between something meant to do a huge amount of work long-term and something to just quickly move some data across a VM boundary. For the latter, I'll do whatever's quickest *right now*, and that may well mean "don't bother figuring out the XYZ module, just do it over a plain socket". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: querry on queue ( thread safe ) multithreading
In article , Jaiprakash Singh wrote: > hey i am working on scraping a site , so i am using multi-threading concept. > i wrote a code based on queue (thread safe) but still my code block out after > sometime, please help , i have searched a lot but unable to resolve it. > please help i stuck here. Do you really want to subject the web server to 150 simultaneous requests? Some would consider that a denial-of-service attack. When I scrape a site, and I have been doing that occasionally of late, I put a 10-second sleep after each HTTP request. That makes my program more considerate of other people's resources and a better web citizen. It is also much easier to program. -- Jim Gibson -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Antoine Pitrou wrote: > Yes, why use a library when you can rewrite it all yourself? This assumes something equivalent to the library will have to be written. But if it can be replaced with something very minimalistic it is just bloat. I would also like to respond that the select module and pywin32 are libraries. So what we are talking about here is not using a library versus issuing low-level system calls, but using a cross-platform library instead of having separate modules with system calls for Linux, *BSD/Apple and Windows. Another thing is that co-routines and "yield from" statements just makes it hard to follow the logic of the program. I still have to convince myself that a library for transforming epoll function calls into co-routines is actually useful. If it just turns otherwise readable code into something most Python programmers cannot read it is better left out of the project. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Sturla Molden gmail.com> writes: > > Antoine Pitrou pitrou.net> wrote: > > > Yes, why use a library when you can rewrite it all yourself? > > This assumes something equivalent to the library will have to be written. > But if it can be replaced with something very minimalistic it is just > bloat. I would also like to respond that the select module and pywin32 are > libraries. Lower-level ones, though. Just like C malloc() is lower-level than Python's memory management. This is the usual assumption that high-level libraries are made of useless cruft piled up by careless programmers. But there are actual reasons why these frameworks have a significant amount of code, and people who decide to ignore those reasons are simply bound to reimplement non-trivial parts of those frameworks in less careful and less tested ways (and they have to maintain it themselves afterwards). What irks me with your response is that you phrased it as though writing a good event loop was an almost trivial thing to do, which it is not once you start considering multiple use cases and constraints. It is quite irresponsible to suggest people don't need the power of network programming frameworks. I would personally distrust a programmer who chooses to reimplement their own event loop, except if they happen to have a very brilliant track record. > Another thing is that co-routines and "yield from" statements just > makes it hard to follow the logic of the program. That's an optional part of Tornado and asyncio, though. It is very reasonable to use Tornado or asyncio and still code in purely callback-driven style (even though Guido himself prefers the coroutine style). Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On Wed, Mar 12, 2014 at 5:43 AM, Antoine Pitrou wrote: > This is the usual assumption that high-level libraries are made of useless > cruft piled up by careless programmers. But there are actual reasons > why these frameworks have a significant amount of code, and people who > decide to ignore those reasons are simply bound to reimplement > non-trivial parts of those frameworks in less careful and less tested > ways (and they have to maintain it themselves afterwards). Once again, that's a judgment call. Those frameworks are usually written to be generic and to support lots of different systems, and if all you need is one of them, it's not so obvious that you 'ought to' use the framework. You do not need Joomla when all you want is a whole lot of static HTML files by one person - look for a simpler framework that doesn't put heaps of emphasis on user management, or no framework at all (just some nice templating system). But yes. If you're reimplementing something, you have to have a VERY good reason. I'm much more likely to write a program that edits bindfiles than to write a DNS server (although I have done both - Pike makes it easy to do the latter, and I had one situation where I was using DNS in such a way that I actually needed to generate responses on-the-fly based on rules, rather than pre-write everything), because BIND9 already handles pretty much everything, and its definition files are simple and easy to manipulate. (That said, though, I have *frequently* gone for some kind of meta-file with a script that creates the actual bindfiles. Helps with keeping things consistent, making sure I do the version updates, and so on. But that's not rewriting BIND.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On 3/11/2014 3:53 AM, Chris Withers wrote: On 10/03/2014 21:57, Terry Reedy wrote: I'd like to be able to serve the rest of the web api using a pyramid wsgi app if possible, and I'd like to be able to write the things that process requests in and validation out in a synchronous fashion, most likely spinning off a thread for each one. If you are writing 'standard' blocking, synchronous code, I am not sure why you would use any of the above. The idea I have is to do all the networking async based on a declarative set of messages in and recording all messages out and then hand that set of messages off to a syncronous layer to make assertions, record into a database, etc. In the absence of an event-loop oriented queue, putting jobs on a thread queue for a job-handler makes sense. The protocols are all financial (do we really not have a pure-python FIX library?!) but none are likely to have existing python implementations. How should I pick between the options? What would people recommend and why? I know nothing of tornado. I personally would use asyncio over twisted if I could because it is simpler, in the stdlib, has the option to write 'untwisted' non-blocking code similar to blocking code, and the docs easier for me to read. Guess I was expecting more of a response. Let me try again. I read the Twisted docs a couple of years ago. While I could deal with the interface, I understand why it is called 'twisted' and why Guido does not particularly like it. I read the asyncio doc before the most recent revisions and found it easier to understand. I personally like the co-routine layer. But I know that this is very much a personal preference. (Sturla just confirmed this by posting the opposite response to the coroutine interface.) So I suggest you spend an hour with the doc for each of the three candidates. I suspect I'll just end up cross-posting to the various mailing lists, Bad idea. Post separately if you must. > which I hope won't cause too much offence or kick off any flame wars. It would do both. I'm faced with a difficult choice that I suspect many in our community are, just trying to find out how to make the best decision :-) The asyncio event loop interface was designed with knowledge of other event loops, including but not limited to those of twisted and tornado. The implementation in asyncio is intended to be replaceable by other implementations that include the same interface. I do not know if there are adapters yet for the twisted and tornado loops, but I expect there will be, official or not. Part of Guido's intent is to reduce single-framework lockin. If you start with asyncio, and decide you want to use some Twisted protocols, you should be able to (at least in the future) without dumping your current code. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: golang OO removal, benefits. over python?
On Mon, Mar 10, 2014 at 2:38 AM, Marko Rauhamaa wrote: >> On the whole though I think that the language is not yet mature enough >> to be able to seriously compete with more established languages like >> Python or Java. > > Also, is there anything seriously lacking in Python, Java and C? > > I was very interested in Go when it came out, but was turned off by the > fact that you had so have a Google account to effectively participate in > the community. Concurrency is one area where Go beats Python hands down. The newish multiprocessing module helps with that, but it is still rather heavy compared to the light-weight processes used by Go's goroutines. -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Antoine Pitrou wrote: > This is the usual assumption that high-level libraries are made of useless > cruft piled up by careless programmers. It often is the case, particularly in network programming. But in this case the programmer is Guido, so it doesn't apply. :) > What irks me with your response is that you phrased it as though writing > a good event loop was an almost trivial thing to do, which it is not > once you start considering multiple use cases and constraints. Right. But in my programs an event loops does not have multiple usecases. I know all the details about my usecase. I am more concerned that multiple frameworks have their own event loops. Sturla -- https://mail.python.org/mailman/listinfo/python-list
unittest weirdness
So I finally got enough data and enough of an understanding to write some unit
tests for my code.
These aren't the first unit tests I've written, but the behavior I'm getting is
baffling.
I'm using 2.7.4 and I'm testing some routines which attempt to interpret data from a flat file and create a new flat
file for later programmatic consumption.
The weird behavior I'm getting:
- when a test fails, I get the E or F, but no summary at the end
(if the failure occurs in setUpClass before my tested routines
are actually called, I get the summary; if I run a test method
individually I get the summary)
- I have two classes, but only one is being exercised
- occasionally, one of my gvim windows is unceremoniously killed
(survived only by its swap file)
I'm running the tests under sudo as the routines expect to be run that way.
Anybody have any ideas?
--
~Ethan~
--snippet of code--
from VSS.path import Path
from unittest import TestCase, main as Run
import wfbrp
class Test_wfbrp_20140225(TestCase):
@classmethod
def setUpClass(cls):
cls.pp = wfbrp.PaymentProcessor(
'.../lockbox_file',
'.../aging_file',
[
Path('month_end_1'),
Path('month_end_2'),
Path('month_end_3'),
],
)
def test_xxx_1(self):
p = self.pp.lockbox_payments[0]
# affirm we have what we're expecting
self.assertEqual(
(p.payer, p.ck_num, p.credit),
('a customer', '010101', 1),
)
self.assertEqual(p.invoices.keys(), ['XXX'])
self.assertEqual(p.invoices.values()[0].amount, 1)
# now make sure we get back what we're expecting
np, b = self.pp._match_invoices(p)
missing = []
for inv_num in ('123456', '789012', '345678'):
if inv_num not in b:
missing.append(inv_num)
if missing:
raise ValueError('invoices %r missing from batch' % missing)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
Steven D'Aprano wrote: On Tue, 11 Mar 2014 04:39:39 -0600, Ian Kelly wrote: On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing > What's the obvious way to spell in-place set intersection, for example? I would expect it to be &=, That's my point -- once you know the binary operator for an operation, the corresponding in-place operator is obvious. But there's no established standard set of method names for in-place operations -- each type does its own thing. You mean set.intersection_update? The in-place set methods are not hard to remember, because they all end in _update. For that particular type, maybe, but I wouldn't trust that rule to extend to other types. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Sturla Molden wrote: Another thing is that co-routines and "yield from" statements just makes it hard to follow the logic of the program. I still have to convince myself that a library for transforming epoll function calls into co-routines is actually useful. It's not "epoll function calls" that the coroutine style is intended to replace, it's complex systems of chained callbacks. They're supposed to make that kind of logic *easier* to follow. If you haven't had that experience, it may be because you've only dealt with simple cases. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: unittest weirdness
In Ethan Furman
writes:
> if missing:
> raise ValueError('invoices %r missing from batch' % missing)
It's been a while since I wrote test cases, but I recall using the assert*
methods (assertEqual, assertTrue, etc.) instead of raising exceptions.
Perhaps that's the issue?
--
John Gordon Imagine what it must be like for a real medical doctor to
[email protected] 'House', or a real serial killer to watch 'Dexter'.
--
https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Gregory Ewing : > It's not "epoll function calls" that the coroutine style is intended > to replace, it's complex systems of chained callbacks. They're > supposed to make that kind of logic *easier* to follow. If you haven't > had that experience, it may be because you've only dealt with simple > cases. The coroutines are definitely something to get into, although I'm skeptical as well. Epoll and the associated idioms have been with us for a long time and are well understood. As for "easy to follow," unfortunately the complexities of network state machines cannot be abstracted out, and the result is never exactly easy to the eye. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Antoine Pitrou : > This is the usual assumption that high-level libraries are made of > useless cruft piled up by careless programmers. But there are actual > reasons why these frameworks have a significant amount of code, and > people who decide to ignore those reasons are simply bound to > reimplement non-trivial parts of those frameworks in less careful and > less tested ways (and they have to maintain it themselves afterwards). Maybe, maybe not. You can't assume it one way or another. > What irks me with your response is that you phrased it as though writing > a good event loop was an almost trivial thing to do, It's not rocket science. There are pitfalls, to be sure, but the resulting, solid event loop is not many lines of code. Have had to implement it numerous times. That said, asyncio seems to have the necessary facilities in place. Definitely worth a closer look. > I would personally distrust a programmer who chooses to reimplement > their own event loop, except if they happen to have a very brilliant > track record. As with all programming, you have to do it right. If you can't write your own event loop, you probably can't be trusted with any multithreaded code, which has much more baffling corner cases. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: unittest weirdness
On 03/11/2014 01:58 PM, Ethan Furman wrote: Anybody have any ideas? I suspect the O/S is killing the process. If I manually select the other class to run (which has all successful tests, so no traceback baggage), it runs normally. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On Wed, Mar 12, 2014 at 9:28 AM, Marko Rauhamaa wrote: > If you can't write your own event loop, you probably can't be trusted > with any multithreaded code, which has much more baffling corner cases. I'm not sure about that. Threads are generally easier to handle, because each one just does something on its own, sequentially. (The problem with threads is the resource usage - you need to allocate X amount of stack space and other execution state, when all you really need is the socket (or whatever) and some basic state about that.) Regardless of how you structure your code, you have to ensure that one handler doesn't tread on another's toes, and with multithreading, that's _all_ you have to worry about. A proper event loop, handling events from all sorts of different sources, is far more complicated. What corner cases are there with threads that you don't have with anything else? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: unittest weirdness
On 03/11/2014 03:13 PM, John Gordon wrote:
Ethan Furman writes:
if missing:
raise ValueError('invoices %r missing from batch' % missing)
It's been a while since I wrote test cases, but I recall using the assert*
methods (assertEqual, assertTrue, etc.) instead of raising exceptions.
Perhaps that's the issue?
Drat. Tried it, same issue. O/S kills it. :(
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Chris Angelico : > Yep. Now how is that not a problem when you use some other model, like > an event loop? The standard methods of avoiding deadlocks (like > acquiring locks in strict order) work exactly the same for all models, > and are just as necessary. I was simply saying that if you can work with multiple threads, an event loop shouldn't be a big deal. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
On Wed, Mar 12, 2014 at 10:18 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> What corner cases are there with threads that you don't have with >> anything else? > > There are numerous. Here's one example: deadlocks due to two threads > taking locks in a different order. The problem crops up naturally with > two intercommunicating classes. It can sometimes be very difficult to > spot or avoid. Yep. Now how is that not a problem when you use some other model, like an event loop? The standard methods of avoiding deadlocks (like acquiring locks in strict order) work exactly the same for all models, and are just as necessary. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Balanced trees
On 11/03/2014 8:12 PM, Marko Rauhamaa wrote: Python should let skilled professionals do their work. Thankfully, for the most part, it does. Skilled professionals don't solely rely on the standard library, either. If you know you need a balanced tree, you'll also know where to find an implementation of one. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to create an instance of a python class from C++
On 5 Mar 2014, at 00:14, Bill wrote:
> Hello:
>
> I can't figure out how to create an instance
> of a python class from 'C++':
>
Why not use pycxx from http://sourceforge.net/projects/cxx/?
This lib does all the heavy lifting for you for both python2 and python3.
Has docs and examples.
Barry
PyCXX maintainer.
> ( I am relatively new to Python so excuse some of
> the following. )
>
> In a .py file I create an ABC and then specialize it:
>
>from MyMod import *
>from abc import ABCMeta, abstractmethod
>
># Declare an abstract base class.
>class Base(metaclass=ABCMeta):
>"""Base class."""
>@abstractmethod
>def description(self):
>return "From the base class."
>
># Declare a class that inerits from the base.
>class Derived(Base):
>"""Derived class."""
>def description(self):
>return "From the Derived."
>
># Register the derived class.
>RegisterClass(Derived)
>
> Then from 'C++' (my implementation of RegisterClass)
> I try to create an instance
>
>static PyObject *
>RegisterClass( PyObject *, PyObject *args ) { // This gets called ok.
>
>PyObject *class_decl;
>if( ! PyArg_ParseTuple(args, "O", &class_decl) )
>return NULL;
>Py_INCREF(class_decl);
>
>PyTypeObject *typ = class_decl->ob_type;
>
>// Tried this.
>// PyObject *an = _PyObject_New(class_decl->ob_type); assert(an);
>// PyObject *desc = PyObject_CallMethod(an,"description",NULL);
> assert(desc);
>
>// Tried this.
>// PyObject *an = PyType_GenericNew((PyTypeObject
> *)class_decl->ob_type, NULL, NULL); assert(an);
>// assert(class_decl); assert(class_decl->ob_type);
> assert(class_decl->ob_type->tp_new);
>
>// This returns something.
>assert(class_decl); assert(class_decl->ob_type);
> assert(class_decl->ob_type->tp_new);
>PyObject *an_inst =
> class_decl->ob_type->tp_new(class_decl->ob_type,NULL, NULL); assert(an_inst);
>assert(class_decl->ob_type->tp_init);
>
>// This crashes.
>int ret = class_decl->ob_type->tp_init(an_inst,NULL, NULL); assert(ret
> == 0);
>// PyObject_CallMethod(an_inst,"__init__",NULL);
>// PyObject *an_inst = PyObject_CallMethod(class_decl,"__new__",NULL);
> assert(an_inst);
>
>// Never get here.
>PyObject *desc = PyObject_CallMethod(an_inst,"description",NULL);
> assert(desc);
>char *cp = _PyUnicode_AsString(desc);
>cerr << "Description:" << cp << endl;
>
>return PyLong_FromLong(0);
>}
>
>static PyMethodDef MyModMethods[] = {
>{ "RegisterClass", RegisterClass, METH_VARARGS, "Register class." },
>{ NULL, NULL, 0, NULL }
>};
>
>static struct PyModuleDef MyModMod = {
> PyModuleDef_HEAD_INIT,
> "MyMod",// name of module
> NULL,// module documentation, may be NULL
> -1,
> MyModMethods,
> NULL,
> NULL,
> NULL,
> NULL
>};
>
>PyMODINIT_FUNC
>PyInit_MyMod( void ) {
>PyObject* m = PyModule_Create(&MyModMod);
>if( m == NULL )
>return NULL;
>return m;
>}
>
>int
>main( int, char ** ) {
>
>PyImport_AppendInittab( "MyMod", PyInit_MyMod );
>
>Py_Initialize();
>
>const char *file_name = "z.py";
>FILE *fp = fopen(file_name,"r");
>if( fp ) {
>PyRun_SimpleFileExFlags(fp,file_name,1,0);
>}
>
>Py_Finalize();
>
>return 0;
>}
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: which async framework?
Chris Angelico : > What corner cases are there with threads that you don't have with > anything else? There are numerous. Here's one example: deadlocks due to two threads taking locks in a different order. The problem crops up naturally with two intercommunicating classes. It can sometimes be very difficult to spot or avoid. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Balanced trees
On Tue, 11 Mar 2014 04:28:25 -, Chris Angelico wrote: On Tue, Mar 11, 2014 at 2:38 PM, Ian Kelly wrote: On Mon, Mar 10, 2014 at 7:45 PM, Chris Angelico wrote: No no, I could make this so much better by using the 80x86 "REP MOVSW" command (or commands, depending on your point of view). That would be so much better than all those separate operations the silly compiler was doing! Roughly an hour of fiddling later, making sure it all still worked correctly, I discover that... hmm, it's not actually any faster. Better to have tried and failed though than to have simply accepted what the compiler was doing with no verification at all. Maybe. But I've learned now that one guy who used to do assembly language programming on an 8086 is unlikely to discover something that the many authors of a C compiler haven't noticed. Yes, it's possible there'll be something specific to my code, like if I'm doing a strcpy-like operation that isn't *actually* strcpy (the function will be optimized heavily, but a C-level loop might not be recognized), but it's more likely the compiler knows better than I do. That might be true for x86, but it isn't true for ARM for example. Apparently it's algorithmically hard to generate ARM code that makes efficient use of conditional instructions, and I can almost always write tighter, faster code than the compiler generates in consequence. It's not always worth the extra coding time (longer now that I'm not in practise), but that's a separate matter. -- Rhodri James *-* Wildebeest Herder to the Masses -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Wed, Mar 12, 2014 at 1:01 PM, Rick Johnson wrote: > On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote: >> x += y is meant to be equivalent, except possibly in-place and more >> efficient, than x = x + y. > > In an ideal world, the speed of these two codes should be the same, of course > i'm "assuming" that most competent language designers would optimise the > slower version. > Except that they don't mean the same thing, so it's not an optimization target. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: beautiful soup get class info
On 03/06/2014 02:22 PM, [email protected] wrote: I am using beautifulsoup to get the title and date of the website. title is working fine but I am not able to pull the date. Here is the code in the url: October 22, 2011 In Python, I am using the following code: date1 = soup.span.text data=soup.find_all(date="value") Results in: [] March 5, 2014 What is the proper way to get this info? Thanks. I believe it's the 'attrs' argument. http://www.crummy.com/software/BeautifulSoup/bs4/doc/ # Workaround the 'class' problem: data = soup.find_all(attrs={'class': 'date'}) I haven't tested it, but it's worth looking into. -- \¯\ /¯/\ \ \/¯¯\/ / / Christopher Welborn (cj) \__/\__/ / cjwelborn at live·com \__/\__/ http://welbornprod.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Tue, Mar 11, 2014 at 10:46 AM, Steven D'Aprano wrote: >> There are a number of possible solutions. One possibility would be to >> copy the Circle as an Ellipse and return the new object instead of >> mutating it. Then you have the situation where, given a mutable object >> x that satisfies isinstance(x, Ellipse), the stretch method *may* be >> able to update the object in-place, or it *may* not. > > That is a really lousy design. Of course we are free to create classes > with ugly, inconsistent, stupid or unworkable APIs if we like. Python > won't stop us: That's true but irrelevant to my point, which was to counter the assertion that mutable types can always be assumed to be able to perform operations in-place. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote: > x += y is meant to be equivalent, except possibly in-place and more > efficient, than x = x + y. In an ideal world, the speed of these two codes should be the same, of course i'm "assuming" that most competent language designers would optimise the slower version. """But Rick, Python is an interpreted language and does not benefit from a compile stage.""" Even if the bytecode can't be optimized on the current run, it CAN be optimized by updating the .pyo file for future runs without degrading current (or future) runtime performance. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On 3/11/2014 10:01 PM, Rick Johnson wrote: On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote: x += y is meant to be equivalent, except possibly in-place and more efficient, than x = x + y. The manual actually says "An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a similar, but not exactly equal effect. In the augmented version, x is only evaluated once. Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target, the old object is modified instead. In an ideal world, the speed of these two codes should be the same, Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once and possibly allocating a new object versus not take extra time. In a statement like "x.y.z[3*n+m] += 1", calculating the target dominates the time to increment, so this form should be nearly twice as fast. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: unittest weirdness
On 3/11/2014 6:13 PM, John Gordon wrote:
In Ethan Furman
writes:
if missing:
raise ValueError('invoices %r missing from batch' % missing)
It's been a while since I wrote test cases, but I recall using the assert*
methods (assertEqual, assertTrue, etc.) instead of raising exceptions.
Perhaps that's the issue?
Yes. I believe the methods all raise AssertionError on failure, and the
test methods are wrapped with try:.. except AssertionError as err:
if missing:
raise ValueError('invoices %r missing from batch' % missing)
should be "assertEqual(missing, [], 'invoices missing from batch')" and
if that fails, the non-empty list is printed along with the message.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tuples and immutability
On Tue, 11 Mar 2014 23:25:19 -0400, Terry Reedy wrote: > On 3/11/2014 10:01 PM, Rick Johnson wrote: >> >> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote: >>> x += y is meant to be equivalent, except possibly in-place and more >>> efficient, than x = x + y. > > The manual actually says "An augmented assignment expression like x += 1 > can be rewritten as x = x + 1 to achieve a similar, but not exactly > equal effect. In the augmented version, x is only evaluated once. Also, > when possible, the actual operation is performed in-place, meaning that > rather than creating a new object and assigning that to the target, the > old object is modified instead. > > >> In an ideal world, the speed of these two codes should be the same, > > Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once > and possibly allocating a new object versus not take extra time. In a > statement like "x.y.z[3*n+m] += 1", calculating the target dominates the > time to increment, so this form should be nearly twice as fast. Excellent point Terry! I always forget that the target of an augmented assignment may not be a simple name like "x" but can be an arbitrary complex reference, anything that is a legal assignment target. Because += is documented as only evaluating the expression once it can behave quite differently to the `spam = spam + 1` case. Evaluating the right hand side may have side- effects that change what the left hand side evaluates to. This is not the case with the augmented assignment. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
