dasich / brownie Goto Github PK

Any interest in an implementation of collections.defaultdict?

>>> now = LazyProxy(datetime.utcnow)
>>> now.second
1
>>> now.second
2

Useful for APIs that expect an object and not a callable, but you need the object to behave more like a callable. A CachedLazyProxy could also be implemented that calls the callable only the first time, if there's a use case for that.

See patch at http://bpaste.net/show/12955/

Hi, what I've often seen (particularly in web frameworks and web templating languages are objects that behave like dicts.

I've got an implementation of said pattern myself, and would be happy to add it to brownie if you think it's something useful. Let me know and I'll craft up a patch and submit a pull request.

What the title says, see http://docs.python.org/dev/library/collections.html#collections.OrderedDict.move_to_end

It's (sometimes) exposed as brownie.parallel.get_cpu_count() and the docstring indicates that is supposed to take a default argument.

If you create an LFUCache without specifying a maxsize, setitem passes a -inf down into Counter.most_common which eventually blows up in heapq.nlargest

Here's the exception traceback:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/stephen/dev/taipan/categories/lib/python2.6/site-packages/brownie/caching.py", line 116, in __setitem__
    for key, _ in self.usage_counter.most_common(len(self) - self.maxsize):
  File "/Users/stephen/dev/taipan/categories/lib/python2.6/site-packages/brownie/datastructures/mappings.py", line 779, in most_common
    return nlargest(n, self.iteritems(), key=itemgetter(1))
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/heapq.py", line 370, in nlargest
    result = _nlargest(n, it)
OverflowError: cannot convert float infinity to integer

I haven't checked whether this is specific to LFUCache or effects the other caches as well.

We need support for progress bars, however if they are added they should support the following:

• (Un)known sizes
• Per update text updates or hints
• Update size (kB/s)
• ETA support

If the initial implementation doesn't support all of this it should be extend able enough to add support for these features.

The ability to change the design would be nice although I'm not sure that this is would be necessary.

Hello, I've got the following failure wen running runtests.py -- is it an expected issue?

Code/brownie » python runtests.py
[100%] 495 of 495 ETA:  00:00:00

brownie.tests.terminal.progress.TestDataTransferSpeedWidget.update
────────────────────────────────────────────────────────────────────────────────
Traceback (most recent call last):
  File "/home/bobry/Code/brownie/brownie/tests/terminal/progress.py", line 342, in update
    Assert(speed) > 45.0
AssertionError: 43.52 <= 45.0

Failures: 1/495 (1512 assertions)

Something like werkzeug.import_string would be nice to have.

At the moment it is quite easy to intercept any call to a special method, however due to the fact that they cannot all be treated equally in order to make use of the API the user has to handle the special cases in the handler when obtaining a result.

The API needs to be changed in a way that maintains the current simplicity but simply allows you to "do the right thing".

Maybe parts of the tests can be reused here?

Due to the way the dictionaries are implemented at the moment type checks do not yield the results one might expect e.g. ImmutableOrderedMultiDict is not a subclass of OrderedMultiDict nor is OrderedMultiDict a subclass of MultiDict.

This should be fixable at least in 2.6 and onwards.

try:
    with timeout(5):
        return subprocess.Popen(...).communicate(...)
except TimeoutError:
    return None

I have working code for this if you're interested (just needs to be turned into a context manager and optionally a decorator).

Yea, I keep thinking of things that are in Werkzeug that are neat :D while I don't want to depend on the whole of Werkzeug for something non-WSGI.

Would be useful to have thread and process safe stacks á la Werkzeug, for example in Attest to count assertions "per run()" and in the future I might need to keep a context-local "configuration" for e.g. whether to evaluate function calls or not.

(Hm, I wonder if it would mess with your using Attest if Attest used Brownie?)

What the title says.

Consider this snippet:

def foo():
    print "Hello"

def bar():
    print "World!"

If you now use compose with these two functions, it won't work:

compose(foo, bar)()

With this error message:

World!
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (4, 0))

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

C:\Dokumente und Einstellungen\nelson\Eigene Dateien\ in ()

C:\Programme\Python27\lib\site-packages\brownie\functional.pyc in (*a, *
*kws)
     28     elif len(functions) == 1:
     29         return functions[0]
---> 30     return reduce(lambda f, g: lambda *a, **kws: f(g(*a, **kws)), functi
ons)
     31
     32

TypeError: foo() takes no arguments (1 given)

If you spend foo a parameter, it works:

def foo(param):
    print "Hello"

So of course compose is not really meant to be used for functions without any parameter, but it could be documented anyway I think :-)

What's up with the LazyList.exhausting method?

https://github.com/DasIch/brownie/blob/master/brownie/datastructures/sequences.py#L70

It's really not clear what it does, especially given the fact that it takes no self yet it is not decorated as a staticmethod. So what is it and what does it to? Some documentation would help.

There are probably still some special cases which are not yet dealt with, particularly these http://docs.python.org/reference/datamodel.html#emulating-container-types, http://docs.python.org/reference/datamodel.html#additional-methods-for-emulation-of-sequence-types has to be considered as well.

A set() that preserves order but otherwise acts like a normal set: drops duplicates, supports intersection/union etc.

It would be nice to know which versions of Python are supported in brownie. Please consider adding this info to the README file.

it seems that most production deployments are either 2.4 -- CentOS 5, or 2.6 -- CentOS 6 or Debian Stable.

Why?

1. Abstract Base Classes from collections -- without them, we're forced to subclass dict and enjoy all the subtleties in both brownie.caching and brownie.datastructures.*
2. Less compatibility-code: Counter, itools.* to name a few

What do you think?