Re: Hash stability
Heiko Wundram wrote: > Am 15.01.2012 13:22, schrieb Peter Otten: >> I'm curious: did you actually get false cache hits in a suds cache >> or just slower responses? > It broke the application using suds, not due to false cache hits, but > due to not getting a cache hit anymore at all. > so basically I worked around > the problem by creating an appropriate cache entry with the appropriate > name based on hash() using a local copy of xml.dtd I had around. This > took place on a development machine (32-bit), and when migrating the > application to a production machine (64-bit), the cache file wasn't used > anymore (due to the hash not being stable). Thanks for the explanation. > if the hash() output is changed. Additionally, if hash() isn't stable > between runs (the randomized hash() solution which is preferred, and > would also be my preference), suds caching becomes completely useless. > And for the results, see above. I've taken a quick look into the suds source; the good news is that you have to change a single method, reader.Reader.mangle(), to fix the problem with hash stability. However, I didn't see any code to deal with hash collisions at all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Hash stability
Am 16.01.2012 09:18, schrieb Peter Otten: > I've taken a quick look into the suds source; the good news is that you have > to change a single method, reader.Reader.mangle(), to fix the problem with > hash stability. > > However, I didn't see any code to deal with hash collisions at all. It smells like suds is vulnerable to cache poisoning. -- http://mail.python.org/mailman/listinfo/python-list
Re: Hash stability
Am 16.01.2012 09:44, schrieb Christian Heimes: Am 16.01.2012 09:18, schrieb Peter Otten: I've taken a quick look into the suds source; the good news is that you have to change a single method, reader.Reader.mangle(), to fix the problem with hash stability. However, I didn't see any code to deal with hash collisions at all. It smells like suds is vulnerable to cache poisoning. That it is, yes, at least partially. Generally, this is only relevant in case you are actually caching DTDs (which is the default) and in case you are querying untrusted SOAP-servers (in which case you'll most likely/should not use caching anyway), and in case the attacker has control over the URL namespace of a DTD-serving host (because the host-part of the DTD URL is used in the cache filename, unhashed, only the actual path is hashed to form the cache index). The easier way to poison the cache is most probably through actual traffic modification, as most DTD URLs are served through plain http and thus are suspect to MitM-modifications, anyway. -- --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: NaN, Null, and Sorting
On 13 jan, 20:04, Ethan Furman wrote:
> With NaN, it is possible to get a list that will not properly sort:
>
> --> NaN = float('nan')
> --> spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN]
> --> sorted(spam)
> [1, 2, nan, 3, nan, 4, 5, 7, nan]
>
> I'm constructing a Null object with the semantics that if the returned
> object is Null, it's actual value is unknown.
>
> From a purist point of view if it is unknown then comparison results
> are also unknown since the actual value might be greater, lesser, or the
> same as the value being compared against.
>
> From a practical point of view a list with Nulls scattered throughout
> is a pain in the backside.
>
> So I am strongly leaning towards implementing the comparisons such that
> Null objects are less than other objects so they will always sort together.
>
> Thoughts/advice/criticisms/etc?
>
> ~Ethan~
My suggestion would be thus: nans/nulls are unordered; sorting them is
fundamentally an ill defined notion. What you want, conceptually, is a
sorted list of the sortable entries, and a seperate list of the
unsorted entries. Translated into code, the most pure solution would
be to filter out the nanas/nulls in their own list first, and then
sort the rest. If the interface demands it, you can concatenate the
lists afterwards, but probably it is most convenient to keep them in
seperate lists.
Perhaps arbitrarily defining the ordering of nulls/nans is slightly
more efficient than the above, but it should not make a big
difference, and in terms of purity its no contest.
--
http://mail.python.org/mailman/listinfo/python-list
Re: NaN, Null, and Sorting
On Mon, Jan 16, 2012 at 9:22 PM, Eelco wrote: > What you want, conceptually, is a > sorted list of the sortable entries, and a seperate list of the > unsorted entries. Translated into code, the most pure solution would > be to filter out the nanas/nulls in their own list first, and then > sort the rest. If the interface demands it, you can concatenate the > lists afterwards, but probably it is most convenient to keep them in > seperate lists. So... you split it into two lists, sort the two lists (one of which can't be sorted), and then concatenate them. Sounds like the quicksort algorithm. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: NaN, Null, and Sorting
On 1/16/12 10:57 AM, Chris Angelico wrote: On Mon, Jan 16, 2012 at 9:22 PM, Eelco wrote: What you want, conceptually, is a sorted list of the sortable entries, and a seperate list of the unsorted entries. Translated into code, the most pure solution would be to filter out the nanas/nulls in their own list first, and then sort the rest. If the interface demands it, you can concatenate the lists afterwards, but probably it is most convenient to keep them in seperate lists. So... you split it into two lists, sort the two lists (one of which can't be sorted), and then concatenate them. Sounds like the quicksort algorithm. Not at all. The "split it into two lists" steps are entirely different in what Eelco suggested and quicksort. It's misleading to attempt to describe both using the same words. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Deleted System default Python on Leopard
Hello everyone, recently I've started to be try Python on my Mac OS X 10.5.8 Leopard and I've already messed up with it... I was compiling a Python souce code but didn't succeed and so I decided to install a newer version of Python. But before that, I did a stupid thing: I deleted manually all the folders of the Leopard's system default Python 2.5.1... Before when I was using the system Python, the program namebench worked perfectly. After that I messed everything up and installed MacPython 2.5 from the site python.org, now namebench always crashes. On the problem report system of Apple it gives me these errors: http://bpaste.net/show/21904/ While this is the Console: http://bpaste.net/show/21905/ What problem can it be? Can I clean up all the Pythons and restore the system one? Thanks everyone. Regards, Francesco Zhu -- http://mail.python.org/mailman/listinfo/python-list
python loggingL filter limitation, looks intentional?
Hi Vinay, It looks like this was intentional, so why was it decided that filters would only be passed messages logged to the logger they're attached to rather than the all messages that end up getting passed to logger? For example, an app and the libraries it uses log to 'some.db.driver', 'some.lib' and 'myapp'. The root logger has a number of handlers attached to it. I want to write a filter that adjusts, up or down, the level of certain messages logged based on a regex match of their message. If I understand correctly, I have to add my filter to all of the loggers above, rather than just the root logger where my handlers live? Or, alternatively, add the filter to all of the root handlers, thereby making the configuration of those handlers and/or more dependent on each other. Why is that? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: python loggingL filter limitation, looks intentional?
Hi Chris, Filtering is intended to be for cases where integer level-based filtering is insufficient; hence it applies to individual loggers and handlers, just as the integer levels do. You are right that you would need to add a filter to all of the loggers where you want it to apply, or to all of the handlers where you want it to apply. However, if you find your usage pattern occurring very commonly in your applications, it's easy enough to create a DelegatingHandler handler class which passes its events on to any number of handlers you like. You can then apply the filter you want to an instance of this handler, which you attach to your root logger. Regards, Vinay Sajip - Original Message - > From: Chris Withers > To: Vinay Sajip > Cc: Python List > Sent: Monday, 16 January 2012, 13:10 > Subject: python loggingL filter limitation, looks intentional? > > Hi Vinay, > > It looks like this was intentional, so why was it decided that filters would > only be passed messages logged to the logger they're attached to rather than > the all messages that end up getting passed to logger? > > For example, an app and the libraries it uses log to 'some.db.driver', > 'some.lib' and 'myapp'. > > The root logger has a number of handlers attached to it. > > I want to write a filter that adjusts, up or down, the level of certain > messages > logged based on a regex match of their message. > > If I understand correctly, I have to add my filter to all of the loggers > above, > rather than just the root logger where my handlers live? > > Or, alternatively, add the filter to all of the root handlers, thereby making > the configuration of those handlers and/or more dependent on each other. > > Why is that? > > cheers, > > Chris > > -- Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > -- http://mail.python.org/mailman/listinfo/python-list
Re: Deleted System default Python on Leopard
On Mon, Jan 16, 2012 at 7:41 AM, Francesco Zhu wrote: > Hello everyone, > > recently I've started to be try Python on my Mac OS X 10.5.8 Leopard and > I've already messed up with it... > > I was compiling a Python souce code but didn't succeed and so I decided to > install a newer version of Python. > But before that, I did a stupid thing: I deleted manually all the folders of > the Leopard's system default Python 2.5.1... > > Before when I was using the system Python, the program namebench worked > perfectly. > After that I messed everything up and installed MacPython 2.5 from the site > python.org, now namebench always crashes. > > On the problem report system of Apple it gives me these errors: > http://bpaste.net/show/21904/ > > While this is the Console: > http://bpaste.net/show/21905/ > > What problem can it be? > Can I clean up all the Pythons and restore the system one? > > Thanks everyone. > > Regards, > Francesco Zhu For compatibility reasons, a lot of programs specify the system Python: either /usr/bin/python for the executable or /System/Library/Frameworks/Python.Framework/Versions/2.5/python for the library. If they didn't and you (for example) installed 3.2 and set it as the default Python, everything would break. You could download the Apple's Python 2.5.1 from http://opensource.apple.com/source/python/python-30.1.3/, apply the patches, and attempt to put everything back the way you found it but it's probably easiest just to reinstall Leopard from the DVD. It shouldn't wipe anything but I would suggest backing up just in case. -- http://mail.python.org/mailman/listinfo/python-list
Decorated class question
Pardon me if this is a silly question. If I decorate a class, then subclass it, does my subclass feature whatever the decorator did to my superclass? Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorated class question
On Mon, Jan 16, 2012 at 10:10 AM, deathweaselx86 wrote: > If I decorate a class, then subclass it, does my subclass feature > whatever the decorator did to my superclass? Yes. The following two things are completely equivalent: @foo class Bar(...): ... # and class Bar(...) ... # immediately afterward Bar = foo(Bar) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorated class question
On Mon, Jan 16, 2012 at 8:10 AM, deathweaselx86 wrote: > Pardon me if this is a silly question. > > If I decorate a class, then subclass it, does my subclass feature > whatever the decorator did to my superclass? That depends on what the decorator did. Changes made directly to the class itself, such as items added to the class dict, will be inherited. Other operations performed, such as registering the class with a framework of some sort, are not inherited and would need the decorator to be applied to the subclass as well. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Elementwise 0.120116 -//- beta release -//- Lazily compute functions, method calls and operations on all elements of an iterable (or graph).
Elementwise provides helpful proxy objects which let you perform a
series of computations on every element of an iterable or graph, in a
lazy manner.
Docs: http://packages.python.org/elementwise/
GitHub: https://github.com/nathan-rice/Elementwise
Examples:
The standard ElementwiseProxy:
>>> nums = ElementwiseProxy([1, 2, 3, 4)
>>> print nums.bit_length()
1, 2, 2, 3
>>> nums + 1
2, 3, 4, 5
>>> print nums * 2
2, 4, 6, 8
>>> print nums == 2
False, True, False, False
>>> print ((nums + 1) * 2 + 3).apply(float)
7.0, 9.0, 11.0, 13.0
>>> print (nums.apply(float) + 0.0001).apply(round, 2)
1.0, 2.0, 3.0, 4.0
>>> print abs(nums - 3)
2, 1, 0, 1
>>> print (nums * 2 + 3) / 4
>>> print efoo2.undo(3)
1, 2, 3, 4
>>> print ((nums * 2 + 3) / 4).replicate([2, 2, 3, 3])
1, 1, 2, 2
>>> words = ElementwiseProxy(["one", "two", "three", "four"])
>>> print (words + " little indians").upper().split("
").apply(reversed).apply("_".join) * 2
'INDIANS_LITTLE_ONEINDIANS_LITTLE_ONE',
'INDIANS_LITTLE_TWOINDIANS_LITTLE_TWO',
'INDIANS_LITTLE_THREEINDIANS_LITTLE_THREE',
'INDIANS_LITTLE_FOURINDIANS_LITTLE_FOUR'
The PairwiseProxy:
>>> nums = PairwiseProxy([1, 2, 3, 4])
>>> nums + [1, 2, 3, 4]
2, 4, 6, 8
>>> nums * [2, 2, 3, 3]
2, 4, 9, 12
>>> nums == [2, 2, 3, 5]
False, True, True, False
>>> (nums.apply(float) / itertools.count(2) +
itertools.count(1)).apply(round, args=itertools.repeat([2]))
1.5, 2.67, 3.75, 4.8
>>> abs(nums - [3, 2, 1, 1])
2, 0, 2, 3
>>> (nums * [2, 2, 1, 5] + [3, 5, 9, 0]) / [4, 1, 2, 3]
1, 9, 6, 6
>>> ((nums * itertools.repeat(2) + itertools.repeat(3)) /
itertools.repeat(4)).replicate([2, 2, 3, 3])
1, 0, 0, 0
>>> ((nums * [2, 3, 4, 5]) > [5, 6, 7, 8]) != [True, True, False, True]
True, True, True, False
The RecursiveElementwiseProxy:
>>> treenums = RecursiveElementwiseProxy([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
>>> treenums + 1
((2, 3, 4), (5, 6, 7), (8, 9, 10))
>>> treenums * 2
((2, 4, 6), (8, 10, 12), (14, 16, 18))
>>> (treenums * 2 + 1).apply(float)
((3.0, 5.0, 7.0), (9.0, 11.0, 13.0), (15.0, 17.0, 19.0))
Feedback is welcome.
--
http://mail.python.org/mailman/listinfo/python-list
Re: python loggingL filter limitation, looks intentional?
Hi Vinay, On 16/01/2012 15:08, Vinay Sajip wrote: Filtering is intended to be for cases where integer level-based filtering is insufficient; ...or where you want to manipulate log messages, which is the use case I have. You are right that you would need to add a filter to all of the loggers where you want it to apply, or to all of the handlers where you want it to apply. Why is this? There must be some rationale for this rather than what, for me and others I've talked to, would seem more natural, ie: a filter on the root logger would get messages both logged to it and any messages propagated to it from child loggers to process. However, if you find your usage pattern occurring very commonly in your applications, it's easy enough to create a DelegatingHandler handler class which passes its events on to any number of handlers you like. But this is just extra work when the normal built-in delegation-upwards-ending-in-root works exactly as I want. It's also the opposite of what I'd need, I'd need to plug one handler into all the specific loggers that get used (and bear in mind that many libraries log to __name__ from modules and sub-modules) this is a pretty onerous task :-( cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: python loggingL filter limitation, looks intentional?
> Why is this? There must be some rationale for this rather than what, for me > and > others I've talked to, would seem more natural, ie: a filter on the root > logger would get messages both logged to it and any messages propagated to it > from child loggers to process. Perhaps you're right, but this can't be changed without breaking existing code, AFAICT. This hasn't come up before, so I'm not sure to what extent this is just a matter of taste. >> However, if you find your usage pattern occurring very commonly in your > applications, it's easy enough to create a DelegatingHandler handler class > which passes its events on to any number of handlers you like. > But this is just extra work when the normal built-in > delegation-upwards-ending-in-root works exactly as I want. It's not in general useful to filter on message content, when one factors in use of third-party libraries. Of course, if you are in control in the whole software stack you're using, or in certain very specific scenarios, it may be more useful - but in general it's most useful to filter on level and using logger names. The __name__ for loggers is useful to locate the source of events to a module, but you can have child loggers under that to log specific types of events in that module, and use the verbosity of those sub-module loggers to control output. Of course I don't know the precise reason you need things to work this way, so my suggestions and comments might appear somewhat general. > It's also the opposite of what I'd need, I'd need to plug one > handler into all the specific loggers that get used (and bear in mind that > many > libraries log to __name__ from modules and sub-modules) this is a pretty > onerous > task :-( I thought from an earlier comment - "rather than just the root logger where my handlers live" - that you had your handlers attached to the root logger, in which case it wouldn't be onerous at all. In place of those individual handlers attached to the root, you simply attach your DelegatingHandler to the root logger, and attach the filter and the other handlers to that DelegatingHandler instance. Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
Re: python loggingL filter limitation, looks intentional?
On Jan 16, 11:21 pm, Vinay Sajip wrote: > > I thought from an earlier comment - "rather than just the root logger where > my handlers live" - that you had your handlers attached to the root logger, > in which case it wouldn't be onerous at all. In place of those individual > handlers attached to the root, you simply attach your DelegatingHandler to > the root logger, and attach the filter and the other handlers to that > DelegatingHandler instance. An example of using a delegating handler: https://gist.github.com/1623702 Regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
pymysql only works under IDLE
I've been using pymysql to connect to a database, and it has suddenly stopped working on the one machine (a virtual server) where I really need it to work. I have a function with hard-coded parameters to do the connection, and now I'm getting an error that says, "Can't connect to MySQL server on ...". The strangest thing is that while I can't connect if I run the script from the command line, or from the shell under Wing IDE, I can connect if I run the script under the IDLE shell. I noticed that the command line shell prints Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. at startup, but the IDLE shell prints Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. So, while the first lines are identical, the second lines are different. Is this a different interpreter then? Can anyone tell me what the difference is? I'm hoping that may help me figure out what's gone wrong. I'm running on Windows 7. I'll be grateful for any help you can give me. Saul -- http://mail.python.org/mailman/listinfo/python-list
Re: pymysql only works under IDLE
On Mon, Jan 16, 2012 at 4:18 PM, Saul Spatz wrote: > I've been using pymysql to connect to a database, and it has suddenly stopped > working on the one machine (a virtual server) where I really need it to work. > I have a function with hard-coded parameters to do the connection, and now > I'm getting an error that says, "Can't connect to MySQL server on ...". The > strangest thing is that while I can't connect if I run the script from the > command line, or from the shell under Wing IDE, I can connect if I run the > script under the IDLE shell. > > I noticed that the command line shell prints > > Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > > at startup, but the IDLE shell prints > > Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on > win32 > Type "copyright", "credits" or "license()" for more information. > > So, while the first lines are identical, the second lines are different. Is > this a different interpreter then? Can anyone tell me what the difference > is? I'm hoping that may help me figure out what's gone wrong. You can check the value of `sys.executable` in each to see whether they're the same, and if not, where the other one is from. Cheers, Chris -- http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: pymysql only works under IDLE
Thanks a lot; I didn't know about sys.executable. For the record, IDLE is running pythonw.exe. I won't have a chance to test if this helps till tomorrow, unfortunately. -- http://mail.python.org/mailman/listinfo/python-list
Comparing None and ints
Hello, I discovered this strange property by accident: Python 2.7.2 (default, Nov 21 2011, 17:25:27) [GCC 4.6.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> None < 0 True >>> None == 0 False >>> None > 0 False >>> int(None) Traceback (most recent call last): File "", line 1, in TypeError: int() argument must be a string or a number, not 'NoneType' What was the rationale behind this design? Specifically, (None < 0) == Trueand(None == 0) == False ? Personally I would have expected an exception on all tests above. Cheers, Xav -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparing None and ints
On Tue, Jan 17, 2012 at 5:47 PM, Xavier Ho wrote: > What was the rationale behind this design? Specifically, (None < 0) == True > and (None == 0) == False? > > Personally I would have expected an exception on all tests above. Compare with Python 3: >>> None<0 Traceback (most recent call last): File "", line 1, in None<0 TypeError: unorderable types: NoneType() < int() ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparing None and ints
Good to see Python3 got rid of that confusion :] Cheers, Xav On 17 January 2012 16:50, Chris Angelico wrote: > On Tue, Jan 17, 2012 at 5:47 PM, Xavier Ho wrote: > > What was the rationale behind this design? Specifically, (None < 0) == > True > > and (None == 0) == False? > > > > Personally I would have expected an exception on all tests above. > > Compare with Python 3: > > >>> None<0 > Traceback (most recent call last): > File "", line 1, in >None<0 > TypeError: unorderable types: NoneType() < int() > > ChrisA > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparing None and ints
On Tue, Jan 17, 2012 at 5:55 PM, Xavier Ho wrote: > Good to see Python3 got rid of that confusion :] Yep. Obviously you can still test for equality (they're not equal, of course), but now they're non-ordered. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
