Re: virtualenv wrecked my Django+modules install

[Alec Taylor]

I ran Pinax-env\Scripts\deactivate.bat but it didn't change anything.

I'm skeptical if satchmo will work in a virtualenv, since many of its
dependencies (such as PIL) I had to install with a setup from here:
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil

How would I get around this issue in a virtualenv?


P:\Prototype>where python
C:\Python27\python.exe

P:\Prototype>Pinax-env\Scripts\activate.bat
(Pinax-env) P:\Prototype>where python
P:\Prototype\Pinax-env\Scripts\python.exe
C:\Python27\python.exe
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python philosophical question - strong vs duck typing

[Devin Jeanpierre]

> where n,m are compiler variables used to define the dependent
> (paramaterized) types array(int,n) and int(n)/ The double use of n means
> that the compiler checks that length n of the array equals the length
> passed.
>
> My response: in Python, there is no need to pass concrete collection sizes
> because they are packaged with the collection at runtime as an attribute.
> So:
>
> 1) In Python, there is no need for such checking. In addition, the for-loop
> construct, 'for item in iterable:', removes the possibility of indexing
> errors.

Correct. This is a systems language, designed so that you do the least
work possible and store the least amount possible in memory. For that
reason it's one of the fastest languages on the language shootout,
with the least memory usage overall. (
http://shootout.alioth.debian.org/ )

That is, you can also simply do "A[k] = 3", and if the compiler can
prove that k is always less than the length of the list, then this
goes ahead without any extra work like a runtime check. This is
similar to what Cython does above, but Python always does the check --
and ATS makes this optimization a core feature of the language, and
predictable: you can force the compiler to try to do this, and if it
can't, you can try to provide more information so that it can. The
easiest way to prove it was provided above, by doing a runtime check
-- but there are other ways (e.g. the inference Cython did; convenient
constants; etc.)

This is probably less appealing to Python programmers, who (rightly)
don't really care about speed unless it becomes an issue. For them,
ATS also has more advanced features like proofs of adherence to
specification and so on (e.g. FIB above). On the other hand, ATS's
main focus is, as far as I can tell, being something that's "as fast
as C, and safer than Haskell". I don't think it's meant for
Pythonistas. :)   (I've seen it compared to Ada, as well)

I should also note that while Python stores the length information at
runtime, you can do that in ATS too (it has exceptions). In fact, ATS
has two array types: array0 keeps the size information at runtime, and
array does not. With array0, out-of-bounds index access results in a
runtime exception, with no compile-time checks performed.

I don't really want to undestate how awesome Python is, though. I have
long been of the opinion that C's attitude was unacceptable[**] -- if
you forget to check, things go drastically wrong in undefined and
unpredictable ways (that depend on your libc/compiler/etc.). Python
offers a way out: all errors are checked for by Python itself. This
makes your job easier and makes mistakes obvious. ATS is nowhere near
as easy in general. :)

Also, you make a good point about for loops. They are a wonderful
thing. :)   (ATS doesn't have them; it could get them in theory...)


[*] With the idea being that in Python you can get unexpected errors
at runtime, whereas in ATS you can try to prove they can't exist, at
compile time. E.g. take "AttributeError: None has no attribute
'split'" versus non-nullable types
[**] Unfortunately, C is still irreplaceable. ATS is never going to
win this one. I do think that dependent typing will eventually enter
the mainstream, though. It's a powerful concept we rely on implicitly
all the time, and I seem to be seeing more of it lately.

> 2) Python classes are, in a sense, or in effect, runtime dependent types.
> While the formal implementation type of a 'list' is just 'list', the
> effective computation type is 'mutable sequence of length n'. The type of an
> iterator is 'read-only sequence of indefinite length'. I find this an
> interesting way to look at Python.

I think that's reasonable. I don't think it would be outrageous to
promote this concept to how we do isinstance checks, but nobody but me
seems to like things like "except IOError(errno.EBADF): ...". (Usually
the if-statements aren't really more complicated, but IOError is an
exception (which is being rectified a different way)).

But yes, even without it being part of the language we can model it
that way. And it's something we do all the time. I think another good
example of that is the "k-tuple". k-tuples seem very different to
n-tuples, for n != k.

-- Devin

On Wed, Jan 4, 2012 at 3:22 PM, Terry Reedy  wrote:
> On 1/4/2012 1:37 AM, Terry Reedy wrote:
>>
>> On 1/3/2012 8:04 PM, Devin Jeanpierre wrote:
>
>
>>> [ An example of a simple dependently typed program:
>>> http://codepad.org/eLr7lLJd ]
>>
>>
>> Just got it after a minute delay.
>
>
> A followup now that I have read it. Removing the 40 line comment, the
> function itself is
>
> fun getitem{n,m:nat}(arr : array(int, n) ,
>  length : int(n), index : int m) : int =
>    if index < length then
>        arr[index]
>    else
>        ~1 (* -1, error *)
>
> where n,m are compiler variables used to define the dependent
> (paramaterized) types array(int,n) and int(n)/ The double use of n means
> that the compiler checks that length n of the array equals the

Re: replacing __dict__ with an OrderedDict

[Ian Kelly]

On Fri, Jan 6, 2012 at 5:49 PM, Steven D'Aprano
 wrote:
> In the real world, test conflicts and dependencies are bugs in your test
> suite that should be fixed, like any other bug in code. The fact that it
> is test code that is failing is irrelevant.

I agree 100%, but none of that changes my point, which is that when
that this sort of problem arises, you need to be able to test
consistently to know that the bug is actually fixed.

> Every test should stand alone. You should be able to isolate each and
> every test and run it without the others.

Ideally, yes.  I'm talking about *unintentional* conflicts and dependencies.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Lie Ryan]

On 01/07/2012 11:49 AM, Steven D'Aprano wrote:

You may not be able to run tests*simultaneously*, due to clashes
involving external resources, but you should be able to run them in
random order.


tests that involves external resources should be mocked, although there 
are always a few external resources that cannot be mocked, those are the 
exceptions not the rule; a concurrent test runner might have mechanisms 
to mark them to be run synchronously.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Help with python-list archives

[random joe]

On Jan 6, 1:41 am, Ian Kelly  wrote:
> One could also avoid creating the intermediate file by using a
> StringIO to keep it in memory instead:

Yes StringIO is perfect for this. Many thanks to all who replied.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to get id(function) for each function in stack?

[Steven D'Aprano]

On Fri, 06 Jan 2012 10:02:28 -0800, dmitrey wrote:

> hi all,
> how to get id(func) for each func in stack? (I mean memory address, to
> compare it with id(some known funcs)) Thank you in advance, D.

id() does not return a memory address, except perhaps by accident. It 
returns a ID number. In Jython, and I think IronPython, id() returns a 
sequential number for each object created. The first object created by 
the Jython virtual machine gets ID 1, the second gets ID 2, and so on.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Steven D'Aprano]

On Fri, 06 Jan 2012 10:20:28 -0700, Ian Kelly wrote:

> On Fri, Jan 6, 2012 at 10:01 AM, Lie Ryan  wrote:
>> That unittest executes its tests in alphabetical order is
>> implementation detail for a very good reason, and good unittest
>> practice dictates that execution order should never be defined (some
>> even argued that the execution order should be randomized). If the test
>> runner turns out to execute tests concurrently, that should not cause
>> problems for a well-designed test. Displaying the test results in a
>> more convenient order for viewing is what you really wanted in 99.99%
>> of the cases.
> 
> Randomizing the order is not a bad idea, but you also need to be able to
> run the tests in a consistent order, from a specific random seed. In the
> real world, test conflicts and dependencies do happen,

In the real world, test conflicts and dependencies are bugs in your test 
suite that should be fixed, like any other bug in code. The fact that it 
is test code that is failing is irrelevant.

Also in the real world, sometimes it is too hard to fix a bug and you 
just live with it.


> and if we observe
> a failure, make a change, rerun the tests and observe success, we need
> to be able to be sure that we actually fixed the bug, and that it didn't
> pass only because it was run in a different order.

Every test should stand alone. You should be able to isolate each and 
every test and run it without the others. If you can't, your test suite 
is buggy. (Chances are good that most test suites are buggy. After all, 
who writes tests for their tests? That's just the start of an infinite 
regress with rapidly diminishing benefit.) 

You may not be able to run tests *simultaneously*, due to clashes 
involving external resources, but you should be able to run them in 
random order.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Steven D'Aprano]

On Sat, 07 Jan 2012 04:01:44 +1100, Lie Ryan wrote:

> On 01/07/2012 12:36 AM, Ulrich Eckhardt wrote:
>> True, perhaps, but doing it this way would be more fun and easier
>> reusable in other cases where the default order is not desirable. I can
>> also go and name the test functions test_000 to test_009 to get results
>> quickly, if that was the only goal.
> 
> Fun and easier, perhaps. Except that it solves the wrong problem.

Fun and easier, and a terrible thing to do. Contrast:

"test_binsearch_tuple is failing. What does that mean?"
"Oh, that tests that binsearch works on a tuple. You need to look at the 
BinSearch.search_tuple method and see what it's doing."

with 

"test_047 is failing. What does that mean?"
"How the hell should I know?"


Debugging is hard enough without obfuscating the test names. You wouldn't 
write a function called "func_009", why write one called "test_009"?



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to get id(function) for each function in stack?

[Lie Ryan]

On 01/07/2012 06:50 AM, Ian Kelly wrote:

On Fri, Jan 6, 2012 at 12:29 PM, dmitrey  wrote:

Python build-in function sum() has no attribute func_code, what should
I do in the case?


Built-in functions and C extension functions have no code objects, and
for that reason they also do not exist in the stack.  There is no way
to find sum() in the Python stack, because it isn't there.


a practical solution to this issue is to wrap the C functions in Python 
functions. You lose some speed but that might be an acceptable tradeoff 
in some situations (especially if you're only wrapping when debugging).


--
http://mail.python.org/mailman/listinfo/python-list

Re: Nested Function Question

[Ian Kelly]

On Fri, Jan 6, 2012 at 2:46 PM, GZ  wrote:
> Hi,
>
> I am reading the documentation of functools.partial (http://
> docs.python.org/library/functools.html#functools.partial) and found
> the following 'reference implementation' of functools.partial.
>
> def partial(func, *args, **keywords):
>    def newfunc(*fargs, **fkeywords):
>        newkeywords = keywords.copy()
>        newkeywords.update(fkeywords)
>        return func(*(args + fargs), **newkeywords)
>    newfunc.func = func
>    newfunc.args = args
>    newfunc.keywords = keywords
>    return newfunc
>
> I don't understand why the below 3 lines are needed:
>
>    newfunc.func = func
>    newfunc.args = args
>    newfunc.keywords = keywords
>
>
> It is as if they are trying to prevent garbage collection, but I don't
> get why it is needed. As long as something holds reference to newfunc,
> because it in turn references keywords and args, nothing will be
> freed. If nothing is referencing newfunc, then everything should be
> freed.

They exist for introspection.  The partial object has to store the
function and arguments it was passed so that it can call it later, so
as long as they're being stored anyway, why not make them visible?
-- 
http://mail.python.org/mailman/listinfo/python-list

Nested Function Question

[GZ]

Hi,

I am reading the documentation of functools.partial (http://
docs.python.org/library/functools.html#functools.partial) and found
the following 'reference implementation' of functools.partial.

def partial(func, *args, **keywords):
def newfunc(*fargs, **fkeywords):
newkeywords = keywords.copy()
newkeywords.update(fkeywords)
return func(*(args + fargs), **newkeywords)
newfunc.func = func
newfunc.args = args
newfunc.keywords = keywords
return newfunc

I don't understand why the below 3 lines are needed:

newfunc.func = func
newfunc.args = args
newfunc.keywords = keywords


It is as if they are trying to prevent garbage collection, but I don't
get why it is needed. As long as something holds reference to newfunc,
because it in turn references keywords and args, nothing will be
freed. If nothing is referencing newfunc, then everything should be
freed.

Thanks,
GZ
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Arnaud Delobelle]

On 6 January 2012 13:40, Ulrich Eckhardt
 wrote:
> Am 06.01.2012 12:44, schrieb Peter Otten:
>
>> Alternatively you can write your own test loader:
>
> [...CODE...]
>
> Well, actually you just did that for me and it works! ;)
>
>
> Nonetheless, I'm still wondering if I could somehow replace the dict with an
> OrderedDict.

No, you can't.

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Arnaud Delobelle]

On 6 January 2012 11:44, Peter Otten <__pete...@web.de> wrote:
> class Loader(unittest.TestLoader):
>    def getTestCaseNames(self, testCaseClass):
>        """Return a sequence of method names found within testCaseClass
>        sorted by co_firstlineno.
>        """

That's a clever trick!

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to support a non-standard encoding?

[Tim Wintle]

On Fri, 2012-01-06 at 12:00 -0800, jmfauth wrote:
> The distibution of such a codec may be a problem.

There is a register_codec method (or similar) in the codecs module.

Tim


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to get id(function) for each function in stack?

[Ian Kelly]

On Fri, Jan 6, 2012 at 12:56 PM, Dave Angel  wrote:
> On 01/06/2012 02:29 PM, dmitrey wrote:
>>
>> On Jan 6, 8:28 pm, Ian Kelly  wrote:
>>>
>>> On Fri, Jan 6, 2012 at 11:02 AM, dmitrey  wrote:

 hi all,
 how to get id(func) for each func in stack? (I mean memory address, to
 compare it with id(some known funcs))
 Thank you in advance, D.
>>>
>>> The answer hasn't changed since your last thread about this.  The
>>> stack contains code objects, not functions.  You can get the code
>>> objects using inspect.stack(), and compare them to the func_code
>>> attributes of the functions you're interested in.
>>>
>>> Also, there's no need to use id() for this.  Just use the "is"
>>> operator to check identity.
>>>
>>> for frame_tuple in inspect.stack():
>>>     frame = frame_tuple[0]
>>>     if frame.f_code is some_function.func_code:
>>>         print("Found it!")
>>>
>>> Cheers,
>>> Ian
>>
>> Python build-in function sum() has no attribute func_code, what should
>> I do in the case?
>> D.
>
> flag = False
>
>
> for frame_tuple in inspect.stack():
>    frame = frame_tuple[0]
>    if frame.f_code is some_function.func_code:
>        flag = True
>
> if !flag:
>    print "FuncDesigner.sum() not used.  Change."

That would also print when no sum function is used at all, e.g. a
simple "a + b".  I don't think that's what the OP wants.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to support a non-standard encoding?

[jmfauth]

On 6 jan, 11:03, Ivan  wrote:
> Dear All
>
> I'm developing a python application for which I need to support a
> non-standard character encoding (specifically ISO 6937/2-1983, Addendum
> 1-1989).  Here are some of the properties of the encoding and its use in
> the application:
>
>    - I need to read and write data to/from files.  The file format
>      includes two sections in different character encodings (so I
>      shan't be able to use codecs.open()).
>
>    - iso-6937 sections include non-printing control characters
>
>    - iso-6937 is a variable width encoding, e.g. "A" = [41],
>      "Ä" = [0xC8, 0x41]; all non-spacing diacritical marks are in the
>      range 0xC0-0xCF.
>
> By any chance is there anyone out there working on iso-6937?
>
> Otherwise, I think I need to write a new codec to support reading and
> writing this data.  Does anyone know of any tutorials or blog posts on
> implementing a codec for a non-standard characeter encoding?  Would
> anyone be interested in reading one?
>


Take a look at the files, Python modules, in the
...\Lib\encodings. This is the place where all codecs
are centralized. Python is magically using these
a long there are present in that dir.

I remember, long time ago, for the fun, I created such
a codec quite easily. I picked up one of the file as
template and I modified its "table". It was a
byte <-> byte table.

For multibytes coding scheme, it may be a litte bit more
complicated; you may take a look, eg, at the mbcs.py codec.

The distibution of such a codec may be a problem.



Another simple approach, os independent.

You probably do not write your code in iso-6937, but
you only need to encode/decode some bytes sequence
"on the fly". In that case, work with bytes, create
a couple of coding / decoding functions with a
created  [*] as helper. It's not so complicate.
Use  Py2 or  Py3 (the recommended
way ;-) ) as pivot encoding.

[*] I also created once a such a dict from
# 
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt

I never checked if it does correpond to the "official" cp1252
codec.

jmf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to get id(function) for each function in stack?

[Dave Angel]

On 01/06/2012 02:29 PM, dmitrey wrote:

On Jan 6, 8:28 pm, Ian Kelly  wrote:

On Fri, Jan 6, 2012 at 11:02 AM, dmitrey  wrote:

hi all,
how to get id(func) for each func in stack? (I mean memory address, to
compare it with id(some known funcs))
Thank you in advance, D.

The answer hasn't changed since your last thread about this.  The
stack contains code objects, not functions.  You can get the code
objects using inspect.stack(), and compare them to the func_code
attributes of the functions you're interested in.

Also, there's no need to use id() for this.  Just use the "is"
operator to check identity.

for frame_tuple in inspect.stack():
 frame = frame_tuple[0]
 if frame.f_code is some_function.func_code:
 print("Found it!")

Cheers,
Ian

Python build-in function sum() has no attribute func_code, what should
I do in the case?
D.

flag = False

for frame_tuple in inspect.stack():
frame = frame_tuple[0]
if frame.f_code is some_function.func_code:
flag = True

if !flag:
print "FuncDesigner.sum() not used.  Change."






--

DaveA

--
http://mail.python.org/mailman/listinfo/python-list

Re: how to get id(function) for each function in stack?

[Ian Kelly]

On Fri, Jan 6, 2012 at 12:29 PM, dmitrey  wrote:
> Python build-in function sum() has no attribute func_code, what should
> I do in the case?

Built-in functions and C extension functions have no code objects, and
for that reason they also do not exist in the stack.  There is no way
to find sum() in the Python stack, because it isn't there.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to get id(function) for each function in stack?

[dmitrey]

On Jan 6, 8:28 pm, Ian Kelly  wrote:
> On Fri, Jan 6, 2012 at 11:02 AM, dmitrey  wrote:
> > hi all,
> > how to get id(func) for each func in stack? (I mean memory address, to
> > compare it with id(some known funcs))
> > Thank you in advance, D.
>
> The answer hasn't changed since your last thread about this.  The
> stack contains code objects, not functions.  You can get the code
> objects using inspect.stack(), and compare them to the func_code
> attributes of the functions you're interested in.
>
> Also, there's no need to use id() for this.  Just use the "is"
> operator to check identity.
>
> for frame_tuple in inspect.stack():
>     frame = frame_tuple[0]
>     if frame.f_code is some_function.func_code:
>         print("Found it!")
>
> Cheers,
> Ian

Python build-in function sum() has no attribute func_code, what should
I do in the case?
D.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to get id(function) for each function in stack?

[Ian Kelly]

On Fri, Jan 6, 2012 at 11:02 AM, dmitrey  wrote:
> hi all,
> how to get id(func) for each func in stack? (I mean memory address, to
> compare it with id(some known funcs))
> Thank you in advance, D.

The answer hasn't changed since your last thread about this.  The
stack contains code objects, not functions.  You can get the code
objects using inspect.stack(), and compare them to the func_code
attributes of the functions you're interested in.

Also, there's no need to use id() for this.  Just use the "is"
operator to check identity.

for frame_tuple in inspect.stack():
frame = frame_tuple[0]
if frame.f_code is some_function.func_code:
print("Found it!")

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

how to get id(function) for each function in stack?

[dmitrey]

hi all,
how to get id(func) for each func in stack? (I mean memory address, to
compare it with id(some known funcs))
Thank you in advance, D.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Lie Ryan]

On 01/07/2012 04:20 AM, Ian Kelly wrote:

On Fri, Jan 6, 2012 at 10:01 AM, Lie Ryan  wrote:

That unittest executes its tests in alphabetical order is implementation
detail for a very good reason, and good unittest practice dictates that
execution order should never be defined (some even argued that the execution
order should be randomized). If the test runner turns out to execute tests
concurrently, that should not cause problems for a well-designed test.
Displaying the test results in a more convenient order for viewing is what
you really wanted in 99.99% of the cases.


Randomizing the order is not a bad idea, but you also need to be able
to run the tests in a consistent order, from a specific random seed.
In the real world, test conflicts and dependencies do happen, and if
we observe a failure, make a change, rerun the tests and observe
success, we need to be able to be sure that we actually fixed the bug,
and that it didn't pass only because it was run in a different order.

Concurrent testing is a bad idea for this reason -- it's not
repeatable (testing concurrency, OTOH, is a perfectly fine thing to be
thinking about).


Concurrent testing is perfectly fine strategy in the case where you have 
thousands of tests and running them synchronously will just take too 
long. Certainly it makes it harder to repeat the test if there is any 
sort of dependency in the tests, but when you have the large number of 
tests, the benefit may exceeds the drawbacks.


--
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Ian Kelly]

On Fri, Jan 6, 2012 at 10:01 AM, Lie Ryan  wrote:
> That unittest executes its tests in alphabetical order is implementation
> detail for a very good reason, and good unittest practice dictates that
> execution order should never be defined (some even argued that the execution
> order should be randomized). If the test runner turns out to execute tests
> concurrently, that should not cause problems for a well-designed test.
> Displaying the test results in a more convenient order for viewing is what
> you really wanted in 99.99% of the cases.

Randomizing the order is not a bad idea, but you also need to be able
to run the tests in a consistent order, from a specific random seed.
In the real world, test conflicts and dependencies do happen, and if
we observe a failure, make a change, rerun the tests and observe
success, we need to be able to be sure that we actually fixed the bug,
and that it didn't pass only because it was run in a different order.

Concurrent testing is a bad idea for this reason -- it's not
repeatable (testing concurrency, OTOH, is a perfectly fine thing to be
thinking about).

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Lie Ryan]

On 01/07/2012 12:36 AM, Ulrich Eckhardt wrote:

Am 06.01.2012 12:43, schrieb Lie Ryan:

On 01/06/2012 08:48 PM, Ulrich Eckhardt wrote:

Hi!

The topic explains pretty much what I'm trying to do under Python
2.7[1]. The reason for this is that I want dir(SomeType) to show the
attributes in the order of their declaration. This in turn should
hopefully make unittest execute my tests in the order of their
declaration[2], so that the output becomes more readable and structured,
just as my test code (hopefully) is.


IMO that's a futile effort, first, because as you already know, the test
should not rely on the order. If you want the result to be printed in a
certain order, that's a display issue, not testing order issue.


I'm not sure if you just -ahem- enjoy Usenet discussions, but please
read the footnote that explains that I don't want to discuss this part
and why you are actually wrong with your partial understanding of the
issue. ;^)


I fully understand your issue, and I stand by my opinion. I believe 
you're misunderstanding the nature of your problem, your issue is not 
that you want a customized test order execution, but you want a 
customized view of the test result.


That unittest executes its tests in alphabetical order is implementation 
detail for a very good reason, and good unittest practice dictates that 
execution order should never be defined (some even argued that the 
execution order should be randomized). If the test runner turns out to 
execute tests concurrently, that should not cause problems for a 
well-designed test. Displaying the test results in a more convenient 
order for viewing is what you really wanted in 99.99% of the cases.



 > I guess you would have better luck doing what you want by customizing
 > the TestResult or TestRunner.

True, perhaps, but doing it this way would be more fun and easier
reusable in other cases where the default order is not desirable. I can
also go and name the test functions test_000 to test_009 to get results
quickly, if that was the only goal.


Fun and easier, perhaps. Except that it solves the wrong problem.

--
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Ian Kelly]

On Fri, Jan 6, 2012 at 9:06 AM, Ian Kelly  wrote:
> On Fri, Jan 6, 2012 at 6:40 AM, Ulrich Eckhardt
>  wrote:
>> Nonetheless, I'm still wondering if I could somehow replace the dict with an
>> OrderedDict.
>
> In Python 3, yes.  This is pretty much the entire use case for the new
> __prepare__ method of metaclasses.  See the "OrderedClass" example at:
> http://docs.python.org/py3k/reference/datamodel.html#special-method-names

That link should be:
http://docs.python.org/py3k/reference/datamodel.html#customizing-class-creation
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Ian Kelly]

On Fri, Jan 6, 2012 at 6:40 AM, Ulrich Eckhardt
 wrote:
> Nonetheless, I'm still wondering if I could somehow replace the dict with an
> OrderedDict.

In Python 3, yes.  This is pretty much the entire use case for the new
__prepare__ method of metaclasses.  See the "OrderedClass" example at:
http://docs.python.org/py3k/reference/datamodel.html#special-method-names

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN]: 'tsshbatch', Batch ssh Tool, Version 1.134 Released

[Tim Daneliuk]

'tsshbatch' Version 1.134 is now released and available for download at:

 http://www.tundraware.com/Software/tsshbatch

This is the first public release.
-


What Is 'tsshbatch'?
--

'tsshbatch' is a tool to enable you to issue a command to many
servers without having to log into each one separately.  When writing
scripts, this overcomes the 'ssh' limitation of not being able to
specify the password on the command line.

'tsshbatch' also understands basic 'sudo' syntax and can be used
to access a server, 'sudo' a command, and then exit.

'tsshbatch' thus allows you to write complex, hands-off scripts that
issue commands to many servers without the tedium of manual login and
'sudo' promotion.  System administrators, especially, will find this
helpful when working in large server farms.

'tsshbatch' is written in Python and requires the 'paramiko library.
It has been tested on various Linux and FreeBSD variants as well
as cygwin on MS-Windows.

-

Complete details of all fixes, changes, and new features can be found in
the WHATSNEW.txt and documentation files included in the distribution.

A FreeBSD port has been submitted as well.

--
http://mail.python.org/mailman/listinfo/python-list

Re: UnicodeEncodeError when piping stdout, but not when printing directly to the console

[Adam Funk]

On 2012-01-06, Peter Otten wrote:

> Adam Funk wrote:
>
>> On 2012-01-04, Peter Otten wrote:
>> 
>>> Adam Funk wrote:
>> 
 How can I force python (preferably within my python program, rather
 than having to set something externally) to treat stdout as UTF-8?
>>>
>>>
>>> $ cat force_utf8.py
>>> # -*- coding: utf-8 -*-
>>> import sys
>>>
>>> if sys.stdout.encoding is None:
>>> import codecs
>>> writer = codecs.getwriter("utf-8")
>>> sys.stdout = writer(sys.stdout)
>>>
>>> print u"Ähnlich üblich nötig"
>> 
>> That's great, thanks!
>> 
>> I guess issues like this will magically go away when I eventually move
>> to Python 3?
>
> Not "magically", but UTF-8 has become the default encoding...

Close enough!



-- 
When Elaine turned 11, her mother sent her to train under
Donald Knuth in his mountain hideaway. [XKCD 342]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Ethan Furman]

Ulrich Eckhardt wrote:

Hi!

The topic explains pretty much what I'm trying to do under Python 
2.7[1]. The reason for this is that I want dir(SomeType) to show the 
attributes in the order of their declaration. This in turn should 
hopefully make unittest execute my tests in the order of their 
declaration[2], so that the output becomes more readable and structured, 
just as my test code (hopefully) is.


I believe unittest executes tests in alphabetical order, but it does not 
display them in the same order when it prints error/fail results.


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to support a non-standard encoding?

[Ivan Uemlianin]

Dear Tim

Thanks for your help.

> If your system version of iconv contains that encoding, ...

Alas, it doesn't:

$ iconv -l |grep 6937
$

Also, I'd like to package the app so other people could use it, so I 
wouldn't want to depend too much on the local OS.


Best wishes

Ivan


On 06/01/2012 13:47, Tim Wintle wrote:

On Fri, 2012-01-06 at 10:03 +, Ivan wrote:

Dear All

I'm developing a python application for which I need to support a
non-standard character encoding (specifically ISO 6937/2-1983, Addendum
1-1989).


If your system version of iconv contains that encoding (mine does) then
you could use a wrapped iconv library to avoid re-inventing the wheel.

I've got a forked version of the "iconv" package from pypi available
here:



.. it should work on python2.5-2.7

Tim




--

Ivan A. Uemlianin
Llaisdy
Speech Technology Research and Development

i...@llaisdy.com
 www.llaisdy.com
 llaisdy.wordpress.com
  github.com/llaisdy
 www.linkedin.com/in/ivanuemlianin

"Froh, froh! Wie seine Sonnen, seine Sonnen fliegen"
 (Schiller, Beethoven)

--
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Ulrich Eckhardt]

Am 06.01.2012 12:44, schrieb Peter Otten:

Alternatively you can write your own test loader:

[...CODE...]

Well, actually you just did that for me and it works! ;)


Nonetheless, I'm still wondering if I could somehow replace the dict 
with an OrderedDict.


Thank you!

Uli
--
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Ulrich Eckhardt]

Am 06.01.2012 12:43, schrieb Lie Ryan:

On 01/06/2012 08:48 PM, Ulrich Eckhardt wrote:

Hi!

The topic explains pretty much what I'm trying to do under Python
2.7[1]. The reason for this is that I want dir(SomeType) to show the
attributes in the order of their declaration. This in turn should
hopefully make unittest execute my tests in the order of their
declaration[2], so that the output becomes more readable and structured,
just as my test code (hopefully) is.


IMO that's a futile effort, first, because as you already know, the test
should not rely on the order. If you want the result to be printed in a
certain order, that's a display issue, not testing order issue.


I'm not sure if you just -ahem- enjoy Usenet discussions, but please 
read the footnote that explains that I don't want to discuss this part 
and why you are actually wrong with your partial understanding of the 
issue. ;^)



> I guess you would have better luck doing what you want by customizing
> the TestResult or TestRunner.

True, perhaps, but doing it this way would be more fun and easier 
reusable in other cases where the default order is not desirable. I can 
also go and name the test functions test_000 to test_009 to get results 
quickly, if that was the only goal.


Cheers!

Uli
--
http://mail.python.org/mailman/listinfo/python-list

[ANNOUNCE] greenlet 0.3.3

[Ralf Schmitt]

Hi,

I have uploaded greenlet 0.3.3 to PyPI:
http://pypi.python.org/pypi/greenlet

What is it?
---
The greenlet module provides coroutines for python. coroutines allow
suspending and resuming execution at certain locations.

concurrence[1], eventlet[2] and gevent[3] use the greenlet module in
order to implement concurrent network applications.

Documentation can be found here: http://greenlet.readthedocs.org

The code is hosted on github:
https://github.com/python-greenlet/greenlet

Changes in version 0.3.3

The NEWS file lists these changes for release 0.3.3:

* Use sphinx to build documentation and publish it on greenlet.rtfd.org
* Prevent segfaults on openbsd 4/i386
* Workaround gcc-4.0 not allowing to clobber rbx
* Enhance test infrastructure
* Fix possible compilation problems when including greenlet.h in C++ mode
* Make the greenlet module work on x64 windows
* Add a test for greenlet C++ exceptions
* Fix compilation on Solaris with SunStudio


[1] http://opensource.hyves.org/concurrence/
[2] http://eventlet.net/
[3] http://www.gevent.org/

-- 
Cheers
Ralf Schmitt
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to support a non-standard encoding?

[Tim Wintle]

On Fri, 2012-01-06 at 10:03 +, Ivan wrote:
> Dear All
> 
> I'm developing a python application for which I need to support a 
> non-standard character encoding (specifically ISO 6937/2-1983, Addendum 
> 1-1989).

If your system version of iconv contains that encoding (mine does) then
you could use a wrapped iconv library to avoid re-inventing the wheel.

I've got a forked version of the "iconv" package from pypi available
here:



.. it should work on python2.5-2.7

Tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Peter Otten]

Ulrich Eckhardt wrote:

> The topic explains pretty much what I'm trying to do under Python
> 2.7[1]. The reason for this is that I want dir(SomeType) to show the
> attributes in the order of their declaration. This in turn should
> hopefully make unittest execute my tests in the order of their
> declaration[2], so that the output becomes more readable and structured,
> just as my test code (hopefully) is.
> 
> I've been toying around with metaclasses, trying to replace __dict__
> directly, or using type() to construct the class, but either I hit
> read-only attributes or the changes seem to be ignored.

Alternatively you can write your own test loader:

$ cat ordered_unittest2.py
import unittest

class Test(unittest.TestCase):
def test_gamma(self):
pass
def test_beta(self):
pass
def test_alpha(self):
pass

class Loader(unittest.TestLoader):
def getTestCaseNames(self, testCaseClass):
"""Return a sequence of method names found within testCaseClass
sorted by co_firstlineno.
"""
def first_lineno(name):
method = getattr(testCaseClass, name)
return method.im_func.__code__.co_firstlineno

function_names = super(Loader, self).getTestCaseNames(testCaseClass)
function_names.sort(key=first_lineno)
return function_names


if __name__ == "__main__":
unittest.main(testLoader=Loader())

$ python2.7 ordered_unittest2.py -v
test_gamma (__main__.Test) ... ok
test_beta (__main__.Test) ... ok
test_alpha (__main__.Test) ... ok

--
Ran 3 tests in 0.001s

OK
$


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: replacing __dict__ with an OrderedDict

[Lie Ryan]

On 01/06/2012 08:48 PM, Ulrich Eckhardt wrote:

Hi!

The topic explains pretty much what I'm trying to do under Python
2.7[1]. The reason for this is that I want dir(SomeType) to show the
attributes in the order of their declaration. This in turn should
hopefully make unittest execute my tests in the order of their
declaration[2], so that the output becomes more readable and structured,
just as my test code (hopefully) is.


IMO that's a futile effort, first, because as you already know, the test 
should not rely on the order. If you want the result to be printed in a 
certain order, that's a display issue, not testing order issue. I guess 
you would have better luck doing what you want by customizing the 
TestResult or TestRunner.


--
http://mail.python.org/mailman/listinfo/python-list

replacing __dict__ with an OrderedDict

[Ulrich Eckhardt]

Hi!

The topic explains pretty much what I'm trying to do under Python 
2.7[1]. The reason for this is that I want dir(SomeType) to show the 
attributes in the order of their declaration. This in turn should 
hopefully make unittest execute my tests in the order of their 
declaration[2], so that the output becomes more readable and structured, 
just as my test code (hopefully) is.


I've been toying around with metaclasses, trying to replace __dict__ 
directly, or using type() to construct the class, but either I hit 
read-only attributes or the changes seem to be ignored.


As additional thought (but I'm not there yet), I guess that if I want 
dir(some_object) to be ordered similarly, I will also have to perform 
some steps on instance creation, not only on class creation, right?


Thanks for any suggestions!

Uli


[1] I'm stuck with 2.x for now, from what I found it would be easier 
using 3.x.


[2] No, don't tell me that the tests should run in any order. It's not 
the case that my tests depend on each other, but if one basic test for 
the presence of an API fails, the elaborate tests using that API will 
obviously fail, too, and I just want to take the first test that fails 
and analyse that instead of guessing the point to start debugging from 
the N failed tests.

--
http://mail.python.org/mailman/listinfo/python-list

share a apache pattern log parser

[罗晟]

Hi, folks.  Recently my work involved lots of parsing and statics of
apache server log.
Yes, we have pylogsparser and apachelog, but none of them is for human
IMHO :(
Inspired by kennethreitz, who is the author of the fabulous requests
module, and his concept of "python for human",
I extract a little apache pattern server log parser
"apache_log_parser" to share with you at 
https://github.com/happy15/apache_log_parser
Hope you like it.
-- 
http://mail.python.org/mailman/listinfo/python-list

How to support a non-standard encoding?

[Ivan]

Dear All

I'm developing a python application for which I need to support a 
non-standard character encoding (specifically ISO 6937/2-1983, Addendum 
1-1989).  Here are some of the properties of the encoding and its use in 
the application:


  - I need to read and write data to/from files.  The file format
includes two sections in different character encodings (so I
shan't be able to use codecs.open()).

  - iso-6937 sections include non-printing control characters

  - iso-6937 is a variable width encoding, e.g. "A" = [41],
"Ä" = [0xC8, 0x41]; all non-spacing diacritical marks are in the
range 0xC0-0xCF.

By any chance is there anyone out there working on iso-6937?

Otherwise, I think I need to write a new codec to support reading and 
writing this data.  Does anyone know of any tutorials or blog posts on 
implementing a codec for a non-standard characeter encoding?  Would 
anyone be interested in reading one?


With thanks and best wishes

Ivan


--

Ivan A. Uemlianin
Llaisdy
Speech Technology Research and Development

i...@llaisdy.com
 www.llaisdy.com
 llaisdy.wordpress.com
  github.com/llaisdy
 www.linkedin.com/in/ivanuemlianin

"Froh, froh! Wie seine Sonnen, seine Sonnen fliegen"
 (Schiller, Beethoven)

--
http://mail.python.org/mailman/listinfo/python-list

Re: UnicodeEncodeError when piping stdout, but not when printing directly to the console

[Peter Otten]

Adam Funk wrote:

> On 2012-01-04, Peter Otten wrote:
> 
>> Adam Funk wrote:
> 
>>> How can I force python (preferably within my python program, rather
>>> than having to set something externally) to treat stdout as UTF-8?
>>
>>
>> $ cat force_utf8.py
>> # -*- coding: utf-8 -*-
>> import sys
>>
>> if sys.stdout.encoding is None:
>> import codecs
>> writer = codecs.getwriter("utf-8")
>> sys.stdout = writer(sys.stdout)
>>
>> print u"Ähnlich üblich nötig"
> 
> That's great, thanks!
> 
> I guess issues like this will magically go away when I eventually move
> to Python 3?

Not "magically", but UTF-8 has become the default encoding...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UnicodeEncodeError when piping stdout, but not when printing directly to the console

[Adam Funk]

On 2012-01-04, Peter Otten wrote:

> Adam Funk wrote:

>> How can I force python (preferably within my python program, rather
>> than having to set something externally) to treat stdout as UTF-8?
>
>
> $ cat force_utf8.py
> # -*- coding: utf-8 -*-
> import sys
>
> if sys.stdout.encoding is None:
> import codecs
> writer = codecs.getwriter("utf-8")
> sys.stdout = writer(sys.stdout)
>
> print u"Ähnlich üblich nötig"

That's great, thanks!

I guess issues like this will magically go away when I eventually move
to Python 3?


-- 
Physics is like sex.  Sure, it may give some practical results,
but that's not why we do it.  [Richard Feynman]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help me get excited about python 3

[peter]

I'm sure Python 3 is wonderful, but I make heavy use of the Python
Imaging Library, which as I understand it has not been adapted to
Python 3.  There may be alternatives, but as I have a large amount of
working code using PIL I am reluctant to drop it just yet.

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: problem to install Flask

[88888 Dihedral]

MRAB於 2012年1月6日星期五UTC+8上午11時05分03秒寫道：
> On 06/01/2012 02:24, 水静流深 wrote:
> > ~$ sudo easy_install Flask
> > Searching for Flask
> > Reading http://pypi.python.org/simple/Flask/
> > Reading http://github.com/mitsuhiko/flask/
> > Best match: Flask 0.8
> > Downloading
> > http://pypi.python.org/packages/source/F/Flask/Flask-0.8.tar.gz#md5=a5169306cfe49b3b369086f2a63816ab
> > Processing Flask-0.8.tar.gz
> > Running Flask-0.8/setup.py -q bdist_egg --dist-dir
> > /tmp/easy_install-tnoyjj/Flask-0.8/egg-dist-tmp-pq04_a
> > Traceback (most recent call last):
> > File "/usr/local/bin/easy_install", line 9, in 
> > load_entry_point('distribute==0.6.24', 'console_scripts', 'easy_install')()
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 1883, in main
> > with_ei_usage(lambda:
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 1864, in with_ei_usage
> > return f()
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 1887, in 
> > distclass=DistributionWithoutHelpCommands, **kw
> > File "/usr/local/lib/python3.2/distutils/core.py", line 148, in setup
> > dist.run_commands()
> > File "/usr/local/lib/python3.2/distutils/dist.py", line 917, in run_commands
> > self.run_command(cmd)
> > File "/usr/local/lib/python3.2/distutils/dist.py", line 936, in run_command
> > cmd_obj.run()
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 349, in run
> > self.easy_install(spec, not self.no_deps)
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 589, in easy_install
> > return self.install_item(spec, dist.location, tmpdir, deps)
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 619, in install_item
> > dists = self.install_eggs(spec, download, tmpdir)
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 809, in install_eggs
> > return self.build_and_install(setup_script, setup_base)
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 1086, in build_and_install
> > self.run_setup(setup_script, setup_base, args)
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py",
> > line 1075, in run_setup
> > run_setup(setup_script, args)
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/sandbox.py",
> > line 31, in run_setup
> > lambda: exec(compile(open(
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/sandbox.py",
> > line 73, in run
> > return func()
> > File
> > "/usr/local/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/sandbox.py",
> > line 33, in 
> > ).read(), "setup.py", 'exec'),
> > File "setup.py", line 62
> > print "Audit requires PyFlakes installed in your system."""
> > ^
> > SyntaxError: invalid syntax
> >
> >
> > what is the matter?
> >
> The syntax of this line:
> 
> print "Audit requires PyFlakes installed in your system."
> 
> tells me that it's written for Python 2, but this:
> 
> /usr/local/lib/python3.2
> 
> tells me that you're using Python 3.
> 
> In Python 2, "print" is a statement; in Python 3 it's a function.

http://docs.python.org/library/2to3.html

I am studying the Python 2 to 3 module for code generation techniques
under my debugged environments by various operating systems such as 
 the linux, Windows or Apples. 
 
Python is an excellent programming language that really support 
cross platform SW developments. 

-- 
http://mail.python.org/mailman/listinfo/python-list