Re: [Python-Dev] Python for android - successfully cross-compiled without patches

[Olemis Lang]

Wow ! Awesome ! What specific ISA version(s) and/or device(s) have you tried ?


On 12/15/15, Vitaly Murashev  wrote:
> A lot of talks and patches around how to cross-compile python for andriod
> ...
>
> Dear python-dev@,
> I just want to say thanks to all of you for the high quality cross-platform
> code.
>
> Using alternative Android NDK named CrystaX (home page -
> https://www.crystax.net ) which provides high quality posix support in
> comparison with google's one we managed to cross-compile python 2.7 and 3.5
> completely without any patches applied.
>


-- 
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Brython committer
http://brython.info
http://github.com/brython-dev/brython

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Automated testing of patches from bugs.python.org

[Olemis Lang]

On 5/19/15, Terry Reedy tjre...@udel.edu wrote:
 On 5/19/2015 11:02 AM, Kushal Das wrote:
 Hi,


Hi !

I'm not very familiar with python-dev development workflows .
Nonetheless I just wanted to mention something that proved to be
useful for me in the past .

 With the help of CentOS project I am happy to announce an automated
 system [1] to test patches from bugs.python.org. This can be fully
 automated
 to test the patches whenever someone uploads a patch in the roundup, but
 for now it accepts IRC commands on #python-dev channel. I worked on a
 docker based prototype during sprints in PyCon.

 How to use it?
 ---

 1. Join #python-dev on irc.freenode.net.
 2. Ask for test privilege  from any one of kushal,Taggnostr,bitdancer
 3. They will issue a simple command. #add: YOUR_NICK_NAME
 4. You can then test by issuing the following command in the channel:

  #test: BUGNUMBER
  like #test: 21271

 What if there are multiple patches on the issue?  Pick the latest?
 This is not correct if someone follows up a patch with a 2.7 backport,
 or if there are competing patches.

[...]

It is a fact that running automated tests for patches is a really
useful feature . Nevertheless , IMHO for this to succeed at large
scale there is a need to manage the content of patches themselves ,
the base version they were built upon , as well as their order should
they be stacked . My suggestion for you therefore is to use Hg patch
repositories [1]_ as the starting point for your patch CI system .
Some of the benefits I could mention :

  - triggering (patch) builds on commit via web hooks
  - CI infrastructure needed turns out to be very
similar to the one setup for the main project
  - Commands to work on patch queue repositories are easy to learn
  - The possibility of editing series file is also useful for ignoring
some patches without removing their contents .
  - halt if patch cannot be applied upon latest version
* ... but still be able to see it in action by checking out the
right version
  of the code base used to build it in first place .
  - try the patch against different versions of the code base as it evolves
  - fuzzy refresh
  - version control for patches
  - multiple branches
* which may be bound to tickets in many ways e.g. naming conventions
* ... particularly useful for competing patches .

There are a few black spots too . Patch repositories deal with the
diff of a diff , hence some operations applied upon patches (e.g.
merging) might be quite messy , Most of the time this is no big deal
though .

The following are repositories I used while developing Apache
Bloodhound , during incubation and after it became a TLP . I'm
including them to illustrate branching and naming conventions (I used)
to keep track of tickets .

https://bitbucket.org/olemis/bloodhound-incubator-mq/
https://bitbucket.org/olemis/bloodhound-mq

HTH , since this way the workflow would be tightly integrated with
Mercurial , as highlighted by Berker Peksağ in previous messages .

.. [1] http://mercurial.selenic.com/wiki/MqTutorial

-- 
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 479 and asyncio

[Olemis Lang]

On 11/28/14, Guido van Rossum gu...@python.org wrote:
[...]

 @Olemis: You never showed examples of how your code would be used, so it's
 hard to understand what you're trying to do and how PEP 479 affects you.


The intention is not to restart the debate . PEP is approved , it's
done ... but ...

comment
as a side-effect beware of the consequences that it is a fact that
performance will be degraded (under certain circumstances) due to
either a chain of (SI = StopIteration)

raise SI = except SI: return = raise SI = ...

... or a few other similar cases which I will not describe for the
sake of not repeating myself and being brief .
/comment

-- 
Regards,

Olemis - @olemislc

Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 479 and asyncio

[Olemis Lang]

off-topic , not about asyncio but related to the PEP and other things
been discussed in this thread

On 11/28/14, Victor Stinner victor.stin...@gmail.com wrote:
 2014-11-28 3:49 GMT+01:00 Nick Coghlan ncogh...@gmail.com:

[...]

 So yes, it may help to have a new specialized exception, even if it
 works with RuntimeError.


This is somehow the situation I tried to explain in another thread
about PEP 479 (though I did not use the right words) and will be a
very common situation in practice .

 The drawback is that a new layer would make trollius even slower.


e.g. in a (private) library I wrote for a company that's basically
about composition of generators there is a situation similar to what
Victor explained in this thread . I mostly would have to end-up doing
one of a couple of things

try:
   ...
except RuntimeError:
   return

which over-complicates function definition and introduces a long chain
of (redundant) exception handling code just to end up raising
StopIteration once again (i.e. poor performance) or ...

# decorate functions in the public API
# ... may be improved but you get the idea
def myown_stopiter(f)
def wrapper(*args, **kwargs):
...
try:
...
except RuntimeError as exc:
if isinstance(exc.args[0], StopIteration):
raise StopIteration # exc.args[0] ?
else:
raise
...
return wrapper

which is actually a re-implementation of exception matching itself

Otherwise ...

{{{#!py

# in generator definition
# rather than natural syntax for defining sequence logic
raise MyOwnException(...)

# decorate functions in the public API
# ... may be improved but you get the idea

def myown_stopiter(f)
def wrapper(*args, **kwargs):
...
try:
...
except MyOwnException:
raise StopIteration
...
return wrapper
}}}

In the two las cases the library ends up having two functions , the
one that allows (MyOwnException | RuntimeError) to bubble up (only
used for defining compositions) , and the one that translates the
exception (which *should* not be used for compositions, even if it
will work, because of performance penalties) ... thus leading to
further complications at API level ...

Built-in behavior consisting in raising a subclass of RuntimeError is
a much better approach similar to the second case mentioned above .
This might definitely help to make less painful the process of
rewriting things all over to cope with incompatibilities caused by PEP
479 , but afaict performance issues will be there for a while .

-- 
Regards,

Olemis - @olemislc

Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 479 and asyncio

[Olemis Lang]

correction ...

On 11/28/14, Olemis Lang ole...@gmail.com wrote:

 try:
...
 except RuntimeError:
return


... should be

{{{#!py

# inside generator function body

try:
   ...
except StopIteration:
   return
}}}

[...]

-- 
Regards,

Olemis - @olemislc

Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Please reconsider PEP 479.

[Olemis Lang]

On 11/23/14, Mark Shannon m...@hotpy.org wrote:

[...]

 You are grouping next() and it.__next__() together, but they are different.
 I think we agree that the __next__() method is part of the iterator
 protocol and should raise StopIteration.
 There is no fundamental reason why next(), the builtin function, should
 raise StopIteration, just because  __next__(), the method, does.
 Many xxx() functions that wrap __xxx__() methods add additional
 functionality.

 Consider max() or min(). Both of these methods take an iterable and if
 that iterable is empty they raise a ValueError.
 If next() did likewise then the original example that motivates this PEP
 would not be a problem.


FWIW , I fully agree with this . My (personal) impression about PEP 479 is that

1. All the drawbacks mentioned by Raymond Hettinger ,
Nick Coghlan et al. in the other thread are **really** serious
2. The PEP actually over-complicates the so-far-*natural* definition of
the iterator protocol for generators ... and proposed solution adds more
issues than it really solves .
3. The fault is with next() raising StopIteration. Generators raising
StopIteration is not the problem. since the later is just an instance
of sub-typing whereas the former is more about an exceptional branch


 I'm not sure what you mean by your However above. In both __next__
 and next(), this is a signal; it becomes an error as soon as you call
 next() and don't cope adequately with the signal, just as KeyError is
 an error.

 2. The proposed solution does not address this issue at all, but rather
 legislates against generators raising StopIteration.

 Because that's the place where a StopIteration will cause a silent
 behavioral change, instead of cheerily bubbling up to top-level and
 printing a traceback.
 I must disagree. It is the FOR_ITER bytecode (implementing a loop or
 comprehension) that silently converts a StopIteration exception into a
 branch.

 I think the generator's __next__() method handling of exceptions is
 correct; it propogates them, like most other code.


This is really true and is the basis for composing generator
expressions (the discussion's been too long I do not want to add more
examples to emphasize this point) . IMHO StopIteration should be
propagated up to the caller in the context of iterator composition
(i.e. definition) as opposite to the case of client code actually
*using* (i.e. consuming) the generator (and the difference between
both scenarios is somehow similar to has-a vs is-a in classical OO
subtyping scenarios) . In the later case (use) raising ValueError or
RuntimeError (I'd prefer the former) would be really helpful , so I
really favor doing so in next() method rather than over-complicating
generators (and breaking the iterator subtype condition) for no good
(IMHO) reason .

[...]

p.s. I know that the PEP has been accepted by the BDFL , but I really
think this is an important concern , that's why I insist for the sake
of helping ... in case this represents a serious violation of
established rules please send me a private message and I will not do
it again (... but I'm hoping , after all, that post-acceptance debate
will not be considered as harmful when there's a good reason according
to someone ...)

-- 
Regards,

Olemis - @olemislc

Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reduce memory footprint of Python

[Olemis Lang]

On 10/6/13, Benjamin Peterson benja...@python.org wrote:
 2013/10/6 Victor Stinner victor.stin...@gmail.com:
 Hi,


:)

[...]

 unittest doesn't look to release memory (the TestCase class) after the
 execution of a test.

 Is it important to optimize unittests for memory usage?


AFAICT , test results will stored the outcomes of individual test
cases , which is O(n) under normal circumstances, but I guess this is
not what Victor was talking about (isn't it ?).

However , I've been thinking since some time ago that if the only
outcome of running the test suite is to dump the output to stdout or
any other file-like object then test result lists might be of little
value most of the time . Maybe an efficient runner + results
implementation focused on streaming output with no caching could help
with efficient memory allocations .

Regarding the memory allocated in setUp* method(s) then IMO it should
be torn down if it will not be used anymore. Such optimizations should
be better performed in TCs tearDown* methods themselves rather than
e.g. automatically deallocating memory associated to TC instances .
Sometimes different tools use such data for certain analysis .

jftr
BTW , I've detected a few instances where this proves to be useful (to
me) ; especially (concurrently) running (matrix jobs of) relatively
long test suites on hosted (Jenkins) instances , where quotas apply .
/jftr

-- 
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Popularidad de Python, septiembre 2013 -
http://goo.gl/fb/tr0XB
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: Reduce memory footprint of Python

[Olemis Lang]

forwarding to the list , sorry ...

-- Forwarded message --
From: Olemis Lang ole...@gmail.com
Date: Sun, 6 Oct 2013 17:09:38 -0500
Subject: Re: [Python-Dev] Reduce memory footprint of Python
To: Benjamin Peterson benja...@python.org

On 10/6/13, Benjamin Peterson benja...@python.org wrote:
 2013/10/6 Victor Stinner victor.stin...@gmail.com:
 2013/10/6 Benjamin Peterson benja...@python.org:
 2013/10/6 Victor Stinner victor.stin...@gmail.com:
 Hi,

 Slowly, I'm trying to see if it would be possible to reduce the memory
 footprint of Python using the tracemalloc module.

 First, I noticed that linecache can allocate more than 2 MB. What do
 you think of adding a registry of clear cache functions? For
 exemple, re.purge() and linecache.clearcache(). gc.collect() clears
 free lists. I don't know if gc.collect() should be related to this new
 registy (clear all caches) or not.

 What is the usecase for minimizing the memory usage of Python in the
 middle of a program?

 If you know that your application uses a lot of memory, it is
 interesting to sometimes (when the application is idle) try to release
 some bytes to not use all the system memory. On embedded devices,
 memory is expensive and very limited. Each byte is important :-)

 How many embedded systems are running Python?


ot
I know of a few of them, and it seems they will be more popular with
the growing interest for devices like Raspberry Pi and technologies
like 3D printing e.g. http://raspberry-python.blogspot.com/
/ot

-- 
Regards,

Olemis - @olemislc

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Popularidad de Python, septiembre 2013 -
http://goo.gl/fb/tr0XB
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] doctest and pickle

[Olemis Lang]

On 6/8/13, Ethan Furman et...@stoneleaf.us wrote:
 On 06/08/2013 03:09 AM, Serhiy Storchaka wrote:
 08.06.13 11:47, Ethan Furman написав(ла):
[...]

 Fair point.  But I suppose that if the end-user is running a doc test, it is
 not too much to require that the other
 tests be installed as well.  Plus, we definitely have the other tests.  :)


 Is it possible to add invisible code which doesn't displayed in the
 resulting documentation, but taken into account by
 doctest?

 I have no idea.  This is my first time using doctest.


ot
No ... if using doctest . To get such things done you'll need
something like dutest [1]_ [2]_ , but that's not an option for testing
docs in stdlib .
/ot

.. [1] dutest @ PyPI
(https://pypi.python.org/pypi/dutest‎)

.. [2] Purpose of Doctests [Was: Best practices for Enum]
(http://goo.gl/F7Afy)

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] doctest and pickle

[Olemis Lang]

On 6/7/13, Ethan Furman et...@stoneleaf.us wrote:
 Is there a doctest mailing list?  I couldn't find it.


JFTR, Testing-in-Python (TiP) ML should be the right target for
general purpose questions about testing, considering docs even for
unittest and doctest
http://lists.idyll.org/listinfo/testing-in-python

[...]
 Any advice on how to make it work?

 Here's the excerpt:

 ===
 Pickling
 

 Enumerations can be pickled and unpickled::

   from enum import Enum
   class Fruit(Enum):
  ... tomato = 1
  ... banana = 2
  ... cherry = 3
  ...
   from pickle import dumps, loads
   Fruit.tomato is loads(dumps(Fruit.tomato))
  True


... but it seems I'm still getting in tests an instance of Fruit after
invoking loads (do you ?)

[...]

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

[Olemis Lang]

On 5/20/13, Mark Janssen dreamingforw...@gmail.com wrote:
 * Doctests practically beg you to write your code first and then copy
 and
 paste terminal sessions - they're the enemy of TDD

 Of course , not , all the opposite . If the approach is understood
 correctly then the first thing test author will do is to write the
 code «expected» to get something done . When everything is ok with API
 code style then write the code . Many problems in the API and
 inconsistencies are thus detected early .

 Now all we need is a test() built-in, a companion to help() and we
 have the primo platform for doctest-code-test cycle for TDD and agile
 development.


«test() built-in» , interesting observation ... at least to me
setup.py test is more than enough in real-life , and I guess many
people really involved in building APIs for sure will notice that in
real life it's not as simple as «doctest-code-test» ; in the same way
that TDD is not always exactly like what is read in the books .
However writing doctests first for APIs could definitely be helpful to
think in advance in terms of the clients , especially when there are
some aspects looking a bit fuzzy .

Nevertheless , what is really needed , like I've been saying
(elsewhere) since years ago , is a better doctest module . The API in
stdlib does not offer the means to really benefit of its potential (=
that does not mean it's bad , it might be better ;) .

Above I was talking about testing libraries defining APIs . In the
meantime following the approach sketched above , it's been possible
(at least to me) to develop tested  documented RESTful + RPC APIs
with relatively little effort .

Besides , the differences between RPC and functions due to subtle
technological  implementation details may be erased . Using the
approach I've sketched in previous messages it's also possible to run
the very same doctests for APIs that are meant to work transparently
locally or hosted online (e.g. pastebins ... or other services in the
cloud) . The only thing needed is to use the right implementation of
doctests setUp / tearDown e.g. switching from Python functions to
ServerProxy , or REST , or ...

... so , yes , it's proven to be useful in practice ...

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

[Olemis Lang]

Hi !
:)

I'll be replying some individual messages in this thread in spite of
putting my replies in the right context . Sorry if I repeat something
, or this makes the thread hard to read . Indeed , IMHO this is a
subject suitable to discuss in TiP ML .

On 5/19/13, Gregory P. Smith g...@krypto.org wrote:
 On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger 
 raymond.hettin...@gmail.com wrote:


 On May 14, 2013, at 9:39 AM, Gregory P. Smith g...@krypto.org wrote:

 Bad: doctests.


 I'm hoping that core developers don't get caught-up in the doctests are
 bad meme.


 So long as doctests insist on comparing the repr of things being the number
 one practice that people use when writing them there is no other position I
 can hold on the matter.  reprs are not stable and never have been.
  ordering changes, hashes change, ids change, pointer values change,
 wording and presentation of things change.  none of those side effect
 behaviors were ever part of the public API to be depended on.


«Bad doctests» slogan is not positive because the subliminal message
for new users is «there's something wrong with that ... let's better
not use it» . IMHO that's not true ; doctest is an incredibly awesome
testing framework for delta assertions and there is nothing wrong with
the philosophy behind that module and its intent .

This surfaces an issue I've noticed years ago wrt doctest module (so,
yes , it's obvious there's an issue ;) . The way I see it this is more
about the fact that module frontend does not offer the means to
benefit from all the possibilities of doctest classes in the backend
(e.g. output checkers , doctest runners, ...)

 That one can write doctests that don't depend on such things as the repr
 doesn't ultimately matter because the easiest thing to do, as encouraged by
 examples that are pasted from an interactive interpreter session into docs,
 is to have the interactive interpreter show the repr and not add code to
 check things in a accurate-for-testing manner that would otherwise make the
 documentation harder for a human to read.


This is something that could be easily mitigated by a custom output
checker . In the end , in docs there is no difference between output
messages like 'Spam object at 0xb7cf5d70' or 'Spam object at
0x1' (i.e. some deterministic label like computed hex number or
anything else ...) . You might also avoid printing repr(s)

 Instead, we should be clear about their primary purpose which is to test
 the examples given in docstrings.   In many cases, there is a great deal
 of benefit to docstrings that have worked-out examples (see the
 docstrings
 in the decimal module for example).  In such cases it is also worthwhile
 to make sure those examples continue to match reality. Doctests are
 a vehicle for such assurance.  In other words, doctests have a perfectly
 legitimate use case.


 I really do applaud the goal of keeping examples in documentation up to
 date.  But doctest as it is today is the wrong approach to that. A repr
 mismatch does not mean the example is out of date.


... and I confess I never use doctest «as it is today» in stdlib . So
, you are right .

 We should continue to encourage users to make thorough unit tests
 and to leave doctests for documentation.  That said, it should be
 recognized that some testing is better than no testing.  And doctests
 may be attractive in that regard because it is almost effortless to
 cut-and-paste a snippet from the interactive prompt.  That isn't a
 best practice, but it isn't a worst practice either.


 Not quite, they at least tested something (yay!) but it is uncomfortably
 close to a worst practice.


I disagree . IMO what is a bad practice is to spread the rumor that
«doctests are evil» rather than saying «doctest module has
limitations»

 It means someone else needs to come understand the body of code containing
 this doctest when they make an unrelated change that triggered a behavior
 change as a side effect that the doctested code may or may not actually
 depend on but does not actually declare its intent one way or another for
 the purposes of being a readable example rather than accurate test.


I see no problem in keeping both these aspects .

 bikeshed colors: If doctest were never called a test but instead were
 called docchecker to not imply any testing aspect

No way ! ( IMHO )

I just wrote dutest [1]_ framework , built on top of doctest and
unittest , that does the following (among other things) :

  1. Implements unittest loaders for doctests
  2. Allows for customizing output checkers , doctest runners , ...
  anything you might find in the backend
 * For instance , replacing default test runner and output checkers
   might be useful to write delta assertions for command-line scripts
  3. Tightly integrated with unittest (e.g. custom TestSuite(s) ...)
  4. Access to unittest test case in special __tc__ variable , so all
  known assertion methods are handy ootb
  5. Encapsulate 

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

[Olemis Lang]

-- Forwarded message --
From: Olemis Lang ole...@gmail.com
Date: Mon, 20 May 2013 11:33:42 -0500
Subject: Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
To: Antoine Pitrou solip...@pitrou.net

On 5/20/13, Antoine Pitrou solip...@pitrou.net wrote:
 On Sat, 18 May 2013 23:41:59 -0700
 Raymond Hettinger raymond.hettin...@gmail.com wrote:

 We should continue to encourage users to make thorough unit tests
 and to leave doctests for documentation.  That said, it should be
 recognized that some testing is better than no testing.  And doctests
 may be attractive in that regard because it is almost effortless to
 cut-and-paste a snippet from the interactive prompt.  That isn't a
 best practice, but it isn't a worst practice either.

 There are other reasons to hate doctest, such as the obnoxious
 error reporting.  Having to wade through ten pages of output to find
 what went wrong is no fun.


+1

FWIW , while using dutest [1]_ each interactive example will be a test
case and therefore the match for that particular assertion will be
reported using the usual unittest output format

.. [1] dutest
(https://pypi.python.org/pypi/dutest)

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

[Olemis Lang]

On 5/19/13, Steven D'Aprano st...@pearwood.info wrote:
 On 20/05/13 09:27, Gregory P. Smith wrote:
 On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger 
 raymond.hettin...@gmail.com wrote:


 On May 14, 2013, at 9:39 AM, Gregory P. Smith g...@krypto.org wrote:

 Bad: doctests.


 I'm hoping that core developers don't get caught-up in the doctests are
 bad meme.


 So long as doctests insist on comparing the repr of things being the
 number
 one practice that people use when writing them there is no other position
 I
 can hold on the matter.  reprs are not stable and never have been.

 I think this *massively* exaggerates the problem with doc tests.

I agree , and it is a negative influence for beginners .

 I make
 heavy use of them, and have no problem writing doc tests that work in code
 running over multiple versions, including from 2.4 through 3.3. Objects that
 I write myself, I control the repr and can make it as stable as I wish. Many
 built-in types also have stable reprs. The repr for small ints is not going
 to change, the repr for floats like 0.5, 0.25, 0.125 etc. are stable and
 predictable, lists and tuples and strings all have stable well-defined
 reprs. Dicts are a conspicuous counter-example, but there are trivial
 work-arounds.


+1

 Doc tests are not limited to a simple-minded compare the object's repr.

Yes

 You can write as much, or as little, scaffolding around the test as you
 need. If the scaffolding becomes too large, that's a sign that the test
 doesn't belong in documentation and should be moved out, perhaps into a unit
 test, or perhaps into a separate literate testing document that can be as
 big as necessary without overwhelming the doc string.


There is an alternate approach related to a feature of dutest [1]_ I
mentioned in a previous message (i.e. doctests setUp and tearDown
methods) . The main reason to desire to leave long doctests
scaffolding code out (e.g. loading a Trac environment, or setting up a
separate Python virtual environment , subversion repository , ... as
part of -unit, functional, ...- test setup ) is to focus on SUT / API
details , avoid repetition of some steps , and keep tests readable .
This code is moved to underlying unittest setUp method and it's still
possible to write readable doctests for the particular feature of the
SUT .

In general there's a need to find a balance to decide what should be
«hidden» in doctests fixture methods and what should be written in
doctests . Based on my experience there's no benefit in using unittest
over doctests

unittests :

  - are unreadable
  - require knowledge of XUnit , etc ...
  - Writing complex assertions might be hard and tedious

doctests:

  - are extremely readable
  - anybody familiar with the SUT could write tests
  - especially for modules that are meant to be used by persons
who are not (professional / skilled) software developers
encapsulating the use of a testing framework is a plus ;
your test suite is «talking in users language»
(/me not sure about stdlib ...)


   ordering changes, hashes change, ids change, pointer values change,
 wording and presentation of things change.  none of those side effect
 behaviors were ever part of the public API to be depended on.

 Then don't write doctests that depend on those things. It really is that
 simple. There's no rule that says doctests have to test the entire API.
 Doctests in docstrings are *documentation first*, so you write tests that
 make good documentation.


... but someone could do so , if it wasn't by the current limitations
of doctest frontend .
;)

 The fact that things that are not stable parts of the API can be tested is
 independent of the framework you use to do the testing. If I, as an ignorant
 and foolish developer, wrote a unit test like this:

 class MyDumbTest(unittest.TestCase):
  def testSpamRepr(self):
  x = Spam(arg)
  self.assertEquals(repr(x), Spam object at 0x123ab)


 we shouldn't conclude that unit tests are bad, but that MyDumbTest is bad
 and needs to be fixed.

+1

[...]
 And that's great, it really is, I'm not being sarcastic. But unit testing is
 not in competition to doc testing, they are complimentary, not alternatives.
 If you're not using both, then you're probably missing out on something.


+1

PS: ... and well , this would be my last message about dutest and how
it improves upon what's offered by doctest module ...

Summarizing : «Bad doctests» is not a cool statement

.. [1] dutest @ PyPI
(https://pypi.python.org/pypi/dutest)

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

[Olemis Lang]

Hi !
... sorry , I could not avoid to reply this message ...

On 5/20/13, Michael Foord fuzzy...@voidspace.org.uk wrote:

 On 20 May 2013, at 18:26, Mark Janssen dreamingforw...@gmail.com wrote:

 I'm hoping that core developers don't get caught-up in the doctests are
 bad
 meme.

 Instead, we should be clear about their primary purpose which is to
 test
 the examples given in docstrings.
 In other words, doctests have a perfectly legitimate use case.

 But more than just one ;-)  Another great use has nothing to do with
 docstrings:  using an entire file as a doctest.   This encourages
 writing lots of text explaining what you're doing,. with snippets of
 code interspersed to illustrate that the code really does behave in
 the ways you've claimed.

 +1, very true.  I think doctest excel in almost every way above
 UnitTests.  I don't understand the popularity of  UnitTests, except
 perhaps for GUI testing which doctest can't handle.  I think people
 just aren't very *imaginative* about how to create good doctests that
 are *also* good documentation.



With enhanced doctests solution in mind ...

 Doc tests have lots of problems for unit testing.

 * Every line is a test with *all* output part of the test - in unit tests
 you only assert the specific details you're interested in

custom output checkers

 * Unordered types are a pain with doctest unless you jump through hoops

( custom output checkers + doctest runner ) | (dutest __tc__ global var)

 * Tool support for editing within doctests is *generally* worse

this is true , let's do it !

 * A failure on one line doesn't halt execution, so you can get many many
 reported errors from a single failure

it should if REPORT_ONLY_FIRST_FAILURE option [1]_ is set .

 * Try adding diagnostic prints and then running your doctests!

I have ... dutest suites for my Trac plugins do so . However logging
information is outputted to /path/to/trac/env/log/trac.log ... so a
tail -f is always handy .

 * Tools support in terms of test discovery and running individual tests is
 not as smooth

dutest offers two options since years ago MultiTestLoader combines
multiple test loaders to *load* different kinds of tests at once from
a module , whereas a package loader performs test discovery . These
loader objects are composable , so if an instance of MultiTestLoader
is supplied in to the package test loader then multiple types of tests
are loaded out of modules all over across the package hierarchy .

Indeed , in +10 years of Python development I've never used
unittest(2) discovery, and even recently implemented the one that's
used in Apache™ Bloodhound test suite . Unfortunately I've had no much
time to spend on improving all this support in dutest et al.

 * Typing  and ... all the time is really annoying

... I have faith ... there should be something like this for vim ... I
have faith ... ;)

 * Doctests practically beg you to write your code first and then copy and
 paste terminal sessions - they're the enemy of TDD

Of course , not , all the opposite . If the approach is understood
correctly then the first thing test author will do is to write the
code «expected» to get something done . When everything is ok with API
code style then write the code . Many problems in the API and
inconsistencies are thus detected early .

 * Failure messages are not over helpful and you lose the benefit of some of
 the new asserts (and their diagnostic output) in unittest

(custom ouput checkers) | ( dutest __tc__ variable )

 * Tests with non-linear code paths (branches) are more painful to express in
 doctests


that's a fact , not just branches , but also exceptions

Beyond this ...

My really short answer is that I do not agree with this . Like I just
said in previous messages with enhanced support like the one offered
by dutest (i.e. __tc__ global var bound to an instance of
unittest.TestCase) it's possible to invoke each and every unittest
assertion method . So this may be seen all the other way round
«unittest machinery is already used without even declaring a single
test class» ... and so on ...

... so , in concept , there is no real benefit in using unittest over
doctest *if* doctest module is eventually upgraded .

[...]

 However doctests absolutely rock for testing documentation / docstring
 examples.


FWIW , +1

[...]

.. [1] doctest.REPORT_ONLY_FIRST_FAILURE

(http://docs.python.org/2/library/doctest.html#doctest.REPORT_ONLY_FIRST_FAILURE)

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

[Olemis Lang]

On 5/20/13, Olemis Lang ole...@gmail.com wrote:
[...]
 On 5/20/13, Michael Foord fuzzy...@voidspace.org.uk wrote:
[...]

 * Tool support for editing within doctests is *generally* worse

 this is true , let's do it !

[...]
 * Typing  and ... all the time is really annoying

 ... I have faith ... there should be something like this for vim ... I
 have faith ... ;)


FWIW ...

an option could be to combine  auto-completion (in the end that's
yet another indentation ;) to this

http://architects.dzone.com/articles/real-time-doctest-checking-vim

... and I could better enjoy my vim + python development experience ;)

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8

[Olemis Lang]

On 4/3/13, Charles-François Natali cf.nat...@gmail.com wrote:
 Are you planning to cover the code quality of the interpreter itself
 too? I've been recently reading through the cert.org secure coding
 practice recommendations and was wondering if there has is any ongoing
 effort to perform static analysis on the cpython codebase.

 AFAICT CPython already benefits from Coverity scans (I guess the
 Python-security guys receive those notifications). Note that this only
 covers the C codebase.


... but the question seems to be « is there anything similar that
could be used for Python code ? »

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change to logging Formatters: support for alternative format styles

[Olemis Lang]

On Sun, Oct 31, 2010 at 9:55 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
 Olemis Lang olemis at gmail.com writes:

 On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw barry at python.org wrote:
  I haven't played with it yet, but do you think it makes sense to add a
  'style' keyword argument to basicConfig()?  That would make it pretty easy
  to get the formatting style you want without having to explicitly
  instantiate a Formatter, at least for simple logging clients.
 

 Since this may be considered as a little sophisticated, I'd rather
 prefer these new classes to be added to configuration sections using
 fileConfig (and default behavior if missing), and still leave
 `basicConfig` unchanged (i.e. *basic*) .


 Actually it's no biggie to have an optional style argument for basicConfig.
 People who don't use it don't have to specify it; the style argument would 
 only
 apply if format was specified.


ok

 For some people, use of {} over % is more about personal taste than about the
 actual usage of str.format's flexibility;

Thought you were talking about me, you only needed to say «he has
black hair and blue eyes» ... ;o)

 we may as well accommodate that
 preference, as it encourages in a small way the use of {}-formatting.


ok , nevermind , it's ok for me anyway (provided that sections for
`fileConfig` will be available) .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change to logging Formatters: support for alternative format styles

[Olemis Lang]

On Tue, Oct 26, 2010 at 6:15 AM, Nick Coghlan ncogh...@gmail.com wrote:
 On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
 On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip vinay_sa...@yahoo.co.uk 
 wrote:
 Comments welcome. Assuming there are no strong objections asking for 
 reversion
 of this change, I'll publicise to the wider community in a few days.

 It strikes me as a solid, pragmatic solution to a thorny problem.

 Looking at your checkin though, I wonder if it might be worth
 implementing some little formatting style classes to get rid of the
 if/elif chains from the Formatter code. Something like:

 Some syntax highlighting may make that wall-o'-code a little easier to
 read: http://pastebin.com/SG0Qr3r5


FWIW
+1

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change to logging Formatters: support for alternative format styles

[Olemis Lang]

On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw ba...@python.org wrote:
 On Oct 25, 2010, at 02:28 PM, Vinay Sajip wrote:

I've just checked in a change to logging into the py3k branch (r85835),
including doc changes and tests, for providing slightly more flexibility in
alternative format styles for logging.

Basically, Formatter.__init__ gets an extra optional keyword arg style=one of
'%' (default), '{' or '$'. This is then used to merge the format string with
the LogRecord: either fmt % record.__dict__, or fmt.format(**record.dict), or
string.Template(fmt).substitute(**record.dict). Backward compatibility is
maintained (unless I've missed something).

 This sounds like a reasonable solution that provides the flexibility we want,
 while maintaining backward compatibility.  Thanks!

 I haven't played with it yet, but do you think it makes sense to add a 'style'
 keyword argument to basicConfig()?  That would make it pretty easy to get the
 formatting style you want without having to explicitly instantiate a
 Formatter, at least for simple logging clients.


Since this may be considered as a little sophisticated, I'd rather
prefer these new classes to be added to configuration sections using
fileConfig (and default behavior if missing), and still leave
`basicConfig` unchanged (i.e. *basic*) .

PS: Good work !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Alias for distutils.file_util.write_file in e.g. shutils

[Olemis Lang]

On Sun, May 2, 2010 at 1:36 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
 a similar function in
    e.g. shutils module ?

 A: Yes :)

 Basically, anything useful in distutils.file_util and
 distutils.dir_util can maove in Shutil.
 That's why I added make_archive (and unpack_archive)

 Please add an issue, I'll work on adding this function,


http://bugs.python.org/issue8604

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Alias for distutils.file_util.write_file in e.g. shutils

[Olemis Lang]

Hello !

Often I have the contents to be written in a file at a given path that
I know as well. I recently tried to find a function in stdlib to do
that and to my surprise this is what I found :

  - Such function exists
  - It's `distutils.file_util.write_file`

IMO the last place where people'd look for such a function is inside
`distutils` package. Besides I reviewed modules listed under `File and
directory access` category in `Library Reference` and found nothing
even similar.

Q:
  - Is it a good idea to provide a similar function in
e.g. shutils module ?

Probably there's already a better way to do this and my comment is
just irrelevant . Anyway is just a suggestion ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Soporte para AMF (RPC) en Trac -
http://feedproxy.google.com/~r/simelo-es/~3/9dYgHeK5Be8/soporte-para-amf-rpc-en-trac.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] At least one package management tool for 2.7

[Olemis Lang]

On Wed, Mar 24, 2010 at 7:23 AM, anatoly techtonik techto...@gmail.com wrote:
 Sure. Package management tool should have an ability to update itself when 
 required regardless of Python release. For example::

 python.exe -m easy_install setuptools


 This should be:

    python -m easy_install -U setuptools


JFTR

More precisely, what I use for CI is

{{{
#!sh

$ easy_install -U setuptools==dev
}}}

but the `python -m` part should work as well ;o)

PS: e.g. that allows to check out code from SVN in order to use
setuptools 0.7.x `test_runner` switch like this

{{{
python -W ignore::DeprecationWarning setup.py test -r ciutils:junitrunner
}}}

;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
TracRpc: API v2: Test cases for XML-RPC ... PASS -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/228ef43726b0/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] At least one package management tool for 2.7

[Olemis Lang]

On Wed, Mar 24, 2010 at 7:50 AM, Darren Dale dsdal...@gmail.com wrote:
 On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
 The open question is: do we want to include a full installer that
 takes care of installing / removing dependencies as well ?

 I think not. Pip already provides this feature on the top of distutils
 (and distutils2 later I guess) and is not hard to install on the top
 of Python.

 Is pip able to determine and install dependencies recursively, like
 easy_install does? Or is it up to the requested package to it specify
 its dependencies (and its dependencies dependencies) in a pip
 requirements file that is distributed separately?


My experience is that only `install_requires` is needed (unless you
want to create app bundles AFAICR) , but in practice I've noticed that
*some* easy_installable packages are not pip-able (though I had no
time to figure out why :-/ )

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
On adding Hessian (RPC) support for Trac -
http://feedproxy.google.com/~r/simelo-en/~3/Vit6dRudChU/on-adding-hessian-rpc-support-for-trac.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
 On 11/02/2010 12:30, Nick Coghlan wrote:

 Michael Foord wrote:


 I'm not sure what response I expect from this email, and neither option
 will be implemented without further discussion - possibly at the PyCon
 sprints - but I thought I would make it clear what the possible
 directions are.


 I'll repeat what I said in the python-ideas thread [1]: with the advent
 of PEP 343 and context managers, I see any further extension of the
 JUnit inspired setUp/tearDown nomenclature as an undesirable direction
 for Python to take.

 Instead, I believe unittest should be adjusted to allow appropriate
 definition of context managers that take effect at the level of the test
 module, test class and each individual test.

 For example, given the following method definitions in unittest.TestCase
 for backwards compatibility:

   def __enter__(self):
     self.setUp()

   def __exit__(self, *args):
     self.tearDown()

 The test framework might promise to do the following for each test:

   with get_module_cm(test_instance): # However identified
     with get_class_cm(test_instance): # However identified
       with test_instance: # **
         test_instance.test_method()



What Nick pointed out is the right direction (IMHO), and the one I had
in mind since I realized that unittest extensibility is the key
feature that needs to be implemented . I even wanted to start a
project using this particular architecture to make PyUnit extensible.
It's too bad (for me) that I don't have time at all, to move forward
an just do it .

:(

I need days with 38 hrs !!! (at least)

:$

 Well that is *effectively* how they would work (the semantics) but I don't
 see how that would fit with the design of unittest to make them work
 *specifically* like that - especially not if we are to remain compatible
 with existing unittest extensions.


AFAICS (so not sure especially since there's nothing done to criticize
;o) is that backwards compatibility  is not the main stopper ...

 If you can come up with a concrete proposal of how to do this then I'm happy
 to listen. I'm not saying it is impossible, but it isn't immediately
 obvious. I don't see any advantage of just using context managers for the
 sake of it and definitely not at the cost of backwards incompatibility.


... but since I have nothing I can show you , everything is still in my mind ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free milestone ranch Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/rX6_RmRWThE/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Thu, Feb 11, 2010 at 9:41 AM, Olemis Lang ole...@gmail.com wrote:
 On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
 fuzzy...@voidspace.org.uk wrote:
 On 11/02/2010 12:30, Nick Coghlan wrote:

 Michael Foord wrote:


 I'm not sure what response I expect from this email, and neither option
 will be implemented without further discussion - possibly at the PyCon
 sprints - but I thought I would make it clear what the possible
 directions are.


 I'll repeat what I said in the python-ideas thread [1]: with the advent
 of PEP 343 and context managers, I see any further extension of the
 JUnit inspired setUp/tearDown nomenclature as an undesirable direction
 for Python to take.

 Instead, I believe unittest should be adjusted to allow appropriate
 definition of context managers that take effect at the level of the test
 module, test class and each individual test.

 For example, given the following method definitions in unittest.TestCase
 for backwards compatibility:

   def __enter__(self):
     self.setUp()

   def __exit__(self, *args):
     self.tearDown()

 The test framework might promise to do the following for each test:

   with get_module_cm(test_instance): # However identified
     with get_class_cm(test_instance): # However identified
       with test_instance: # **
         test_instance.test_method()



 What Nick pointed out is the right direction (IMHO), and the one I had
 in mind since I realized that unittest extensibility is the key
 feature that needs to be implemented . I even wanted to start a
 project using this particular architecture to make PyUnit extensible.
 It's too bad (for me) that I don't have time at all, to move forward
 an just do it .

 :(

 I need days with 38 hrs !!! (at least)

 :$

 Well that is *effectively* how they would work (the semantics) but I don't
 see how that would fit with the design of unittest to make them work
 *specifically* like that - especially not if we are to remain compatible
 with existing unittest extensions.


 AFAICS (so not sure especially since there's nothing done to criticize
 ;o) is that backwards compatibility  is not the main stopper ...

 If you can come up with a concrete proposal of how to do this then I'm happy
 to listen. I'm not saying it is impossible, but it isn't immediately
 obvious. I don't see any advantage of just using context managers for the
 sake of it and definitely not at the cost of backwards incompatibility.


 ... but since I have nothing I can show you , everything is still in my mind 
 ...


The idea (at least the one in my head ;o) is based on the features
recently introduced in JUnit 4.7, especially the @Rule

;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free milestone ranch Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/rX6_RmRWThE/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Thu, Feb 11, 2010 at 10:11 AM, Olemis Lang ole...@gmail.com wrote:
 On Thu, Feb 11, 2010 at 9:41 AM, Olemis Lang ole...@gmail.com wrote:
 On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
 fuzzy...@voidspace.org.uk wrote:
 On 11/02/2010 12:30, Nick Coghlan wrote:

 Michael Foord wrote:


 I'm not sure what response I expect from this email, and neither option
 will be implemented without further discussion - possibly at the PyCon
 sprints - but I thought I would make it clear what the possible
 directions are.


 I'll repeat what I said in the python-ideas thread [1]: with the advent
 of PEP 343 and context managers, I see any further extension of the
 JUnit inspired setUp/tearDown nomenclature as an undesirable direction
 for Python to take.

 Instead, I believe unittest should be adjusted to allow appropriate
 definition of context managers that take effect at the level of the test
 module, test class and each individual test.

 For example, given the following method definitions in unittest.TestCase
 for backwards compatibility:

   def __enter__(self):
     self.setUp()

   def __exit__(self, *args):
     self.tearDown()

 The test framework might promise to do the following for each test:

   with get_module_cm(test_instance): # However identified
     with get_class_cm(test_instance): # However identified
       with test_instance: # **
         test_instance.test_method()



 What Nick pointed out is the right direction (IMHO), and the one I had
 in mind since I realized that unittest extensibility is the key
 feature that needs to be implemented . I even wanted to start a
 project using this particular architecture to make PyUnit extensible.
 It's too bad (for me) that I don't have time at all, to move forward
 an just do it .

 :(

 I need days with 38 hrs !!! (at least)

 :$

 Well that is *effectively* how they would work (the semantics) but I don't
 see how that would fit with the design of unittest to make them work
 *specifically* like that - especially not if we are to remain compatible
 with existing unittest extensions.


 AFAICS (so not sure especially since there's nothing done to criticize
 ;o) is that backwards compatibility  is not the main stopper ...

 If you can come up with a concrete proposal of how to do this then I'm happy
 to listen. I'm not saying it is impossible, but it isn't immediately
 obvious. I don't see any advantage of just using context managers for the
 sake of it and definitely not at the cost of backwards incompatibility.


 ... but since I have nothing I can show you , everything is still in my mind 
 ...


 The idea (at least the one in my head ;o) is based on the features
 recently introduced in JUnit 4.7, especially the @Rule

 ;o)


.. [1] Writing your own JUnit extensions using @Rule | JUnit.org
 (http://www.junit.org/node/580)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
setUpClass and setUpModule in unittest | Python | Dev  -
http://feedproxy.google.com/~r/TracGViz-full/~3/x18-60vceqg/806136
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Thu, Feb 11, 2010 at 10:10 AM,  exar...@twistedmatrix.com wrote:
 On 02:41 pm, ole...@gmail.com wrote:

 On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
 fuzzy...@voidspace.org.uk wrote:

 On 11/02/2010 12:30, Nick Coghlan wrote:

 Michael Foord wrote:

 I'm not sure what response I expect from this email, and neither option
 will be implemented without further discussion - possibly at the PyCon
 sprints - but I thought I would make it clear what the possible
 directions are.

 I'll repeat what I said in the python-ideas thread [1]: with the advent
 of PEP 343 and context managers, I see any further extension of the
 JUnit inspired setUp/tearDown nomenclature as an undesirable direction
 for Python to take.

 Instead, I believe unittest should be adjusted to allow appropriate
 definition of context managers that take effect at the level of the test
 module, test class and each individual test.

 For example, given the following method definitions in unittest.TestCase
 for backwards compatibility:

   def __enter__(self):
     self.setUp()

   def __exit__(self, *args):
     self.tearDown()

 The test framework might promise to do the following for each test:

   with get_module_cm(test_instance): # However identified
     with get_class_cm(test_instance): # However identified
       with test_instance: # **
         test_instance.test_method()


 What Nick pointed out is the right direction (IMHO), and the one I had

 Why?  Change for the sake of change is not a good thing.  What are the
 advantages of switching to context managers for this?

 Perhaps the idea was more strongly justified in the python-ideas thread.
 Anyone have a link to that?

 in mind since I realized that unittest extensibility is the key
 feature that needs to be implemented . I even wanted to start a
 project using this particular architecture to make PyUnit extensible.

 What makes you think it isn't extensible now?  Lots of people are extending
 it in lots of ways.


Nothing I want to spend my time on. Just consider what the authors of
JUnit (and XUnit too) thought about JUnit4.7, what they did in JUnit
4.7, and you'll save me a lot of time I don't have to explain it to
you (/me not being rude /me have no time :-/ )

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Embedding pages?  -
http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages--td27358804.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Thu, Feb 11, 2010 at 11:18 AM, Tres Seaver tsea...@palladion.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Olemis Lang wrote:
 On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney ben+pyt...@benfinney.id.au 
 wrote:
 Michael Foord fuzzy...@voidspace.org.uk writes:

 I've used unittest for long running functional and integration tests
 (in both desktop and web applications). The infrastructure it provides
 is great for this. Don't get hung up on the fact that it is called
 unittest. In fact for many users the biggest reason it isn't suitable
 for tests like these is the lack of shared fixture support - which is
 why the other Python test frameworks provide them and we are going to
 bring it into unittest.
 I would argue that one of the things that makes ‘unittest’ good is that
 it makes it difficult to do the wrong thing — or at least *this* wrong
 thing. Fixtures persist for the lifetime of a single test case, and no
 more; that's the way unit tests should work.

 Making the distinction clearer by using a different API (and *not*
 extending the ‘unittest’ API) seems to be the right way to go.


 If that means that development should be focused on including
 mechanisms to make unittest more extensible instead of complicating
 the current «relatively simple» API , then I agree . I think about
 unittest as a framework for writing test cases; but OTOH as a
 meta-framework to be used as the basic building blocks to build or
 integrate third-party testing infrastructures (and that includes
 third-party packages ;o)

 Just as a point of reference:  zope.testing[1] has a layer feature
 which is used to support this usecase:  a layer is a class namedd as an
 attribute of a testcase, e.g.:

  class FunctionalLayer:
     @classmethod
     def setUp(klass):
          Do some expesnive shared setup.
         
     @classmethod
     def tearDown(klass):
          Undo the expensive setup.
         

  class MyTest(unittest.TestCase):
      layer = FunctionalLayer

 The zope.testing testrunner groups testcase classes together by layer:
 each layer's setUp is called, then the testcases for that layer are run,
 then the layer's tearDown is called.

 Other features:

 - - Layer classes can define per-testcase-method 'testSetUp' and
  'testTearDown' methods.

 - - Layers can be composed via inheritance, and don't need to call base
  layers' methods directly:  the testrunner does that for them.

 These features has been in heavy use for about 3 1/2 years with a lot of
 success.


I really like the style and the possibility to control the scope of (
setUp | tearDown ) . That's something I'd really consider to be
included in the API ... and if it was accompanied or integrated to
something like the @Rule in the backend to make it look like an
extension and thus provide «standar mechanism(s)» to get other similar
features done outside stdlib too, well, much better ;o)

I have to start using Zope ! Damn, I'm wasting my few most happy years !

PS: I confess that I didn't follow the thread @ Py-Ideas. I associated
Nick comment to the @Rule because, in JUnit, this is implemented using
something similar to Aspect Oriented Programming (something like
before and after hooks ;o), and in that case the Pythonic (and IMHO
more «explicit») translation could be context managers .

Perhaps I misunderstood something in previous messages .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PEP 391 - Please Vote!  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Thu, Feb 11, 2010 at 1:11 PM, Guido van Rossum gu...@python.org wrote:
 On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord fuzzy...@voidspace.org.uk 
 wrote:
 The next 'big' change to unittest will (may?) be the introduction of class
 and module level setUp and tearDown. This was discussed on Python-ideas and
 Guido supported them. They can be useful but are also very easy to abuse
 (too much shared state, monolithic test classes and modules). Several
 authors of other Python testing frameworks spoke up *against* them, but
 several *users* of test frameworks spoke up in favour of them. ;-)

 But unittest *is* still evolving,

as well as the XUnit paradigm as a whole, especially considering the
recent work committed to and released by JUnit

;o) .


 On the other hand, I think we should be careful to extend unittest in
 a consistent way.

+1 . IMO that's a key indicator of the success of anything related to
its evolution .

 Regarding the objection that setUp/tearDown for classes would run into
 issues with subclassing, I propose to let the standard semantics of
 subclasses do their job. Thus a subclass that overrides setUpClass or
 tearDownClass is responsible for calling the base class's setUpClass
 and tearDownClass (and the TestCase base class should provide empty
 versions of both). The testrunner should only call setUpClass and
 tearDownClass for classes that have at least one test that is
 selected.


+1

Considering zope.testing layers proposal, it seems that subclassing of
layers works different, isn't it ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Embedding pages?  -
http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages--td27358804.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel holger.kre...@gmail.com wrote:
 On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney ben+pyt...@benfinney.id.au 
 wrote:
 Michael Foord fuzzy...@voidspace.org.uk writes:

 The next 'big' change to unittest will (may?) be the introduction of
 class and module level setUp and tearDown. This was discussed on
 Python-ideas and Guido supported them. They can be useful but are also
 very easy to abuse (too much shared state, monolithic test classes and
 modules). Several authors of other Python testing frameworks spoke up
 *against* them, but several *users* of test frameworks spoke up in
 favour of them. ;-)

 I think the perceived need for these is from people trying to use the
 ‘unittest’ API for test that are *not* unit tests.


Well the example I was talking about before is when some (critical)
resource needed for unittesting requires a very, very heavy
initialization process. I'll employ the most recent example (hope it
doesn't look like too much biased, it's just to illustrate the whole
picture ;o) which is unittests for a framework like Trac . In that
case it is critical to have a Trac environment, a ready-to-use DB and
backend, initialize the plugins cache by loading relevant plugins, run
the actions specified by each IEnvironmentSetup participant, sometimes
a ready to use repository (if testing code depending on Trac VCS API)
and more ... Just considering these cases someone could :

  - Create a fake environment used as a stub
  - But having a single global environment is not a good idea because
 it would be very difficult to run multiple (independent) tests
 concurrently (e.g. test multiple Trac plugins concurrently in a dedicated
 CI environment). So an environment has to be started for every
 test run and be as isolated as possible from other similar
 stub environments
  - The DB and backend can be replaced by using in-memory SQLite
 connection
  - Plugins cache and loading is mandatory as well running the actions
 specified by each IEnvironmentSetup participant
  - VCS can be mocked, but if it's needed it has to be initialized as well

And all this is needed to run *ANY* test of *ANY* kind (that includes
unittests ;o) . I hope that, up to this point, you all are convinced
of the fact that all this cannot be done for each TestCase instance.
That's why something like class-level setup | teardown might be useful
to get all this done just once ... but it's not enough

Something I consider a limitation of that approach is that it is a
little hard to control the scope of setup and teardown. For instance,
if I was trying to run Trac test suite I'd like to create the
environment stub just once, and not once for every (module | class)
containing tests. The current approach does not fit very well
scenarios like this (i.e. setup | teardown actions span even beyond
single modules ;o)

So that's why it seems that the approach included in Trac testing code
(i.e. a global shared fixture ) will still be needed, but AFAICR it
breaks a little the interface of TC class and setup and tear down has
to be performed from the outside.

OTOH another minimalistic framework I've been building on top of
`dutest` to cope with such scenarios (aka TracDuTest but not oficially
released yet :-/ ) seems to handle all those features well enough by
using doctest extraglobs or by modifying the global namespace at any
given time inside setUp and tearDown (thus hiding all this code from
doctests ;o).

 One nice bit is that you can for a given test module issue py.test 
 --funcargs
 and get a list of resources you can use in your test function - by simply
 specifying them in the test function.

 In principle it's possible to port this approach to the stdlib - actually i
 consider to do it for the std-unittest- running part of py.test because
 people asked for it - if that proves useful i can imagine to refine it
 and offer it for inclusion.


Considering part of what I've mentioned above:

Q:
  - How could py.test help in cases like this ?
  - Considering the similitudes with unittest style (at least IMO)
 I think I'd prefer something like PeckCheck to generate and run
 parameterized TCs. What d'u think ? (I confess that I don't use
 py.test , nose ... because I see they use too much magic  ...,
 but that's just my *VERY* biased opinion, so I won't start
 a war or alike ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Embedding pages?  -
http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages--td27358804.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 6:15 PM,  exar...@twistedmatrix.com wrote:
 On 10:42 pm, fuzzy...@voidspace.org.uk wrote:

 On 09/02/2010 21:57, Ben Finney wrote:

 Michael Foordfuzzy...@voidspace.org.uk  writes:

 The next 'big' change to unittest will (may?) be the introduction of
 class and module level setUp and tearDown. This was discussed on
 Python-ideas and Guido supported them. They can be useful but are also
 very easy to abuse (too much shared state, monolithic test classes and
 modules). Several authors of other Python testing frameworks spoke up
 *against* them, but several *users* of test frameworks spoke up in
 favour of them. ;-)

 I think the perceived need for these is from people trying to use the
 18unittest 19 API for test that are *not* unit tests.

 That is, people have a need for integration tests (test this module's
 interaction with some other module) or system tests (test the behaviour
 of the whole running system). They then try to crowbar those tests into
 18unittest 19 and finding it lacking, since  18unittest 19 is designed
 for
 tests of function-level units, without persistent state between those
 test cases.

 I've used unittest for long running functional and integration tests (in
 both desktop and web applications). The infrastructure it provides is great
 for this. Don't get hung up on the fact that it is called unittest. In fact
 for many users the biggest reason it isn't suitable for tests like these is
 the lack of shared fixture support - which is why the other Python test
 frameworks provide them and we are going to bring it into unittest.

 For what it's worth, we just finished *removing* support for setUpClass and
 tearDownClass from Trial.


Ok ... but why ? Are they considered dangerous for modern societies ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PEP 391 - Please Vote!  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 Michael Foord fuzzy...@voidspace.org.uk writes:

 I've used unittest for long running functional and integration tests
 (in both desktop and web applications). The infrastructure it provides
 is great for this. Don't get hung up on the fact that it is called
 unittest. In fact for many users the biggest reason it isn't suitable
 for tests like these is the lack of shared fixture support - which is
 why the other Python test frameworks provide them and we are going to
 bring it into unittest.

 I would argue that one of the things that makes ‘unittest’ good is that
 it makes it difficult to do the wrong thing — or at least *this* wrong
 thing. Fixtures persist for the lifetime of a single test case, and no
 more; that's the way unit tests should work.

 Making the distinction clearer by using a different API (and *not*
 extending the ‘unittest’ API) seems to be the right way to go.


If that means that development should be focused on including
mechanisms to make unittest more extensible instead of complicating
the current «relatively simple» API , then I agree . I think about
unittest as a framework for writing test cases; but OTOH as a
meta-framework to be used as the basic building blocks to build or
integrate third-party testing infrastructures (and that includes
third-party packages ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free milestone ranch Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/rX6_RmRWThE/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues

[Olemis Lang]

On Wed, Feb 10, 2010 at 6:11 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
 On 10/02/2010 01:07, Ben Finney wrote:
 Michael Foordfuzzy...@voidspace.org.uk  writes:
 On 09/02/2010 21:50, Ben Finney wrote:

 I understood the point of ‘TestCase.shortDescription’, and indeed
 the point of that particular name, was to be clear that some *other*
 text could be the short description for the test case. Indeed, this
 is what you've come up with: a different implementation for
 generating a short description.


 Given that the change broke something, and the desired effect can be
 gained with a different change, I don't really see a downside to the
 change I'm proposing (reverting shortDescription and moving the code
 that adds the test name to TestResult).


 What you describe (adding the class and method name when reporting
 the test) sounds like it belongs in the TestRunner, since it's more a
 case of “give me more information about the test result”.

 The code for giving information about individual test results is the
 TestResult. The TestRunner knows nothing about each individual result (or
 even about each individual test as it happens). The TestRunner is
 responsible for the whole test run, the TestCase runs individual tests and
 the TestResult reports (or holds) individual test results (at the behest of
 the TestCase).

 Given this structure it is not possible for test descriptions to be the
 responsibility of the TestRunner and I don't feel like re-structuring
 unittest today. :-)


FWIW

+1

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Embedding pages?  -
http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages--td27358804.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Wed, Feb 10, 2010 at 3:56 PM, R. David Murray rdmur...@bitdance.com wrote:
 On Wed, 10 Feb 2010 09:45:41 -0500, Olemis Lang ole...@gmail.com wrote:
 On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel holger.kre...@gmail.com 
 wrote:
  On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney ben+pyt...@benfinney.id.au 
  wrote:
  Michael Foord fuzzy...@voidspace.org.uk writes:
 
  The next 'big' change to unittest will (may?) be the introduction of
  class and module level setUp and tearDown. This was discussed on
  Python-ideas and Guido supported them. They can be useful but are also
  very easy to abuse (too much shared state, monolithic test classes and
  modules). Several authors of other Python testing frameworks spoke up
  *against* them, but several *users* of test frameworks spoke up in
  favour of them. ;-)
 
  I think the perceived need for these is from people trying to use the
  unittest API for test that are *not* unit tests.
 

 Well the example I was talking about before is when some (critical)
 resource needed for unittesting requires a very, very heavy
 initialization process. I'll employ the most recent example (hope it
 doesn't look like too much biased, it's just to illustrate the whole
 picture ;o) which is unittests for a framework like Trac . In that
 case it is critical to have a Trac environment, a ready-to-use DB and
 backend, initialize the plugins cache by loading relevant plugins, run
 the actions specified by each IEnvironmentSetup participant, sometimes
 a ready to use repository (if testing code depending on Trac VCS API)
 and more ... Just considering these cases someone could :

   - Create a fake environment used as a stub
   - But having a single global environment is not a good idea because
      it would be very difficult to run multiple (independent) tests
      concurrently (e.g. test multiple Trac plugins concurrently in a dedica=
 ted
      CI environment). So an environment has to be started for every
      test run and be as isolated as possible from other similar
      stub environments
   - The DB and backend can be replaced by using in-memory SQLite
      connection
   - Plugins cache and loading is mandatory as well running the actions
      specified by each IEnvironmentSetup participant
   - VCS can be mocked, but if it's needed it has to be initialized as well

 And all this is needed to run *ANY* test of *ANY* kind (that includes
 unittests ;o) . I hope that, up to this point, you all are convinced

 This doesn't sound very unit-testy, really.  It sounds like you are
 operating at a rather high level (closer to integration testing).
 As someone else said, I don't see anything wrong with using unittest
 as a basis for doing that myself, but I don't think your example is a
 clear example of wanting a setup and teardown that is executed once per
 TestCase for tests that are more obviously what everyone would consider
 unit tests.


Well, probably this is OT here but I follow in order to clarify what I
am saying. I am not integrating talking about integration tests, but
in general, yes they are unittests, but for Trac plugins (i.e. it is
possible that others tests won't need all this ;o) . For example let's
consider TracRpc plugin. Let's say you are gonna implement an RPC
handler that retrieves the ticket summary provided it's ID (pretty
simple method indeed) . In that case you need

  - Implement IRPCHandler interface (in order to extend RPC system ;o)
  - Query ticket data

Let's say you will only test that second part (which is the functional
part without any objections ;o). In that case you'll still need a Trac
environment, you'll need to setup the DB connection inside of it , and
all that just to perform the query . In general, in such cases (e.g.
DB access, but there are others ;o), almost everything needs a Trac
environment and therefore, at least part of what I mentioned before

;o)

 So, having the connection to the database set up once at TestCase start,
 and closed at TestCase end, would make the most sense.  Currently there's
 no way I know of to do that, so I open and close the database for every
 unittest.  Fortunately it's an sqlite database, so the run time penalty
 for doing that isn't prohibitive.


I really cannot see the difference between this and what I mentioned
before since one of the things that's needed is to create a connexion
just once for each test run, but (guess-what !) the connection needs
to be set for the environment itself (i.e. trac.env.db ) so first the
chicken, then the egg ;o)

PS: BTW, The situation you mention is almost the classic example ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PEP 391 - Please Vote!  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
 Hello all,

 Several
 authors of other Python testing frameworks spoke up *against* them, but
 several *users* of test frameworks spoke up in favour of them. ;-)


+1 for having something like that included in unittest

 I'm pretty sure I can introduce setUpClass and setUpModule without breaking
 compatibility with existing unittest extensions or backwards compatibility
 issues

Is it possible to use the names `BeforeClass` and `AfterClass` (just
to be make it look similar to JUnit naming conventions ;o) ?

 - with the possible exception of test sorting. Where you have a class
 level setUp (for example creating a database connection) you don't want the
 tearDown executed a *long* time after the setUp. In the presence of class or
 module level setUp /tearDown (but only if they are used) I would expect test
 sorting to only sort within the class or module [1]. I will introduce the
 setUp and tearDown as new 'tests' - so failures are reported separately,

Perhaps I am missing something, but could you please mention what will
happen if a failure is raised inside class-level `tearDown` ?

 and
 all tests in the class / module will have an explicit skip in the event of a
 setUp failure.


+1

 A *better* (more general) solution for sharing and managing resources
 between tests is to use something like TestResources by Robert Collins.
 http://pypi.python.org/pypi/testresources/

 A minimal example of using test resources shows very little boilerplate
 overhead from what setUpClass (etc) would need, and with the addition of
 some helper functions could be almost no overhead. I've challenged Robert
 that if he can provide examples of using Test Resources to meet the class
 and module level use-cases then I would support bringing Test Resources into
 the standard library as part of unittest (modulo licensing issues which he
 is happy to work on).


I am not really sure about whether unittest API should grow, and grow,
and grow, and ... but if that means that TestResources will not be
even imported if testers don't do it explicitly in the code (which is
not the case of something like class level setUp/tearDown) then +1,
otherwise -0.5

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
TracGViz plugin downloaded more than 1000 times ( 300 from PyPI) -
http://feedproxy.google.com/~r/simelo-en/~3/06Exn-JPLIA/tracgviz-plugin-downloaded-more-than.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang ole...@gmail.com wrote:
 On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
 fuzzy...@voidspace.org.uk wrote:
 Hello all,

 Several
 authors of other Python testing frameworks spoke up *against* them, but
 several *users* of test frameworks spoke up in favour of them. ;-)


 +1 for having something like that included in unittest

 I'm pretty sure I can introduce setUpClass and setUpModule without breaking
 compatibility with existing unittest extensions or backwards compatibility
 issues

 Is it possible to use the names `BeforeClass` and `AfterClass` (just
 to be make it look similar to JUnit naming conventions ;o) ?


Another Q:

  - class setup method will be a `classmethod` isn't it ? It should not be
 a regular instance method because IMO it is not bound to a particular
 `TestCase` instance.

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Embedding pages? - Trac Users | Google Groups  -
http://feedproxy.google.com/~r/TracGViz-full/~3/-XtS7h-wjcI/e4cf16474aa3cb87
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

Sorry. I had not finished the previous message

On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang ole...@gmail.com wrote:
 On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang ole...@gmail.com wrote:
 On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
 fuzzy...@voidspace.org.uk wrote:
 Hello all,

 Several
 authors of other Python testing frameworks spoke up *against* them, but
 several *users* of test frameworks spoke up in favour of them. ;-)


 +1 for having something like that included in unittest

 I'm pretty sure I can introduce setUpClass and setUpModule without breaking
 compatibility with existing unittest extensions or backwards compatibility
 issues

 Is it possible to use the names `BeforeClass` and `AfterClass` (just
 to be make it look similar to JUnit naming conventions ;o) ?


 Another Q:

  - class setup method will be a `classmethod` isn't it ? It should not be
     a regular instance method because IMO it is not bound to a particular
     `TestCase` instance.


  - Is it possible to rely on the fact that all class-level tear down
methods will be guaranteed to run even if class-level setup
method throws an exception ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PEP 391 - Please Vote!  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
 Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :

 The next 'big' change to unittest will (may?) be the introduction of
 class and module level setUp and tearDown. This was discussed on
 Python-ideas and Guido supported them. They can be useful but are also
 very easy to abuse (too much shared state, monolithic test classes and
 modules). Several authors of other Python testing frameworks spoke up
 *against* them, but several *users* of test frameworks spoke up in
 favour of them. ;-)

 One problem is that it is not obvious what happens with inheritance.
 If I have a class-level setUp for class B, and class C inherits from B,
 will there be a separate invocation of setUp for C, or not?
 (I guess both possibilities have use cases)


Considering JUnit :

  - The @BeforeClass methods of superclasses will be run before those
the current class.
  - The @AfterClass methods declared in superclasses will be run after
those of the current class.

However considering that PyUnit is not based on annotations, isn't it
possible to specify that explicitly (and assume super-class method not
called by default) ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
gmane.comp.version-control.subversion.trac.general  -
http://feedproxy.google.com/~r/TracGViz-full/~3/SLY6s0RazcA/28067
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 1:44 PM, Michael Foord fuzzy...@voidspace.org.uk wrote:
 On 09/02/2010 17:57, Antoine Pitrou wrote:

 Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :


 The next 'big' change to unittest will (may?) be the introduction of
 class and module level setUp and tearDown. This was discussed on
 Python-ideas and Guido supported them. They can be useful but are also
 very easy to abuse (too much shared state, monolithic test classes and
 modules). Several authors of other Python testing frameworks spoke up
 *against* them, but several *users* of test frameworks spoke up in
 favour of them. ;-)


 One problem is that it is not obvious what happens with inheritance.
 If I have a class-level setUp for class B, and class C inherits from B,
 will there be a separate invocation of setUp for C, or not?
 (I guess both possibilities have use cases)


 Well, what I would expect (others may disagree) is that you only have class
 level setup invoked for classes that have tests (so not for base classes)
 and that the base-class setUpClass is only called if invoked by the
 subclass.

 I haven't thought about *where* the code to do this should go. It *could* go
 in TestSuite, but that feels like the wrong place.


When I implemented this in `dutest` I did it as follows :

  - Changed suiteClass (since it was an extension ;o)
  - I had to override the suite's `run` method

PS: Probably it's not the right place, but AFAIK it's the only place
«we» have to do such things ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Embedding pages? - Trac Users | Google Groups  -
http://feedproxy.google.com/~r/TracGViz-full/~3/-XtS7h-wjcI/e4cf16474aa3cb87
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 2:16 PM, Brian Curtin brian.cur...@gmail.com wrote:
 On Tue, Feb 9, 2010 at 12:29, Olemis Lang ole...@gmail.com wrote:

 On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
 fuzzy...@voidspace.org.uk wrote:
  I'm pretty sure I can introduce setUpClass and setUpModule without
  breaking
  compatibility with existing unittest extensions or backwards
  compatibility
  issues

 Is it possible to use the names `BeforeClass` and `AfterClass` (just
 to be make it look similar to JUnit naming conventions ;o) ?
 --
 Regards,

 Olemis.


 -1. setUp/tearDown is already well established here so I think it should
 follow the same convention.


ok no big deal

;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Embedding pages?  -
http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages--td27358804.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues

[Olemis Lang]

On Tue, Feb 9, 2010 at 4:50 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 Michael Foord mich...@voidspace.org.uk writes:

 It seems to me that the same effect (always reporting test name) can
 be achieved in _TextTestResult.getDescription(). I propose to revert
 the change to TestCase.shortDescription() (which has both a horrible
 name and a horrible implementation and should probably be renamed
 getDocstring so that what it does is obvious but never mind) and put
 the change into _TextTestResult.

[...]

 I've overridden that method to provide better, more specific, test case
 short descriptions, and the name works fine since I'm providing an
 overridden implementation of “the short description of this test case”.


Oh yes ! Thnx for mentioning that ! Very much !

If you move or remove shortDescription then I think dutest will be
broken. In that case there is an automatically generated short
description  comprising the doctest name or id (e.g. class name +
method name ;o) and example index (just remember that every
interactive example is considered to be a test case ;o)

In that case there is no other way to get this done unless an
all-mighty  heavy test result be implemented .

So I am *VERY* -1 for removing `shortDescription` (and I also think
that TC should be the one to provide the short desc rather than the
test result, just like what Ben Finney said before ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PEP 391 - Please Vote!  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 4:57 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 Michael Foord fuzzy...@voidspace.org.uk writes:

 The next 'big' change to unittest will (may?) be the introduction of
 class and module level setUp and tearDown. This was discussed on
 Python-ideas and Guido supported them. They can be useful but are also
 very easy to abuse (too much shared state, monolithic test classes and
 modules). Several authors of other Python testing frameworks spoke up
 *against* them, but several *users* of test frameworks spoke up in
 favour of them. ;-)

 I think the perceived need for these is from people trying to use the
 ‘unittest’ API for test that are *not* unit tests.


I dont't think so. I'll try to explain what I consider is a real use
case tomorrow ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free milestone ranch Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/rX6_RmRWThE/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 391 - Please Vote!

[Olemis Lang]

On Thu, Jan 14, 2010 at 4:23 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
 In October 2009 I created PEP 391 to propose a new method of configuring 
 logging using dictionaries:

  http://www.python.org/dev/peps/pep-0391/

 In November 2009 I posted to this list that the PEP was ready for review.

 I have had numerous helpful comments from some of you, and I have 
 incorporated most of them into updates to the PEP. Though I have the feeling 
 from community discussions that the PEP has been generally favourably 
 received - well I would think that, wouldn't I? ;-) - I've not asked for a 
 vote and so I don't know the state of community consensus regarding this PEP.

 So, can you please indicate your vote for or against incorporating PEP 391 
 into Python? It would be nice if I could incorporate the changes before 2.7a3 
 is released! Ideally, I would like to check in the changes unless there are 
 objections to doing so. All those who think that logging is currently hard to 
 configure will benefit from these changes, so here's the opportunity to pipe 
 up and improve things.


Probably the only thing that I found a little bit weird is the use of
`()` for custom instances (no big deal ;o).

In general I think it's great !!!

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
TracGViz plugin downloaded more than 1000 times ( 300 from PyPI) -
http://feedproxy.google.com/~r/simelo-en/~3/06Exn-JPLIA/tracgviz-plugin-downloaded-more-than.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

[Olemis Lang]

 On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
 victor.stin...@haypocalc.com wrote:
 Hi,

 Builtin open() function is unable to open an UTF-16/32 file starting with a
 BOM if the encoding is not specified (raise an unicode error). For an UTF-8
 file starting with a BOM, read()/readline() returns also the BOM whereas the
 BOM should be ignored.

[...]


I had similar issues too (please read below ;o) ...

On Thu, Jan 7, 2010 at 7:52 PM, Guido van Rossum gu...@python.org wrote:
 I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy
 talk. And for the other two, perhaps it would make more sense to have
 a separate encoding-guessing function that takes a binary stream and
 returns a text stream wrapping it with the proper encoding?


About guessing the encoding, I experienced this issue while I was
developing a Trac plugin. What I was doing is as follows :

- I guessed the MIME type + charset encoding using Trac MIME API (it
was a CSV file encoded using UTF-16)
- I read the file using `open`
- Then wrapped the file using `codecs.EncodedFile`
- Then used `csv.reader`

... and still get the BOM in the first value of the first row in the CSV file.

{{{
#!python

 mimetype
'utf-16-le'
 ef = EncodedFile(f, 'utf-8', mimetype)
}}}

IMO I think I am +1 for leaving `open` just like it is, and use module
`codecs` to deal with encodings, but I am strongly -1 for returning
the BOM while using `EncodedFile` (mainly because encoding is
explicitly supplied in ;o)

 --Guido


CMIIW anyway ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

[Olemis Lang]

Probably one part of this is OT , but I think it could complement the
discussion ;o)

On Mon, Jan 11, 2010 at 3:44 PM, M.-A. Lemburg m...@egenix.com wrote:
 Olemis Lang wrote:
 On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
 victor.stin...@haypocalc.com wrote:
 Hi,

 Builtin open() function is unable to open an UTF-16/32 file starting with a
 BOM if the encoding is not specified (raise an unicode error). For an UTF-8
 file starting with a BOM, read()/readline() returns also the BOM whereas 
 the
 BOM should be ignored.

 [...]


 I had similar issues too (please read below ;o) ...

 On Thu, Jan 7, 2010 at 7:52 PM, Guido van Rossum gu...@python.org wrote:
 I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy
 talk. And for the other two, perhaps it would make more sense to have
 a separate encoding-guessing function that takes a binary stream and
 returns a text stream wrapping it with the proper encoding?


 About guessing the encoding, I experienced this issue while I was
 developing a Trac plugin. What I was doing is as follows :

 - I guessed the MIME type + charset encoding using Trac MIME API (it
 was a CSV file encoded using UTF-16)
 - I read the file using `open`
 - Then wrapped the file using `codecs.EncodedFile`
 - Then used `csv.reader`

 ... and still get the BOM in the first value of the first row in the CSV 
 file.

 You didn't say, but I presume that the charset guessing logic
 returned either 'utf-16-le' or 'utf-16-be'

Yes. In fact they return the full mimetype 'text/csv; charset=utf-16-le' ... ;o)

 - those encodings don't
 remove the leading BOM.

... and they should ?

 The 'utf-16' codec will remove the BOM.


In this particular case there's nothing I can do, I have to process
whatever charset is detected in the input ;o)

 {{{
 #!python

 mimetype
 'utf-16-le'
 ef = EncodedFile(f, 'utf-8', mimetype)
 }}}

 Same here: the UTF-8 codec will not remove the BOM, you have
 to use the 'utf-8-sig' codec for that.

 IMO I think I am +1 for leaving `open` just like it is, and use module
 `codecs` to deal with encodings, but I am strongly -1 for returning
 the BOM while using `EncodedFile` (mainly because encoding is
 explicitly supplied in ;o)

 Note that EncodedFile() doesn't do any fancy BOM detection or
 filtering.

... directly.

 This is the job of the codecs.


OK ... to come back to the scope of the subject, in the general case,
I think that BOM (if any) should be handled by codecs, and therefore
indirectly by EncodedFile . If that's a explicit way of working with
encodings I'd prefer to use that wrapper explicitly in order to
(encode | decode) the file and let the codec detect whether there's a
BOM or not and «adjust» `tell`, `read` and everything else in that
wrapper (instead of `open`).

 Also note that BOM removal is only valid at the beginning of
 a file. All subsequent BOM-bytes have to be read as-is (they
 map to a zero-width non-breaking space) - without removing them.


;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Test cases for custom query (i.e report 9) ... PASS (1.0.0)  -
http://simelo.hg.sourceforge.net/hgweb/simelo/trac-gviz/rev/d276011e7297
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Question over splitting unittest into a package

[Olemis Lang]

On Mon, Jan 4, 2010 at 9:24 AM, Olemis Lang ole...@gmail.com wrote:
 On Thu, Dec 31, 2009 at 10:30 AM, Martin (gzlist) gzl...@googlemail.com 
 wrote:
 Thanks for the quick response.

 On 30/12/2009, Benjamin Peterson benja...@python.org wrote:

 but maybe a
 discussion could start about a new, less hacky, way of doing the same


 I am strongly -1 for modifying the classes in «traditional» unittest
 module [2]_ (except that I am strongly +1 for the package structure
 WITHOUT TOUCHING anything else ...) , and the more I think about it I
 am more convinced ... but anyway, this not a big deal (and in the end
 what I think is not that relevant either ... :o). So ...


IOW, if I had all the freedom to implement it, after the pkg structure
I'd do something like :

{{{
#!python

class TestResult:
# Everything just the same
def _is_relevant_tb_level(self, tb):
return '__unittest' in tb.tb_frame.f_globals

class BetterTestResult(TestResult):
# Further code ... maybe ;o)
#
def _is_relevant_tb_level(self, tb):
# This or anything else you might want to do ;o)
#
globs = tb.tb_frame.f_globals
is_relevant =  '__name__' in globs and \
globs[__name__].startswith(unittest)
del globs
return is_relevant
}}}

that's what inheritance is for ;o) ... but quite probably that's not
gonna happen, just a comment .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Ubuntu sustituye GIMP por F-Spot  -
http://feedproxy.google.com/~r/simelo-es/~3/-g48D6T6Ojs/ubuntu-sustituye-gimp-por-f-spot.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Question over splitting unittest into a package

[Olemis Lang]

On Thu, Dec 31, 2009 at 10:30 AM, Martin (gzlist) gzl...@googlemail.com wrote:
 Thanks for the quick response.

 On 30/12/2009, Benjamin Peterson benja...@python.org wrote:

 When I made that change, I didn't know that the __unittest hack was
 being used elsewhere outside of unittest, so I felt fine replacing it
 with another. While I still consider it an implementation detail, I
 would be ok with exposing an official API for this. Perhaps
 __unittest_ignore_traceback?

 Well, bazaar has had the trick for a couple of years, and googling
 around now turns up some other projects using it or thinking about it:
 http://github.com/gfxmonk/mocktest/commit/b5e94f7ee06ab627cea2c9cf90d0aeb63ee5a698
 http://bitbucket.org/uche/amara/changeset/eeaf69f48271/
 http://twistedmatrix.com/trac/ticket/4127


Add `dutest` and probably `nose` [2]_ and ...

 Reinstating the old implementation (with the same name) would mean
 that existing code would keep working with Python 2.7

IOW ... if it is removed all the libraries will have to change and
check for the Py version and ... (probably not a big deal depending on
the details of the «solution»)

 but maybe a
 discussion could start about a new, less hacky, way of doing the same


I am strongly -1 for modifying the classes in «traditional» unittest
module [2]_ (except that I am strongly +1 for the package structure
WITHOUT TOUCHING anything else ...) , and the more I think about it I
am more convinced ... but anyway, this not a big deal (and in the end
what I think is not that relevant either ... :o). So ...

pass

 May not be worthwhile making life more complicated though,
 there aren't *that* many unittest-extending projects.


But every library extending `unittest` will do it or otherwise
not-so-useful error messages will be displayed
;o)

PS: Happy New Year ! BTW

.. [1] [feature] nosexml should omit trace frames where `__unittest...
(http://code.google.com/p/python-nosexml/issues/detail?id=4#c0)

.. [2] Assessment of unittest 2.7 API : new features and opinions

(http://simelo-en.blogspot.com/2009/12/assessment-of-unittest-27-api-new.html)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free new ripit 1.3.3 Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/KFwyUTKH0vI/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Question over splitting unittest into a package

[Olemis Lang]

On Wed, Dec 30, 2009 at 3:04 PM, Benjamin Peterson benja...@python.org wrote:
 2009/12/30 Martin (gzlist) gzl...@googlemail.com:
 Hi Benjamin,

 Hi!

 In rev 74094 of Python, you split the unittest module up,

+1

 could you
 point me at any bug entries or discussion over this revision so I can
 catch up?

 This was mostly a discussion on IRC between Michael Foord and myself.


... and there was a previous thread about that some time ago here in python-dev
;o)


    def _is_relevant_tb_level(self, tb):
        return '__unittest' in tb.tb_frame.f_globals

 After:
 http://svn.python.org/view/python/trunk/Lib/unittest/__init__.py?revision=74095view=markup

    def _is_relevant_tb_level(self, tb):
        globs = tb.tb_frame.f_globals
        is_relevant =  '__name__' in globs and \
            globs[__name__].startswith(unittest)
        del globs
        return is_relevant


Had not seen this ... Hmmm ...
-1

 Only packages actually named unittest can be excluded.

 What is now the prefered method of marking a module as test-internal?
 Overriding the leading-underscore _is_relevant_tb_level method? How
 can this be done cooperatively by different packages?

 When I made that change, I didn't know that the __unittest hack was
 being used elsewhere outside of unittest, so I felt fine replacing it
 with another. While I still consider it an implementation detail, I
 would be ok with exposing an official API for this. Perhaps
 __unittest_ignore_traceback?


Hmmm ... One of the issues I didn't notice ...

IMO +1 for leaving it as it was before (i.e. __unittest) because :

  - the double underscore should mean (CMIIW) that it's an implementation detail
  - not few libs use that name already ;o)

+0.5 for adding `__unittest_ignore_traceback` or something shorter
(e.g. `__unittest_ignore`) too ...

+1 for documenting that «hack»

PS: `assertRaises` context managers are great !!! BTW
;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Assessment of unittest 2.7 API : new features and opinions  -
http://feedproxy.google.com/~r/simelo-en/~3/cVOgG8NIBFY/assessment-of-unittest-27-api-new.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Command line options for features in stdlib WAS: Pronouncement on PEP 389: argparse?

[Olemis Lang]

/me starting a new thread because this goes beyond argparse itself

On Tue, Dec 15, 2009 at 4:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
 Steven Bethard steven.bethard at gmail.com writes:

 Because people are continuing this discussion, I'll say again that
 argparse already supports this:

 Well I think the point is that if there is a default, the default should be
 sensible and not run against expectations.

+1

 It would probably be fine not to have a default at all, too.

-1

I really think that it's good to expect the same (similar) behavior
when the same options is accepted by multiple commands. In the end
that's a decision of the people implementing the concrete command line
tool, but it is nice to rely on something like : «if you forgot, or
don't remember or don't know about it then the std decision is
performed»

Now that you mention all this , I follow up with a comment that is
more about -v switch . Most of the time I realize that command line
apps have logging capabilities and should also allow different
verbosity levels (e.g. -q, -s, -v, --noisy) . The good thing is that
this always can be done the same way (i.e. using log levels defined in
logging module ) . The not so good news is that (in practice) coders
have to do it over and over every time they create a new command line
app, and users might need to remember those switches if the author
used different names . My suggestion is that it would be nice to
identify std switches and add support for configuring the cmd-line
parser and logger instance OOTB

{{{
#!python
import argparse
import logging

if __name__ == ’__main__’:
# create the parser
parser = argparse.ArgumentParser(description=’XXX’)
# add the arguments
...
# add args for verbosity level
logging.add_args(parser)
# parse the command line
args = parser.parse_args()
# configure logging --
# probably omitted if an option handles this
logging.fileConfig(*cfg_args)
# setup the logger instance
logging.argparseConfig(getLogger('xxx'), args)
}}}

The same reasoning could probably be extended to other modules in
stdlib (e.g. default encoding, testing, ...). It's probably a good
idea to define a set of (std) command line args for std features
(preferently without conflicting with existing standards ;o) and
provide shortcuts to ease configuration process when building command
line tools

PS: This thread might also be related to the previous one about
logging configuration using dicts

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Automated init.  -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/e122336d1eb2/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pronouncement on PEP 389: argparse?

[Olemis Lang]

On Mon, Dec 14, 2009 at 1:43 PM, Steven Bethard
steven.beth...@gmail.com wrote:
 On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking i...@colorstudy.com wrote:
 On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
 steven.beth...@gmail.com wrote:
 So there wasn't really any more feedback on the last post of the
 argparse PEP other than a typo fix and another +1.

 I just converted a script over to argparse.  It seems nice enough, I
 was doing a two-level command, and it was quite handy for that.

 One concern I had is that the naming seems at times trivially
 different than optparse, just because opt or option is replaced by
 arg or argument.  So .add_option becomes .add_argument, and
 OptionParser becomes ArgumentParser.  This seems unnecessary to me,
 and it make converting the application harder than it had to be.  It
 wasn't hard, but it could have been really easy.  There are a couple
 other details like this that I think are worth resolving if argparse
 really is supposed to replace optparse.

 Thanks for the feedback. Could you comment further on exactly what
 would be sufficient? It would be easy, for example, to add a subclass
 of ArgumentParser called OptionParser that has an add_option method.
 Do you also need the following things to work?

 * options, args = parser.parse_args() # options and args aren't
 separate in argparse
 * type='int', etc. # string type names aren't used in argparse
 * action='store_false' default value is None # it's True in argparse

 These latter kind of changes seem sketchier to me - they would make
 the initial conversion easier, but would make using argparse normally
 harder.


I thought that one of the following approaches would be considered :

  - let optparse remain in stdlib (as is or not ...)
  - re-implement optparse (i.e. a module having the same name ;o) using
argparse

isn't it ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free jacknife 1.3.4 v2 Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/q0HBIH_50wQ/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pronouncement on PEP 389: argparse?

[Olemis Lang]

On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
 On 14/12/2009 19:04, Ian Bicking wrote:

 [snip...]
 Another thing I just noticed is that argparse using -v for version
 where optparse does not (it only adds --version); most of my scripts
 that use -v to mean --verbose, causing problems.  Since this is a poll
 question on the argparse site I assume this is an outstanding question
 for argparse, but just generally I think that doing things the same
 way as optparse should be preferred when at all reasonable.


 I also use -v for verbose in a few scripts (including options to unittest
 when run with python -m). I've seen -V as a common abbreviation for
 --version (I've just used this with Mono for example).


Many Unix commands accept these switches too . AFAICR there was an
standard (well ...) set of command line options for Unix systems
(can't find a link :-/ )

.. [1] Command-Line Options
(http://www.faqs.org/docs/artu/ch10s05.html)


-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Automated init.  -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/e122336d1eb2/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pronouncement on PEP 389: argparse?

[Olemis Lang]

On Mon, Dec 14, 2009 at 3:00 PM, Steven Bethard
steven.beth...@gmail.com wrote:
 On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang ole...@gmail.com wrote:
 I thought that one of the following approaches would be considered :

  - let optparse remain in stdlib (as is or not ...)
  - re-implement optparse (i.e. a module having the same name ;o) using
    argparse

 isn't it ?

 Please read the PEP if you haven't, particularly the Why isn't the
 functionality just being added to optparse? section. I don't believe
 it is sensible to re-implement all of optparse. What Ian Bicking is
 proposing, I believe, is simpler -- adding a few aliases here and
 there so that you don't have to rename so many things when you're
 upgrading from optparse to argparse.


Well, I was actually thinking about adding such aliases in that module
and leave argparse just like it is today (and make the aliases as
compatible with optparse as possible ;o). So probably we're talking
about very similar things that will be placed in different places in
stdlib .

 For what it's worth, I'm still not sure it's a good idea,

... at least that way changes to have optparse-like interface will be
in a separate module. Or otherwise implement optparse like shown below

{{{
#!python

from argparse.optparse import *
}}}

and do the rest in argparse (it's the same anyway ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Initial version of protocol-provider patch. Patch does not currently
apply cleanly - it hasn'...  -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/b302540a1608/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pronouncement on PEP 389: argparse?

[Olemis Lang]

On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan ncogh...@gmail.com wrote:
 Steven Bethard wrote:
 On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang ole...@gmail.com wrote:
 I thought that one of the following approaches would be considered :

  1 - let optparse remain in stdlib (as is or not ...)
  2 - re-implement optparse (i.e. a module having the same name ;o) using
    argparse

 isn't it ?

 Please read the PEP if you haven't, particularly the Why isn't the
 functionality just being added to optparse? section. I don't believe
 it is sensible to re-implement all of optparse.

[...]

 For what it's worth, I'm still not sure it's a good idea, for exactly
 the reason Ian points out - having another class like OptionParser
 also feels like backward compatibility cruft.

 People also need to remember the very conservative deprecation path for
 optparse proposed in the PEP - never deprecated in 2.x,

So, I don't get it . What's the difference between this and the first
option I mentioned above ? I am probably missing the obvious but if
optparse will be «never deprecated in 2.x» then what's gonna happen ?
The only options I see are mentioned above (and I thought it was the
first one ;o) :

  - If (1) is the right one then -0 for considering backwards compatibility
  - If (2) is the right one then IMO, +1 for adding «further backwards
compatibility cruft» in a separate module and remove it in Python 3.5

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Looking for a technique to create flexible, graphical dashboards ...
- http://feedproxy.google.com/~r/TracGViz-full/~3/r7Zcyrg1n3U/019aa74e7095d047
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?

[Olemis Lang]

On Wed, Dec 9, 2009 at 11:34 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
 On 09/12/2009 16:27, Lennart Regebro wrote:

 I just ran the tests for zope.testing on Python 2.7, and the results are not
 good. It seems that there are multiple minor difference in the output
 formatting of the testresults between 2.7 and previous 2.x versions. The
 result is that all the tests that test testing (zope.testing includes a
 testrunner) fails.

 Is these changes necessary? It's going to be hell to test any form of
 testrunner under both 2.6 and 2.7 if the formatting of test results have
 changed.


This is fuzzy . It is necessary to be more precise and describe what
happens in detail.

Besides, I think that it's also necessary to mention (briefly) how
tests look like . Perhaps this is a situation where many fragile tests
[1]_ have been written and something


 Relying on specific formatting for test results *sounds* like you are
 relying on an implementation detail

This makes sense (~65% , and not because it's partially wrong but
because of subjective interpretations and criteria) . Perhaps the best
way would be to analyze contents of test results . The nature of test
runners implies that many features (e.g. formatting used to display
test results) are not standard . OTOH , the contents in instances of
TestResult are (should be more) standard, thereby it's (probably)
better to analyze the contents recorded in there (using doctest or
unittest, or ... ;o)

PS: I'm talking loud with my eyes closed , just a few preliminary
thoughts while waiting for the details ;o)


 Some of the failure reporting in unittest has *improved* in Python 2.7 - are
 you feeding the output of unittest back into doctest... ?


... and I'm assuming that this is what's been done, isn't it ?

.. [1] Fragile tests
(http://xunitpatterns.com/Fragile%20Test.html)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?

[Olemis Lang]

On Wed, Dec 9, 2009 at 12:14 PM, Olemis Lang ole...@gmail.com wrote:
 On Wed, Dec 9, 2009 at 11:34 AM, Michael Foord
 fuzzy...@voidspace.org.uk wrote:
 On 09/12/2009 16:27, Lennart Regebro wrote:

 I just ran the tests for zope.testing on Python 2.7, and the results are not
 good. It seems that there are multiple minor difference in the output
 formatting of the testresults between 2.7 and previous 2.x versions. The
 result is that all the tests that test testing (zope.testing includes a
 testrunner) fails.

 Is these changes necessary?

Well all Pythons need to change their (skin?) from time to time , isn't it ?
:P

 It's going to be hell to test any form of
 testrunner under both 2.6 and 2.7 if the formatting of test results have
 changed.


 This is fuzzy . It is necessary to be more precise and describe what
 happens in detail.


Sorry I didn't see your confirmation in the last msg you posted to the list .

@Fred Drake fdrake at acm dot org
{{{
Evolving the tests to avoid depending on these sorts of implementation
details is reasonable, IMO, and cuold even be considered a bugfix by
the Zope community.
}}}

Salomon says :

  - Problem could impact beyond Zope itself
  - unittest has been very stable (until now) so many solutions might be
tightly coupled to its implementation details (e.g. formatting and reports)
  - so why not to include an option in order to keep runners compatible with
 2.7 ?

A dinosaur will not become a Python in just a few days
;o)

 Besides, I think that it's also necessary to mention (briefly) how
 tests look like . Perhaps this is a situation where many fragile tests
 [1]_ have been written and something


... changed somewhere and your tests suddenly don't pass anymore
:(


 PS: I'm talking loud with my eyes closed , just a few preliminary
 thoughts while waiting for the details ;o)


... opening my eyes

:o)

 .. [1] Fragile tests
        (http://xunitpatterns.com/Fragile%20Test.html)


-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Depurando errores en aplicaciones web CGI con Python  -
http://feedproxy.google.com/~r/simelo-es/~3/xxyDHHH1YZ8/depurando-errores-en-aplicaciones-web.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?

[Olemis Lang]

On Wed, Dec 9, 2009 at 12:23 PM, Lennart Regebro lrege...@jarn.com wrote:
 On Wed, Dec 9, 2009 at 17:43, Fred Drake fdr...@acm.org wrote:
 On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson benja...@python.org 
 wrote:

 Evolving the tests to avoid depending on these sorts of implementation
 details is reasonable, IMO, and cuold even be considered a bugfix by
 the Zope community.

 Evolving doctest.py so it can handle this by itself would be
 considered a bugfix by me. :)

+1

This seems to be a better solution

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Depurando errores en aplicaciones web CGI con Python  -
http://feedproxy.google.com/~r/simelo-es/~3/xxyDHHH1YZ8/depurando-errores-en-aplicaciones-web.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?

[Olemis Lang]

On Wed, Dec 9, 2009 at 12:45 PM, Ian Bicking i...@colorstudy.com wrote:
 On Wed, Dec 9, 2009 at 11:23 AM, Lennart Regebro lrege...@jarn.com wrote:

  Evolving the tests to avoid depending on these sorts of implementation
  details is reasonable, IMO, and cuold even be considered a bugfix by
  the Zope community.

 Evolving doctest.py so it can handle this by itself would be
 considered a bugfix by me. :)

 It's about time doctest got another run of development anyway.

+1 ... that's why I implemented `dutest` BTW (I wanted more out of doctest ;o)

 I can
 imagine a couple features that might help:

 * Already in there, but sometimes hard to enable, is ellipsis.  Can you
 already do this?

      throw_an_exception()
     Traceback (most recent call last):
         ...
     DesiredException: ...


Probably useful ... unless /me want to match something inside the
error message (which seems very hard to specify if error messages
change from time to time )

 I'd like to see doctests be able to enable the ELLIPSIS option internally
 and globally (currently it can only be enabled outside the doctest, or for a
 single line).


Depending on what you mean when you mention «internally and globally»
, you could do such kinds of things with `dutest` too

 * Another option might be something version-specific, like:
      throw_an_exception() # +python2.7
     ... old exception ...
      throw_an_exception() # +python=2.7
     ... new exception ...

You mean skip LOCs if python version is not «compatible» with the one
specified in the doctests (e.g. # +python=2.7) ?

 Maybe for instance # py_version(less=2.7)

[...]

 Or, maybe checkers could be extended so they could actually
 suppress the execution of code (avoiding throw_an_exception() from being
 called twice).

Ah ! Just what I thought !

IMO that choice should be made explicit in the test code but once
again doctest does not support something like

{{{
 if sys.version_info[:3] = (2, 7) :
...   throw_an_exception()
 old exception
... else :
...   throw_an_exception() # +python=2.7
...
 new exception
}}}

I'd definitely prefer something like that or like what you've
mentioned before (i.e. # +python2.7)
but the idea needs to be refined ;o)

To be more explicit, the main limitation is that you cannot make
assertions for individual statements inside blocks (e.g. if, for ,
...) mainly because that's not how interactive sessions look like

;o)

 * Maybe slightly more general, would be the ability to extend OutputCheckers
 more easily than currently.

You can definitely play with these kind of things (e.g. change
OutputCheckers at runtime ;o) by using `dutest`  ;o)

 * Or, something more explicit than ELLIPSIS but able also be more flexible
 than currently possible, like:
      throw_an_exception()
     Traceback (most recent call last):
         ...
     DesiredException: [[2.6 error message | 2.7 error message]]

IMO, this would be limited to be used only with tracebacks, and
ellipsis are more general than that (match against anything) My
preferences above.

PS: Sorry for the commercials . I'm just mentioning that there's
something out there that enhances doctest to support some features you
mentioned , that was proposed some time ago to be included in stdlib
[3]_ and (at least in theory) is waiting for assessment | approval .
That time the main stopper was its recent release [1]_ , now it has
about (184 + 60 + 117 = 361 downloads from PyPI ;o) [2]_ ...

.. [3] [Python-Dev] An OO API for doctest / unittest integration...
(http://mail.python.org/pipermail/python-dev/2008-August/081761.html)

.. [1] [Python-Dev] An OO API for doctest / unittest integration...
(http://mail.python.org/pipermail/python-dev/2008-August/081762.html)

.. [2] Download dutest @ PyPI
(http://pypi.python.org/pypi/dutest)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Depurando errores en aplicaciones web CGI con Python  -
http://feedproxy.google.com/~r/simelo-es/~3/xxyDHHH1YZ8/depurando-errores-en-aplicaciones-web.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI comments and ratings, *really*?

[Olemis Lang]

On Thu, Nov 12, 2009 at 8:38 AM, Steven D'Aprano st...@pearwood.info wrote:
 On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote:
 Why are there comments on PyPI? Moreso, why are there comments which
 I cannot control as a package author on my very own packages? That's
 just absurd.

 No, what's absurd is thinking that the act of publishing software
 somehow gives you the right to demand control over what others say
 about your software.


Both of you are right , but I agree with Mr. Ludvig Ericson opinion (
90%). The package author probably has no «right to demand control over
what others say about her/his software» , but he has the right to
decide where such comments should be posted and also if he/she wants
to focus on (opinions | comments | ... ) or more useful feedback like
issues or support request .

For example, in my case, I prefer to have either custom ticket types
in the project's Trac environment or a plugin to receive this kind of
feedback *in the project's site* . IMHO PyPI is not the right place .
/me probably wrong

IMO -0.1 for votes and comments in PyPI and therefore

+1 for including settings to let coders decide (somehow ;o) whether to
allow this or not

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI comments and ratings, *really*?

[Olemis Lang]

On Thu, Nov 12, 2009 at 9:32 AM, Jesse Noller jnol...@gmail.com wrote:
 On Thu, Nov 12, 2009 at 9:25 AM, Barry Warsaw ba...@python.org wrote:
 On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote:

 Frankly, I agree with him. As implemented, I *and others* think this
 is broken. I've taken the stance of not publishing things to PyPi
 until A I find the time to contribute to make it better or B It
 changes.

 That's distressing.  For better or worse PyPI is the central repository of
 3rd party packages.  It should be easy, desirable, fun and socially
 encouraged to get your packages there.

 I personally think a ratings system can be useful, but you should be able to
 opt-out of it if you want.  Or just write such awesome software that the
 bogus bad reviews will be buried by an avalanche of kudos.

 -Barry

 I completely and totally agree with you. That's why it's a
 self-imposed thing for me, I want to help, but don't have the time. In
 the same breath, I don't want to support it as-is.

 PyPI isn't a place to file bugs, complain something didn't work for
 you if you didn't even have the common decency in some cases to email
 them. Being unable, as an author, to remove, moderate, or even respond
 to issues there bothers me quite a bit.


+1

 Heck, I would even be for requiring packages have a mailing list and /
 or bug tracker to even upload, rather than comments. At least then the
 authors or maintainers have a fighting chance.


Intention = suggestion + crazy idea = for a better PyPI

But there's probably a chance to display what people said in the
project's site . If PyPI would be able to retrieve that information
from the project's site (e.g. that'd be possible for Trac and other
PMS via RPC ) and also some of the aforementioned (Jesse's) issues
might be solved with added benefits (data being cached and discarded
from time to time, better performance, less DB space, ...) or not .

IMO, what's missing in my reasoning is whether there is a common std
API for e.g. issues . But there's a popular API for wikis (i.e.
WikiRPC) so probably there's something std (I repeat, that I don't
know :-/ ) out there . At least Trac's TicketRPC is very simple (i.e.
two simple methods) and extensible (e.g. custom ticket fields ;o)

PS: I don't really know the exact details of the impl of votes and
comments in PyPI.

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI comments and ratings, *really*?

[Olemis Lang]

Intention = precision = for a better PyPI

On Thu, Nov 12, 2009 at 1:54 PM, Guido van Rossum gu...@python.org wrote:
 On Thu, Nov 12, 2009 at 10:30 AM, Terry Reedy tjre...@udel.edu wrote:
 Barry Warsaw wrote:

 On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote:

 Frankly, I agree with him. As implemented, I *and others* think this
 is broken. I've taken the stance of not publishing things to PyPi
 until A I find the time to contribute to make it better or B It
 changes.

 That's distressing.  For better or worse PyPI is the central repository of
 3rd party packages.  It should be easy, desirable, fun and socially
 encouraged to get your packages there.

 I think his point is that a new book announcement servive is different from
 a book review and rating service.  And that mixing the two is 'socially
 discouraging'. I do not know what the answer is

 I would say that publishers disagree -- they seem to really like
 adding social stuff to their book announcement service. See e.g.
 Amazon (which combines all functions: announcement/promotion,
 ordering/download, review/comments/rate/popularity).


... but (most) book writers don't use an issue tracker to manage and
get *useful* feedback from their readers (I know there are exceptions
to the rule ;o) and fix the book chapters or anything else . Besides
there are some differences between software and books and the way both
of them are created, used and enhanced . What I don't like (today)
about comments + votes is that I have to do the same thing in two
different places (especially because one of the sources is *very*
noisy). If there's a way to integrate both and «reduce» the noise ,
that would be nice .

;o)

 I agree that creating a good social app is not easy, and if we can't
 improve the social app embedded in PyPI quickly enough, we should at
 least give authors the option to disable comments.

+1

 Of course, as a
 user, I might not trust a module that has no reviews or ratings.


Not really sure. For example, if a user access the page for setuptools
(just an example ;o) soon she/he will realize that other people use it
very often and also has a high kwalitee score, therefore it is quite
unlikely that such package be «irrelevant» or «untrusted» (this is
IMHO) .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI comments and ratings, *really*?

[Olemis Lang]

Intention = personal opinion = for a better  PyPI

On Thu, Nov 12, 2009 at 2:38 PM, Jesse Noller jnol...@gmail.com wrote:
 On Thu, Nov 12, 2009 at 2:30 PM, Guido van Rossum gu...@python.org wrote:
 On Thu, Nov 12, 2009 at 11:25 AM, Jesse Noller jnol...@gmail.com wrote:
 I'd not trust a package without a bug tracker, mailing list or link to
 the source a lot sooner than something without comments and ratings.

 Yeah, but you're not exactly an average user. Most users don't know
 how to use a bug tracker. Also, there's a large variety of packages on
 PyPI. Not every developer has the same attitude, but they all live
 happily together on PyPI. (Or did you want someone to start a separate
 CPAN for the rest of them ? :-)

 True, but if you make entries for them mandatory (bug trackers,
 source, etc), and you encourage users to use them, you begin being to
 be the change you want to be, which is making PyPi *less* of an app
 store where the consumer doesn't collaborate with the authors.

 Or maybe rather than *putting* this stuff into Pypi; pypi allows
 plugins to allow authors to link in RSS feeds to their bug trackers,
 wiki streams, what have you.


IMO plugins could be a little bit complicated because PyPI would need
to be extended, and there's also the problem of installing, upgrading
and maintaining each plugin . OTOH if PyPI relies on a single API
based on open standards (e.g. RPC or something RESTful ;o) then that
would represent less overhead for PyPI maintainers .

Instead of votes + comments I'd prefer a similar user interface but
doing things as follows (feel free to filter things; besides I'll
mention how it should work using Trac XmlRpcPlugin , but should be
similar for other PMS ;o) :

  - Previous comments retrieved from third party site
and shown (e.g. no more than 5 and only most recent shown like TH.org)
as well as a link to navigate to third party site in order to look
for further
issues . (ticket.getAll + ticket.get)
  - Text input would be the description of a ticket (ticket.create)
  - A combobox to select either comment | defect | support (ticket.create)
  - Ratings could be interpreted as a priority or severity ...
(labels = ticket.priority.getAll + ticket.priority.getAll ,
 values for single item = ticket.get )

Implementing all this might require to add more information to the
index (I am not sure) and also config options in the site for package
maintainers, but since it'd be more useful (for me) probable (me and
others) will prefer something like that : *and users won't even notice
the changes*

;o)

Nonetheless plugins approach is more general and flexible, and it is
also possible to develop a plugin to support the RPC-based integration
with external issue trackers . The main difference is maintenance
effort once it's up and running .

;o)

 I think everyone can co exist, just not one at the cost of another ;)


+1 ... keeping relevant data in single place

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A new way to configure logging

[Olemis Lang]

On Wed, Oct 7, 2009 at 11:26 AM, Olemis Lang ole...@gmail.com wrote:
 On Wed, Oct 7, 2009 at 10:49 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
 Olemis Lang olemis at gmail.com writes:

 This kind of problems is similar to the one mentioned in another
 thread about modifying config options after executing commands. In
 that case I mentioned that the same dict-like interface also holds for
 WinReg and so on ...

 So thinking big (yes ! I have a big head ! ) I think that the best
 approach in this case is to build an adaptation (simple) layer on top
 of ConfigParser, JSON, WinReg, PyCode, YAML, ... and build specific
 extensions for these formats . Perhaps the proper interfaces are
 already there (e.g. `dict`, `shelve` ) and I'm just blind and looking
 somewhere else ;o)

 Sorry, you've lost me :-)


 Never mind . I was just trying to say that using `dict`, an adapter
 could be implemented (if not already there ;o) for multiple formats
 like the ones I mentioned above and the solution would cover many
 config formats ... and also I was saying that I was not sure about
 whether this is correct , I mean for *ANY* config formats,

Intention = answer myself + sharing with you = for a better Pyland

Maybe we could learn something from Augeas [1]_ and use their
experience to include some of those features to `stdlib` . It seems to
be an ambitious attempt to put all the pieces in config-land together;
and AFAICS they handle (a lof of) config formats and have an API for
that, and ... CMIIW anyway

.. [1] Augeas
(http://augeas.net/)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [TIP] Possible language summit topic: buildbots

[Olemis Lang]

On Sun, Oct 25, 2009 at 9:13 AM,  exar...@twistedmatrix.com wrote:
 On 12:48 pm, c...@msu.edu wrote:

 [snip]

 The most *exciting* part of pony-build, apart from the always-riveting
 spectacle of titus rediscovering problems that buildbot solved 5 years
 ago,
 is the loose coupling of recording server to the build slaves and build
 reporters.  My plan is to enable a simple and lightweight XML-RPC and/or
 REST-ish interface for querying the recording server from scripts or other
 Web
 sites.  This has Brett aquiver with anticipation, I gather -- no more
 visual
 inspection of buildbot waterfall pages ;)

 BuildBot has an XML-RPC interface.  So Brett can probably do what he wants
 with BuildBot right now.


... but pony-build follows a different model

;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [TIP] Possible language summit topic: buildbots

[Olemis Lang]

On Fri, Oct 30, 2009 at 11:45 AM, C. Titus Brown c...@msu.edu wrote:
 On Fri, Oct 30, 2009 at 11:42:30AM -0500, Olemis Lang wrote:
 On Sun, Oct 25, 2009 at 9:13 AM,  exar...@twistedmatrix.com wrote:
  On 12:48 pm, c...@msu.edu wrote:
 
  [snip]
 
  The most *exciting* part of pony-build, apart from the always-riveting
  spectacle of titus rediscovering problems that buildbot solved 5 years
  ago,
  is the loose coupling of recording server to the build slaves and build
  reporters. ?My plan is to enable a simple and lightweight XML-RPC and/or
  REST-ish interface for querying the recording server from scripts or other
  Web
  sites. ?This has Brett aquiver with anticipation, I gather -- no more
  visual
  inspection of buildbot waterfall pages ;)
 
  BuildBot has an XML-RPC interface. ?So Brett can probably do what he wants
  with BuildBot right now.

 ... but pony-build follows a different model


that was just a brief comment to mention that even if both (buildbot +
pony-build) support RPC, they are not just «the same»  .

 I'd rather not get into discussions of why my vaporware is going to be
 way, way better than anything anyone else could possibly do

+1 ... I'll be the first one that won't follow it since I have no time
for that and my intention was not to suggest that «pb is better than
bb» (but if you follow, please do it in a separate thread ;o)

@exar...@twistedmatrix.com
 But BuildBot exists, is deployed, and can be used now, without waiting.


+1  as I mentioned before I was not talking about eliminating buildbots

 (Sorry, I don't really understand what point you were hoping to make with your
 message, so I just thought I'd follow up in the same style and hope that 
 you'll
 understand my message even if I don't understand yours :).

well, I understand that you don't understand, since I barely
understand that I will never be able to understand myself ... :)

The only thing I can say so far is that if pb is seriously considered
as an option ... then I could give a hand (... and I'll possibly do it
anyway , once I have time :-/ )

... turning myself off ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Where is `ctypes.com` ?

[Olemis Lang]

Hello !

Recently I found a code snippet [1]_ illustrating integration between
Python and COM technology in Win32 systems. I tried to reproduce it
and I can't import module `ctypes.com`.

Q:

  - Is it (`ctypes.com`) distributed with stdlib ?

If that's true then I'm affraid that those py files were removed
somehow (accidentally ? who knows ? ) ...

Thnx in advance !

.. [1] ctypes.win32.com.server @ Py

(http://svn.python.org/projects/ctypes/tags/release_0_6_2/ctypes/win32/com/server.py)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
[visualization-api] ANN: TracGViz 1.3.4 released: msg#00244 ...  -
http://feedproxy.google.com/~r/TracGViz-full/~3/OBfKGS_sy2E/msg00244.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Where is `ctypes.com` ?

[Olemis Lang]

On Wed, Oct 28, 2009 at 4:39 PM, Thomas Heller thel...@ctypes.org wrote:
 Olemis Lang schrieb:
 Hello !

 Recently I found a code snippet [1]_ illustrating integration between
 Python and COM technology in Win32 systems. I tried to reproduce it
 and I can't import module `ctypes.com`.

 First, the python-dev mailing list is used for developing the Python language
 itself, not developing WITH Python.  For questions about developing with 
 Python,
 please use the newsgroup comp.lang.python.


I apologize if needed ... but I didn't ask about «how to program
things using `ctypes.com` ». I asked here because you are the ones who
should know about modules in stdlib . That's why I thought that it was
not «very» OT

 Q:

   - Is it (`ctypes.com`) distributed with stdlib ?

 If that's true then I'm affraid that those py files were removed
 somehow (accidentally ? who knows ? ) ...

 ctypes.com is very old and has been superseeded by the comtypes
 package: http://starship.python.net/crew/theller/comtypes/


Thnx !

 An even more popular package for using COM with python is
 pywin32: http://sourceforge.net/projects/pywin32/


Yes, I've just tried that one, but the fact is that I'm experiencing a
problem with it (that I won't detail in here because this is not the
list to talk about such subjects , isn't it ? ... just learning fast
... :P ) and I thought I could switch to that one ...

Thnx very much for your reply !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Suggestions: Wave (private) Groups, integration - Google Wave API ...
- http://feedproxy.google.com/~r/TracGViz-full/~3/cuwdwGkX1WA/90bf35ca0c38caf0
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A new way to configure logging

[Olemis Lang]

On Thu, Oct 8, 2009 at 2:44 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 On approximately 10/7/2009 10:45 PM, came the following characters from the
 keyboard of Vinay Sajip:

 Glenn Linderman v+python at g.nevcal.com writes:

 But DictConfigurator the name seems misleading... like you are
 configuring how dicts work, rather than how logs work.  Maybe with more
 context this is not a problem, but if it is a standalone class, it is
 confusing what it does, by name alone.

 Of course the fully qualified name would be
 logging.config.DictConfigurator
 which does provide the requisite context, but if I think of/someone
 suggests a
 better name I'll certainly use it.

[...]

 In thinking more about this, I guess I would have the same comment about the
 existing fileConfig() API also... it isn't file that is being configured,
 but the logs.  readConfigFromFile would have been more descriptive (and lots
 longer :( ).


cfgFromIni | cfgFromFile ? I prefer the former because YAML, shelves,
JSON  Co can also be stored in a file , so at least I get a better
understanding of the format in use. Otherwise I'd had to read the docs
or figure out which one

 Had fileConfig been called bulkConfig or configAll (these names attempt
 to contrast the function of this API versus the individual APIs that
 configure one thing at a time) taking a file parameter, then it could just
 simply/suddenly also allow a dict parameter, and no new API would have to be
 created.  Too late for this, however, and with the new API, it would be
 possible to deprecate the fileConfig API, and tell the user to use the
 ConfigParser (or JSON or YAML or whatever) to create the dict, and then pass
 that to DictConfigurator (or bulkConfig or whatever).


similar and consistent with what I mentioned before but IMO fileConfig
should remain for backwards compatibility

Objections ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Looking for a technique to create flexible, graphical dashboards ...
- http://feedproxy.google.com/~r/TracGViz-full/~3/71kRhT34BgU/43789
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A new way to configure logging

[Olemis Lang]

On Wed, Oct 7, 2009 at 9:49 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
 At present, configuration of Python's logging package can be done in one of 
 two
 ways:

 1. Create a ConfigParser-readable configuration file and use
 logging.config.fileConfig() to read and implement the configuration therein.
 2. Use the logging API to programmatically configure logging using 
 getLogger(),
 addHandler() etc.

[...]

Wow ! Great explanation !
;o)


 All three of the contenders for the title of commonly found configuration
 mechanism - JSON, YAML and Python code - will be expressible, in Python, as
 Python dicts.

.INI files too

{
  'section1' :
{'opt11' : 'val1', 'opt12' : 32323},
  'section1' :
{'opt21' : 'val2', 'opt22' : 32323},
  'section1' :
{'opt31' : 'val3', 'opt32' : 32323},
...
}

In fact it seems that this is a typical characteristic of config formats (CMIIW)

 So it seems to make sense to add, to logging.config, a new
 callable bound to dictConfig which will take a single dictionary argument 
 and
 configure logging from that dictionary.


This kind of problems is similar to the one mentioned in another
thread about modifying config options after executing commands. In
that case I mentioned that the same dict-like interface also holds for
WinReg and so on ...

So thinking big (yes ! I have a big head ! ) I think that the best
approach in this case is to build an adaptation (simple) layer on top
of ConfigParser, JSON, WinReg, PyCode, YAML, ... and build specific
extensions for these formats . Perhaps the proper interfaces are
already there (e.g. `dict`, `shelve` ) and I'm just blind and looking
somewhere else ;o)

If `dict` (possibly nested ;o) is enough to represent config files
then the new method should be ok ... IMHO

[...]

 In outline, the scheme I have in mind will look like this, in terms of the new
 public API:

 class DictConfigurator:
    def __init__(self, config): #config is a dict-like object (duck-typed)



        import copy
        self.config = copy.deepcopy(config)

Why ?


    def configure(self):
        #  actually do the configuration here using self.config

 dictConfigClass = DictConfigurator

 def dictConfig(config):
    dictConfigClass(config).configure()

 This allows easy replacement of DictConfigurator with a suitable subclass 
 where
 needed.


extension is cool ... what's the point about adding the new method
instead of using `DictConfigurator` directly ?

 What's the general feeling here about this proposal?


I'm feeling things ... :)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A new way to configure logging

[Olemis Lang]

On Wed, Oct 7, 2009 at 10:49 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
 Olemis Lang olemis at gmail.com writes:

 This kind of problems is similar to the one mentioned in another
 thread about modifying config options after executing commands. In
 that case I mentioned that the same dict-like interface also holds for
 WinReg and so on ...

 So thinking big (yes ! I have a big head ! ) I think that the best
 approach in this case is to build an adaptation (simple) layer on top
 of ConfigParser, JSON, WinReg, PyCode, YAML, ... and build specific
 extensions for these formats . Perhaps the proper interfaces are
 already there (e.g. `dict`, `shelve` ) and I'm just blind and looking
 somewhere else ;o)

 Sorry, you've lost me :-)


Never mind . I was just trying to say that using `dict`, an adapter
could be implemented (if not already there ;o) for multiple formats
like the ones I mentioned above and the solution would cover many
config formats ... and also I was saying that I was not sure about
whether this is correct , I mean for *ANY* config formats, but
definitely will work for many ;o)

         import copy
         self.config = copy.deepcopy(config)

 Why ?

 So I'm free to mutate self.config as I see fit.


why not to let the user do it if he | she thinks so. I mean if
somebody supplies in a temporary mapping that can be written then why
to spend that time cloning the dict ? If the function has
side-effects, well just document it ;o)

 extension is cool ... what's the point about adding the new method
 instead of using `DictConfigurator` directly ?

 When you say the new method, if you mean configure - the pattern is so 
 that
 a subclass can override __init__ and do additional setup before configure() is
 called.


Sorry I was confused. I was talking about `dictConfig` *FUNCTION* (to
be added to logging.config ... isn't it ? ;o). I mean if dictConfig is
sematically equivalent to a simple `dc.configure` why to add such
function ?

PS: Not a big problem anyway ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Looking for a technique to create flexible, graphical dashboards ...
- http://feedproxy.google.com/~r/TracGViz-full/~3/71kRhT34BgU/43789
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A new way to configure logging

[Olemis Lang]

On Wed, Oct 7, 2009 at 11:06 AM, Paul Rudin p...@rudin.co.uk wrote:
 Vinay Sajip vinay_sa...@yahoo.co.uk writes:


 What's the general feeling here about this proposal? All comments and
 suggestions will be gratefully received.


 How about the global logging configuration being available as an object
 supporting the usual dictionary interface? So you could, for example, do
 something like: logging.dictconfig.update(partialconfig)


Seems interesting ... yes ! ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Search for milestone change in change history - Trac Users ...  -
http://feedproxy.google.com/~r/TracGViz-full/~3/Gsj4xLjuCtk/578d40b734e5e753
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] a new setuptools release?

[Olemis Lang]

On Tue, Oct 6, 2009 at 2:16 PM, Guido van Rossum gu...@python.org wrote:
 On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby p...@telecommunity.com wrote:
 At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:

 To put this into a way that makes sense to me: I'm volunteering to keep
 distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and
 keep that as uncontroversial as possible, and get setuptools 0.6 releases
 out to match distribute 0.6 releases as soon as I can.

 That may not be as easy as it sounds; Distribute deleted various things from
 the setuptools tree (e.g. the release.sh script, used for issuing releases)
 and of course it adds other stuff (e.g. stuff to overwrite setuptools).  So
 you'd need to screen the diffs.

 Second, I still intend to move setuptools 0.7 forward at some point, which
 means the patches also need to go to the trunk.

 Dream on.

 If I had the time to co-ordinate and supervise all this, I'd have the time
 to just do it myself.

 I think at this point the community should not be forced wait for you
 to get a new supply of round tuits. The wait has been too long
 already. You can stay on in an advisory role, but I don't think it's
 reasonable to block development or decisions until you have time.


Is it possible to fork `setuptools` somehow ? This way :

  - patches may be built for setuptools 0.7 if it evolves
  - community can continue development in the «new» branch.

all this easy if a DVCS is used ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 6:26 AM, Jens W. Klein j...@bluedynamics.com wrote:
 Am Montag, den 05.10.2009, 13:07 +0200 schrieb Christian Heimes:
 Fredrik Lundh wrote:
 
  Oh, it was just yet another Zope developer behaving like an ass.  Why
  am I not surprised?
 
  On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh fred...@pythonware.com 
  wrote:
  it's reviews like this that makes me wonder if releasing open source is
  a good idea:
 

Peace for the world brothers . Lots of yoga, meditation, tai-chi ...
and tons of FOSS

    no egg - worst seen ever, remove it from pypi or provide an egg
  (jensens, 2009-10-05, 0 points)
 
[...]

 Note-to-self: Never post when
 angry about some $whatever.

e.g. I don't do it either when I'm drunk or thinking about Britney  ;o)

 And as far as I understand PIL is not the
 problem, but the packaging/ setuptools.

well I just mentioned few times before (and J. P. Eby said something
too, many times actually ;o) that setuptools solved a crucial problem
that was unsolved when it was released

 For the records: PIL is a great
 piece of software and I dont want to miss it.


Yes, and the fact is that without setuptools many other wonderful
(commands | libs | frameworks | apps | software) would be in the
darkness. I mention some of them :

  - setuptools `test` command
  - Trac
  - PasteDeploy
  - ... and here fuel is over ... there are a lot believe me ;o)

the small price to pay is that there are a few annoying
implementation details in there ...

 I hope in future we have a packaging-tool solving those problems.


... or OTOH that some time is needed to improve it ;o) but considering
the benefits ...

Besides you could use

{{{
$ easy_install -Z eggs_are_awesome.egg
}}}

and the package will be installed directly in the file system ( modify
.pth + PYTHONPATH if desired ;o).

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 1:21 PM, Jesse Noller jnol...@gmail.com wrote:
 On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum gu...@python.org wrote:

[...]

 User ratings and comments are the
 future for app store style sites such as PyPI, and spam
 unfortunately comes with the terrain. There are plenty of things we
 can learn about fighting spam and other forms of vandalism from other
 areas of the social web, including our very own wiki, and other wikis
 (WikiPedia survives despite spam).


 I agree that feedback, commentary/etc is a Good Thing; but doing it
 right is not an easy thing, and typically implementing it poorly leads
 to spam, people filing bugs in comments, astroturfing, etc. Just on
 first glance, I could see immediate improvements around:

 * Moderation
[...]
 * Flagging as spam

* Captcha ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 4:06 PM, Fred Drake fdr...@gmail.com wrote:
 On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
 When it comes to comments and recommendations for selecting software
 packages, developers *are* the end users :)

 Yes, most certainly.  But developers as consumers are very different
 from application users as consumers, which is what I was getting at.

 The convenience interfaces for commenting on a library are far less
 valuable for developers, IMO, since developers are expected to better
 understand how their context impacts their perception.  Useful
 feedback from a developer just doesn't fit will into the
 giant-pile-of-comments UIs conventional for non-developers.


+1

IMO :

  - decision matrix are useful to decide which lib to use (i.e. which
one supports the features I need ;o). BTW that's something cool about
wikipedia ;o)
  - project metrics and build results are useful to have a idea
of project dev status (e.g. coverage, test results, ...).
  - the rest goes to issue tracker + project (sites | wikis). that's what
they are for ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 4:23 PM, Olemis Lang ole...@gmail.com wrote:
 On Mon, Oct 5, 2009 at 4:06 PM, Fred Drake fdr...@gmail.com wrote:
 On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
 When it comes to comments and recommendations for selecting software
 packages, developers *are* the end users :)

 Yes, most certainly.  But developers as consumers are very different
 from application users as consumers, which is what I was getting at.

 The convenience interfaces for commenting on a library are far less
 valuable for developers, IMO, since developers are expected to better
 understand how their context impacts their perception.  Useful
 feedback from a developer just doesn't fit will into the
 giant-pile-of-comments UIs conventional for non-developers.


 +1

 IMO :

  - decision matrix are useful to decide which lib to use (i.e. which
    one supports the features I need ;o). BTW that's something cool about
    wikipedia ;o)

I mean feature matrix

  - project metrics and build results are useful to have a idea
    of project dev status (e.g. coverage, test results, ...).
  - the rest goes to issue tracker + project (sites | wikis). that's what
    they are for ;o)

 --
 Regards,

 Olemis.

 Blog ES: http://simelo-es.blogspot.com/
 Blog EN: http://simelo-en.blogspot.com/

 Featured article:
 Nabble - Trac Users - Coupling trac and symfony framework  -
 http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html




-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sharing stdlib across python implementations

[Olemis Lang]

On Wed, Sep 30, 2009 at 9:28 AM, Chris Withers ch...@simplistix.co.uk wrote:
 Frank Wierzbicki wrote:

 Talk has started up again on the stdlib-sig list about finding a core
 stdlib + tests that can be shared by all implementations, potentially
 living apart from CPython.

[...]

 if the
 stdlib was actually a set of separate python packages with their own version
 metadata so that packaging tools could manage them, and upgrade them
 independently of python packages when there are bug fixes. If that were the
 case, then pure python packages in the stdlib, of which there are many,
 *really* could be used across python implementations with no changes
 whatsoever...


nice ! That's something I really liked about Python.NET

:)

BTW ... is there something like that for Java ? I mean to use J2[SE]E
classes using CPython ?

This could also be useful to have personalized distributions. I mean,
if I want to implement a Py app that will run in devices with limited
capabilities, and let's say that it only imports `sockets` module (or
a few more ;o), then it will be easier to prepare a subset of stdlib
in order to deploy just what is needed in such devices, and save some
space ;o).

Projects like py2exe or others, could use something like that in order
to extract relevant stdlib (modules | packages) and make them
available to Windows apps distributed as exe files (e.g. Hg )

CMIIW anyway, perhaps I'm just dreaming.

however ...

 The big changes I can see from here would be moving the tests to the
 packages from the central tests directory, and adding a setup.py file or
 some other form of metadata providion for each package. Not that big now
 that I've written it ;-)


In this case I envision the following issues if one setup.py file is
generated for every module or top-level package (... which is
-considering the previous message- how u plan to do it, isn't it ? )

  - the maintenance effort might increase
  - what about dependencies between stdlib modules ?
  - there are many attributes which will take the same values for each
and every
packages (e.g. version info, issue tracker, ...) and some that
will be specific
(e,g, maintainer, author, contact info, dependencies ...)
  - Overhead when a new package is included in stdlib (need to create and
maintain `setup.py` script, and so on ...)

So my $0.02 here are :

  - to have a single `setup.py` file (in the end it's a script, isn't it ? )
  - provide an argument in order to select module(s) to be included
(full stdlib if missing) in source distribution. In general any other
parameterization of the `setup.py` may be just ok, the goal is
to have only one
  - use a mechanism in order to specify config options for specific pkgs
modules, and make it available to the global `setup.py`. For example :
* Specify metadata using top-level fields in modules (e.g. __author__,
   __maintainer__, ...)
* Specify metadata using separate INI files for each target

What d'u think ?

There may be some issues with sdist anyway
:-/

PS: Will those packages be submitted to PyPI too ? I mean if not
sdists, at least meta-data ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Sobrepasa las 300 descargas el módulo dutest  -
http://feedproxy.google.com/~r/simelo-es/~3/U5rff5iTQPI/sobrepasa-las-300-descargas-el-modulo.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sharing stdlib across python implementations

[Olemis Lang]

On Wed, Sep 30, 2009 at 9:43 AM, Antoine Pitrou solip...@pitrou.net wrote:
 Chris Withers chris at simplistix.co.uk writes:

 I'm on on stdlib-sig and I'm afraid I don't have the bandwidth to start
 on it, but I'd just like to throw in (yet again) that it would be great
 if the stdlib was actually a set of separate python packages with their
 own version metadata so that packaging tools could manage them, and
 upgrade them independently of python packages when there are bug fixes.

 This sounds like a bad idea to me. Each Python release is tested and debugged 
 as
 a whole. If you have a lot of possible combinations (module A version 1.1 with
 module B version 1.2, etc.), it becomes impossible for us to ensure proper QA
 for the whole and as a result the quality might become lower, rather than 
 higher.


You are right here !

-1 for splitting the test code and test suite

but I still think it could be a good idea ...

 (of course, if we rigorously enforce APIs and preserve compatibility,

-1

 this might
 not be a real issue; but our compatibility story is a bit irregular, IMHO)


mainly because of this ;o)

But it's still possible to use a parameterized `setup.py` and leave
things just like they are right now.

For instance, I have started something like that has been dome by the
FLiOOPS  project [1]_ (and possibly others, it's just an example ;o).
In the SVN repository there's a single trunk containing the whole
PyOOP package (which is not complete BTW). Inside of it there are
separate `setup.py` files for other distributions too :

  - `PyOOP` (which should contain them all) employs default `setup.py`
  - `dutest` is a single file (there are more in there) under
`oop.utils` package and
 is distributed separately too, so you can find in there `setup_dutest.py`
 script. All other packages rely on it to build test suites ;o)
  - CASPy (Comprehensive Assertion Support for Python) should be distributed
separately too, so it should have its own `setup_dbc.py` script
once it's ready.

When I create (SVN) tags for each package, I have to rename it
(extra-overhead), and I once global metadata changes, then I have to
change them all

PS: Another alternative for stdlib could be to have common data in
`setup.cfg` and separate `setup.py` scripts, but I don't really like
this one ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Sobrepasa las 300 descargas el módulo dutest  -
http://feedproxy.google.com/~r/simelo-es/~3/U5rff5iTQPI/sobrepasa-las-300-descargas-el-modulo.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] sharing stdlib across python implementations

[Olemis Lang]

On Wed, Sep 30, 2009 at 10:37 AM, Olemis Lang ole...@gmail.com wrote:
 On Wed, Sep 30, 2009 at 9:43 AM, Antoine Pitrou solip...@pitrou.net wrote:
 Chris Withers chris at simplistix.co.uk writes:

[...]

 For instance, I have started something like that has been dome by the
 FLiOOPS  project [1]_

Sorry for the missing reference and typos, should be

For instance, something like that has been done by the FLiOOPS  project [1]_

.. [1] py trunk @ FLiOOPS @ sf.net
(http://sourceforge.net/apps/trac/flioops/browser/py/trunk)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Sobrepasa las 300 descargas el módulo dutest  -
http://feedproxy.google.com/~r/simelo-es/~3/U5rff5iTQPI/sobrepasa-las-300-descargas-el-modulo.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Application configuration (was: PEP 389: argparse)

[Olemis Lang]

On Mon, Sep 28, 2009 at 10:33 AM, Oleg Broytman p...@phd.pp.ru wrote:
 On Mon, Sep 28, 2009 at 09:23:22AM -0600, m h wrote:

 Does anyone else have interest in such functionality?  Is it outside
 the realm of this PEP?

   It is outside the scope of this particular PEP, but it is certainly an
 interesting idea.

:)

   Actually it is the Right Thing, but I doubt it is possible to implement
 such a generic configuration *framework* in the Python standard *library*.
 Applications use different configfile layouts, some programs use w32
 registry instead of configfiles...


If this is the only reason :

Q:
  - What if only INI files are considered ?

In the end, that's the format included in stdlib and used by stdlib
commands (e.g. distutils ;o), and also by others (e.g. Trac, Hg, ...).
Reducing the scope in this direction could yield good results.

OTOH, if other cfg need to be supported, then possibly an «object
layer» (e.g. compatible with ConfigParser) could be used in order to
support further config layouts built outside stdlib. For instance, in
the case of WinReg :

{{{
#!python

RegParser = RegConfigParser(HKEY_CURRENT_USER, r'Software\MyApp\xxx')
RegParser.sections() # Children of this reg key
RegParser.options('s1')  # Values under
   #
HKEY_CURRENT_USER\Software\MyApp\xxx\s1
...
}}}

... and similar solutions could be implemented outside stdlib for e.g. YAML, ...

PS: BTW, is there something like this already for WinReg ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Sobrepasa las 300 descargas el módulo dutest  -
http://feedproxy.google.com/~r/simelo-es/~3/U5rff5iTQPI/sobrepasa-las-300-descargas-el-modulo.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] OT : Cannot login to PyPI using MyOpenId

[Olemis Lang]

I realized that PyPI accepts MyOpenId and tried to login to the site.
In the process I get this message :

{{{
OpenID provider did not provide your email address
}}}

I mean, is it mandatory to provide the e-mail address in order to bind
a user to an OpenId ?
I'm curious : I'd like to know if there's a reason to do that.

Thnx in advance !

PS: I know is a little bit OT. Hope you dont mind ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for Python/Windows

[Olemis Lang]

On Wed, Jul 22, 2009 at 2:43 PM, Martin v. Löwismar...@v.loewis.de wrote:
 My question is the following :

 - What are the implications for Py users ?

 So I stick with what you said is your question: What are the
 implications for Py users ?

 To this, the answer is mostly: none at all. There may be vague indirect
 effects (such as more Python software being available on Windows),


Well this being said, it seems to be cool.

 - What are the implications for other devs (not core ;o) who use to
 download sources and try new things, or perhaps use Py code the way
 they want to solve an specific issue, or modify it somehow to
 experiment or learn something, or whatever ?

 They can now get tools for free that they previously had to buy.


Well it seems that this applies to core devs and I was talking about
people not being Py core devs. But anyway, if everybody can still
compile Py sources without worrying about further licensing
side-effects (i.e. more than we have today ;) then the storm is gone.

 - Will that affect contributions from «future or potential» devs ?

 This is an indirect effect; I doubt there is any noticable change
 (in particular as VS Express is free (as in beer) already).


Well my concern (and what I didnt understand) was that if some
people, in this case core devs, (need | like to have) the
license to do (use)  something they cannot do (use) without the
license then (possibly) everybody else (i.e. those
not having the license) trying to reproduce what others did (e.g.
compilation) had to purchase the license.

If this is not the case, and non-core devs can do what they do the
way they do it so far, then the storm is over ...

 - Will they also need an MS license to see or compile (or whatever)
 the changes contributed by Py devs ?

 Not more than currently already, no.

... and it seems that's the case ;o)

 You may not be aware that Python
 is *already* compiled by MSVC on Windows.


Yes I am, but since I'm a frustrated lawyer I didnt understand a few
things (and I couldnt sleep yesterday because of that ... XD ...)

 I apologize in advance if I'm being rude or naïve or *

 I didn't consider your message rude. It is perhaps naïve (apparently
 ignoring the status quo), but you don't have to apologize for that.


Well I wanted to avoid flamewars or unnecessary disputes or whatever
(you know, this licensing and FOSS vs proprietary debates may be
complicated and sometimes people get excited /me included, of course :
I'm human ;o)

Thnx !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for Python/Windows

[Olemis Lang]

Hi !

On Tue, Jul 21, 2009 at 5:32 PM, Steve Holdenst...@holdenweb.com wrote:
 Christian Heimes wrote:
 Steve Holden wrote:
 Devs:

 If you are interested in offering better Windows support then please
 read the email below

 [...]

 MSDN subscriptions include copies of most Microsoft products (including 
 Office and Exchange) for use while developing and testing software.  For 
 more details, check here - we provide Visual Studio Pro with MSDN Premium 
 under this program 
 (http://msdn.microsoft.com/en-us/subscriptions/subscriptionschart.aspx).

 Thanks you for getting in touch with Microsoft. The deal is worth a
 fortune for any Windows developer!

 Does the MSDN subscription also include the permission to create and
 release binaries?
[...]
 Can you
 please verify that we are allowed to use the subscription for that
 purpose, too?

 I'll ask. I don't see why not (it would hardly be in Microsoft's
 interest to help us create unreleasable open source projects, would it?)


When talking about MS + FOSS everything is possible :-/

My question is the following :

- What are the implications for Py users ?

I mean, even if somebody (not me but enterprises  organizations I
work or may work for in the future ;o) decides to use Windows pay for
that and everything else, I'd not like to qualify as a pirate (or
alike) for using a Py distribution or app including MS Intelectual
Property (MSIP) (and MS loves MSIP -even if nobody can see it- and all
kind of legal issues, especially with FOSS) nor even have Py in the
middle of a patent dispute or something ...

And they have some great innovations [1]_ to ensure (sometimes, I
know) that (some) apps (who decides ?) wont run on a Win host. I could
mention a lot of snippets in that text (yes it's very interesting
and substantial, and useful ) here goes one of them :

{{{
According to another aspect of the invention, the digest catalog
includes, for each program file corresponding to an application or
driver that should be executable by the computer, a digitally signed
hash value that is generated from a hash function based on the
corresponding program file. When attempting to load a particular file,
the loader generates a hash value and compares it to the decrypted
hash values in the digest catalog. If the comparison results in no
matches, then the corresponding program file (and thus the application
or driver) is not loaded.
}}}

OTOH :

- What are the implications for other devs (not core ;o) who use to
download sources and try new things, or perhaps use Py code the way
they want to solve an specific issue, or modify it somehow to
experiment or learn something, or whatever ?
- Will that affect contributions from «future or potential» devs ?
- Will they also need an MS license to see or compile (or whatever)
the changes contributed by Py devs ?
- What about if for some reason, a idea or impl or alg or snippet (or
whatever) is propagated to GNU/Linux distributions and it's MSIP?
(considering former disputes like «Linux kernel violates 42 of MS
patents») ?


.. [1] Restricted software and hardware usage on a computer
(http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=7,536,726)

PD: My question is not technical at all but at least for me is
important (even if I'm not a lawyer, nor a core Py dev  ;o) since I
manage (and develop ;o) several Py-based apps running on Win hosts in
different locations .

Finally I clearly see that this msg is strongly influenced by my
biases, paranoia, and maybe I'm overreacting ... but I prefer to ask
before things actually happen (and MS has a long history specially
with FOSS + patents + legal affaires).

I apologize in advance if I'm being rude or naïve or *

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package Management - thoughts from the peanut gallery

[Olemis Lang]

2009/4/3 Tarek Ziadé ziade.ta...@gmail.com:
 Guys,

 The tasks discussed so far are:

 - version definition (http://wiki.python.org/moin/DistutilsVersionFight)
 - egg.info standardification (PEP 376)
 - metadata enhancement (rewrite PEP 345)
 - static metadata definition work  (*)

Looks fine ... and very useful ... ;)

 - creation of a network of OS packager people
 - PyPI mirroring (PEP 381)


Wow !

BTW ... I see nothing about removing dist_* commands from distutils ...

Q: Am I wrong or it seems they will remain in stdlib ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package Management - thoughts from the peanut gallery

[Olemis Lang]

On Fri, Apr 3, 2009 at 8:36 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
 On Fri, Apr 3, 2009 at 2:56 PM, Olemis Lang ole...@gmail.com wrote:

 BTW ... I see nothing about removing dist_* commands from distutils ...

 Q: Am I wrong or it seems they will remain in stdlib ?

 This is roughly what Guido was talking about when he said we would
 remove things like bdist_rpm
 from the stdlib : it's too OS-specific for the stdlib to do a good job
 in this area.

 To discuss this plan in details, let's move to Distutils-SIG


understood ... ;)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Package Management - thoughts from the peanut gallery

[Olemis Lang]

On Fri, Apr 3, 2009 at 11:20 AM, Chris Withers ch...@simplistix.co.uk wrote:
 Tarek Ziadé wrote:

 - PyPI mirroring (PEP 381)

 I don't see why PyPI isn't just ported to GAE with an S3 data storage bit
 and be done with it... Offline mirrors for people behind firewalls already
 have solutions out there...


-1 ... IMHO ...

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
No me gustan los templates de Django ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Fri, Mar 27, 2009 at 4:27 PM, Barry Warsaw ba...@python.org wrote:
 On Mar 27, 2009, at 2:27 PM, Eric Smith wrote:
 Olemis Lang wrote:

 I also think the feature should go. If you want functionality that's so
 difficult to provide when you install as a zip file, the answer is not
 to
 make things more complex, but to not install as zip files.

 What about environments like Google App Engine ? I mean, AFAIK using
 ZIP files is the *official* solution to meet some quotas 
 requirements ... CMIIW anyway ...

 I mentioned yesterday (in the language summit) that we really need to get
 all the requirements together before we start any work. I fear that there
 are many hidden requirements (or ones that I'm personally not aware of, at

I remembered another similar use case (which is mentioned in PEP 302
-motivation AFAICR- ) ... what about importing Py modules/pkgs
packaged in .JAR files to be used in Jython ? ... Hm?

I dont think its a good idea so far to remove zip imports | installs
and similar ... at least I'll need further arguments and solutions to
concrete use cases to understand this decision a little bit better...
;)

 least). I don't know gettext well enough give an answer yet.

 The class-based API for gettext takes streams, so resource_stream() would
 work just fine.  I think i18n plugins for Python do not necessarily need to
 use the classic gettext API.


In fact ... I use Babel (... especially Translations  Locale classes
;) quite often ... :P

Besides web frameworks and apps also need specific artifacts (e.g.
Genshi template filters for i18n ...) to fully accomplish these tasks
... ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Thu, Mar 26, 2009 at 4:48 PM, Barry Warsaw ba...@python.org wrote:
 On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote:
 On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw ba...@python.org wrote:
 On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:

 One thing that /would/ be helpful though is the ability to list all
 the
 resources under a specific package path.  This is (I think) one use
 case
 that pkg_resource fails to support and it's the one place that I've
 had
 to
 drop down to file system introspection.


 Really ... ? What are all these for ?

 E.g. find all the doctests under foo.bar.docs

 Could you explain this a little more pls ? You mean ... using doctest
 finders in a module (even inside a zip file ;) that's already loaded ?

 Sure ... else I dont understand ...

 Here's a concrete example.  I have a bunch of .sql files inside the
 mailman.database package.  Their file names encode a sort order.  I want to
 load each one in order and apply them to my database.  I'd like to be able
 to find all these .sql files (which are intermixed with .py files in the
 same package) without having to use os.listdir() because that forces the
 package to live on the file system.


Ok ... I will assume the following scenario :

- You have many .py together ... so you distribute them in a
mailman.database package (not module ... but it should be almost the
same thing ...) and provide setup.py for this ... therefore you should
have something like this in the later file

{{{
#!python

try:
from setuptools import setup
except ImportError:
from distutils.core import setup
# Many incredibly useful statements ...

setup(
name='mailman.database',
package_dir = {
'mailman.database' : './db',
},
packages= ['mailman.database'],
package_data={
'mailman.database': ['sql/*', 'messages/es/LC_MESSAGES/*']
},
**many_incredibly_useful_args
)
}}}

- Provided you have done this ... I will assume that u need to execute
such scripts at run-time, and not at install-time ... else setup.py is
more than enough ... ;)

{{{
#!python

from pkg_resources import *

for fnm in sorted(resource_listdir('mailman.database', 'sql'), \
   my_own_cmp ): # Only if needed ... ;)
exec_script(resource_string('mailman.database', 'sql/' + fnm))
}}}

... perhaps your specific example is a little bit more complex than
that ... but the procedure should be similar to the one ci-dessus ...
:)

ResourceManager instances handle all the details involved disregarding
whether the pkg is in a zip file, an egg file or FS ... ;)

CMIIW anyway ... ;)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Thu, Mar 26, 2009 at 6:27 PM, Paul Moore p.f.mo...@gmail.com wrote:
 2009/3/26 Barry Warsaw ba...@python.org:
 Let me clarify my position: I just want the functionality (preferably in the
 stdlib); I don't really care how it's spelled (except please not
 pkg_resource.whatever() :).

 Agreed.

+1

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Fri, Mar 27, 2009 at 7:49 AM, M.-A. Lemburg m...@egenix.com wrote:
 On 2009-03-27 04:19, Guido van Rossum wrote:
 - keep distutils, but start deprecating certain higher-level
 functionality in it (e.g. bdist_rpm)
 - don't try to provide higher-level functionality in the stdlib, but
 instead let third party tools built on top of these core APIs compete

 Should this be read as:

 - remove bdist_rpm from the stdlib and let it live on PyPI

 ?

 Perhaps I just misunderstand the comment.

 I think that esp. the bdist_* commands help developers a lot by
 removing the need to know how to build e.g. RPMs or Windows
 installers and let distutils deal with it.

 The bdist_* commands don't really provide any higher level
 functionality. They only provide interfaces to certain packaging
 formats commonly used on the various platforms.

 Instead of removing such functionality, I think we should add
 more support for standard packaging formats to distutils, e.g.
 bdist_deb, bdist_pkg, etc.


+1 ... for this ...

 And for eggs, there should be a standard bdist_egg, written against
 the core distutils APIs (*), creating archives which other Python
 package managers can then use in whatever way they seem fit.


If not the eggs we have today ... the eggs we may incubate for tomorrow ... XD

 Just please don't tie eggs to one specific package manager,
 e.g. having to install setuptools just to run eggified packages
 is just plain wrong. The format itself doesn't require this and
 neither should the software shipped with those eggs.


... partly, because of this ... ;)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
 2009/3/27 Guido van Rossum gu...@python.org:
 - keep distutils, but start deprecating certain higher-level
 functionality in it (e.g. bdist_rpm)
 - don't try to provide higher-level functionality in the stdlib, but
 instead let third party tools built on top of these core APIs compete

 Please don't move bdist_wininst out of the core, though!

 I'd argue that Windows is a special case, as many Windows users don't
 have the ability to build their own extensions,

H ... what about devs (me?) trying to build installers for
multiple platforms being in a single OS (let's say Ubuntu ...) ? IMO
in this case where policies are unique for a particular OS-flavour
(deb, rpms, and so on ...) ... there should be a single way to package
your app and to conform to the standards agreed by distros (e.g.
Debian) and maintainers ... isnt it enough std to be in stdlib ? I'd
really like to have those (... at least the most influential systems
... rpm, debs, and maybe two or three more that I'm missing here ...)

Indeed I'd like to know the arguments behind «deprecating certain
higher-level functionality in it (e.g. bdist_rpm)» BTW ... perhaps
they'r self-explanatory and therefore I should not be asking this at
all ... :P

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Fri, Mar 27, 2009 at 1:21 PM, Eric Smith e...@trueblade.com wrote:
 M.-A. Lemburg wrote:
 On 2009-03-27 17:07, P.J. Eby wrote:
 At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:

 P.J. Eby wrote:

 As someone else suggested, moving some of the functionality to PEP 302
 interfaces would also help.  Most of the code, though, deals with
 locating/inspecting installed distributions, resolving version
 requirements, and managing sys.path.  And most of the nastiest
 complexity comes from trying to support true filename access to
 resources -- if that were dropped from the stdlib, there'd be no need
 for egg caches and the like, along with all the complexity entailed.

 Application environments such as Chandler, Trac, Zope, etc. that want
 their plugins to live in .egg files wouldn't necessarily be able to use
 such an API, but the independent pkg_resources wouldn't be
 disappearing.  (Of course, they could also implement
 application-specific file extraction, if the stdlib API included the
 ability to inspect and open zipped resources.)

 Could you comment on why they couldn't use such an API?

 If a plugin includes C code (.so/.dll), or uses a library that operates
 on filenames rather than bytes in memory (e.g. gettext), then the
 resources would need to be extracted from the .egg.  pkg_resources
 transparently extracts such resources to a cache directory when you ask
 for a resource's filename, rather than asking for a stream or string of
 its contents.

 This feature represents a significant chunk of the complexity and code
 size of pkg_resources --

 The solution to this is simple: don't use ZIP files for installed
 packages, instead unzip them into normal directories on sys.path.

 Zip files are great for shipping packages to the end-user, but
 there's no need to keep them zipped once they get there.


 I also think the feature should go. If you want functionality that's so
 difficult to provide when you install as a zip file, the answer is not to
 make things more complex, but to not install as zip files.


What about environments like Google App Engine ? I mean, AFAIK using
ZIP files is the *official* solution to meet some quotas 
requirements ... CMIIW anyway ...

I mean, for example: what if someone writes an app containing
resources like message catalogs for i18n, uploads it to GAE using ZIP
files and still wants to use the MO files (i.e. resources) for
translation (i.e. for anything else ...) ... H ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Fri, Mar 27, 2009 at 2:27 PM, Eric Smith e...@trueblade.com wrote:
 Olemis Lang wrote:

 I also think the feature should go. If you want functionality that's so
 difficult to provide when you install as a zip file, the answer is not to
 make things more complex, but to not install as zip files.


 What about environments like Google App Engine ? I mean, AFAIK using
 ZIP files is the *official* solution to meet some quotas 
 requirements ... CMIIW anyway ...

 I mean, for example: what if someone writes an app containing
 resources like message catalogs for i18n, uploads it to GAE using ZIP
 files and still wants to use the MO files (i.e. resources) for
 translation (i.e. for anything else ...) ... H ?

 I mentioned yesterday (in the language summit) that we really need to get
 all the requirements together before we start any work. I fear that there
 are many hidden requirements (or ones that I'm personally not aware of, at
 least). I don't know gettext well enough give an answer yet.



Perhaps it is not necessary ... i18n was only a motivation to
establish a concrete (... *very real*  *no more choices* ...) use
case. The same could be said like this :

«What if someone writes an app containing many (... *A LOT OF* ...)
resource files, uploads it to GAE using ZIP files, and still wants to
use them for anything he/she wants ... H ?»

;o)

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Fri, Mar 27, 2009 at 2:59 PM, Fred Drake fdr...@acm.org wrote:
 On Mar 27, 2009, at 3:56 PM, Guido van Rossum wrote:

 One of the motivations for deprecating this (and for using this
 specific example) was that Matthias Klose, the Python packager for
 Debian, said he never uses bdist_rpm.

 Given that Debian doesn't use RPMs,

Only if using alien ... but ...

 isn't that expected?


... yes I assume that the best way for building debs is not building
an RPM first so ...

 I'm actually in favor of removing the bdist_* from the standard library, and
 allowing 3rd-party tools to implement whatever they need for the distros.
  But I don't think what you're presenting there supports it.


I agree ...


BTW ... bdist_rpm is also there in Windows, and viceversa,
bdist_wininst is also the in FC | RH ... and noione needs that, except
devs willing to build RPMs in order to provide their own installers
... but most of the use cases for distutils bdist_* cmds come from
similar situations ... IMHO ... and the OS of users of a pkg doesnt
match the OS of the devs. The later may even have different OSs
installed ... ;)

I mean, who is gonna use bdist_* if not devs or distro maintainers or
somebody trying to build an installable artifact (... RPM, DEB, MSI,
...) for users having their own OS-flavors ?

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools has divided the Python community

[Olemis Lang]

2009/3/25 Tennessee Leeuwenburg tleeuwenb...@gmail.com:
 I would suggest there may be three use cases for Python installation tools.
 Bonus -- I'm not a web developer! :)
 Case One: Developer wishing to install additional functionality into the
 system Python interpreter forever
 Case Two: Developer wishing to install additional functionality into the
 system Python interpreter for a specific task
 Case Three: Person wanting to install an application which happens to be
 written in Python

If none of these includes managing packages (... similar to apt, yum,
and equivalent ;) pls include it ... and I mean it from a higher level
of abstraction; i.e. disregarding the nature of the «thing» (pkg, mdl,
web framew, plugin, console app, GUI, sci-tool, and so on ... made
with Py ;)

 The prime limitation of setuptools appears to me to come when there are
 conflicts.

IMO the prime limitation of setuptools (for installing pkgs ... and so
on ..) appears to me when I want to control what I've installed (... a
broader situation, i.e. it includes the specific case when there are
conflicts ... and many others ... like removal, etc ... ).

 For issues
 where there are conflicts, where I have been sufficiently motivated, setting
 up a virtualenv has more than met my needs.

I dont think this should be *THE* option ...

 In fact, that's and *awesome*
 piece of functionality.

But shouldnt be the only one ... not everybody (... devs  users ...)
will be open to setup a virtual env in order to install a Py app ...
even myself ... I'd do it if I really need it ... else it is just
painful and non-sense to force me to do it ... and I dont think it'd
be right either ...

 For case one, where I want to install additional functionality into my
 system Python interpreter forever, it would be great to have my system
 manage this. On my ubuntu machine, this happens. The Ubuntu packages take
 care of things very satisfactorily and I don't see how anyone would have a
 problem with it.

Well I do ... my example is as follows (... it actually happened few
days ago ...) :

- I maintain many Trac instances in many different places ...
- I updated some of them to Trac 0.11.1 ...
- One of these was a host running Ubuntu Hardy ... and AFAIK there are
no official debs for Ubuntu Hardy, including backports ... but only
for Intrepid ;)
- So I removed Trac 0.10 and installed Trac 0.11, this time using
setup.py since I didnt have stdeb (... or equivalent ;) at hand ...
- Few months later there was a problem with that server ...
- Since I'm used to use apt+dpkg I didnt find Trac among the list of
installed soft and I completely forgot about all the previous steps
(... believe me my memory sucjks ... :S ...), I though Trac was
removed and I installed trac 0.10 once again from a local repo ...
- Results ... conflicts everywehere and time spent in finding out what
was wrong ... Besides I hosted multiple Trac instances in that single
machine (... that's why I package plugins as egg files ... most of the
time I face this situation, and I always try to do it as portable as
possible to decrease maintainance effort ... ;)
- ... and the solution was to remove trac (pkg  egg) folder, and this
is ugly (... at least these days in XXI century ... and me thinking in
taking control over the whole Emperor Vader's fleet ... I want all
their spaceships and vessels ... ;) but ... what if the installation
includes some other files placed somewhere else ... they remain there
and they'r useless ... and you possibly wont ever know they'r still
there ... if you dont use apt or similar ... ;)

 Perhaps an automated updates site could be configured such that there was a
 package for a variety of Python + some extra modules scenarios.

AFAIK PyPI offers some kwalitee (cheesecake) metrics and this includes
installability ... perhaps these metrics could be extended to consider
whether it is possible or not to automatically build packages for a
particular platform (debs, rpms, win_inst), and ... as a side-effect,
additional service or maybe because of the devs manually uploading the
«platform-specific pkgs» ... include those packages in PyPI ... (no
debs allowed in there ... yet ;)

Perhaps I'm going too far up to this point ... and I'm just dreaming
... but, beyond all these ... perhaps easy_install could just be a
little bit smarter and do things as follows :

1 - Detect the platform of the target host (i.e. the OS | distro in
the «machine» where the app | framework | ... will be installed )
2 - Find out if there is a specific install package for this OS |
distro in PyPI ( ... or the downloads site ...)
3 - Install the specific install package ...
4 - If either 2 or 3 goes wrong ... fall-back to installing the source
distro as usual (... perhaps notifying «the user» of what's going on
and asking him about whether to proceed or not ...)

Doing nothing but this (... and allowing to upload debs to PyPI,
together with including (b|s)dist commands for debs ... in order to
get the 

[Python-Dev] Py plugins architecture - Trac [WAS:] setuptools has divided the Python community

[Olemis Lang]

On Wed, Mar 25, 2009 at 6:08 PM, Barry Warsaw ba...@python.org wrote:
 On Mar 25, 2009, at 11:35 AM, Olemis Lang wrote:

 Yes you're right, Trac requires .egg files for local plugins installs
 (... in /plugins folder ;) so that not all environments but only one
 be able to use the plugin ... but that's not exactly what I'm saying,
 since setuptools AFAIK *MUST* be already there ... so Trac depends on
 setuptools.

 I've not looked at Trac's plugin architecture, but I wonder, how much of it
 is generic enough to be useful for any application?  I've found setuptools
 entry points difficult to work with for plugins, and I think the Python
 ecosystem could benefit from more shared wisdom, if not code, in designing
 plugin frameworks for applications.


Well ... I'm not pretty sure about following this here (py-dev)
however, I'll do my best effort to try to explain a little about it
and provide you some pointers ... ;)

- Trac plugin architecture (... which is a little bit «meta» ...) is
based on a few classes (... and more of them under the hood ... ;)
  1 - Interface ... includes the protocol used to interact with the
specific plugin
  2 - Component ... The base class for implementing the plugin functionality ...
  3 - ComponentManager ... represents something managing many
components | plugins ... (e.g. Trac environments are «represented» as
instances of trac.env.Environment class and it is nothing but a direct
descendant of ComponentManager ... ;).
  4 - ExtensionPoint ... to access all the plugins implenting an
specific interface ...
  5 - A few other «cosmetic» features like Configurable items and
classes (i.e. descriptors ;) to access configuration options ...

In theory people can implement their own descendants of
ComponentManager and do things the way they want to (... at least Noah
K. -trac dev- has mentioned that he has used Trac architecture for
«his own apps» ... and I have, but only for «my own» *web* apps ... I
have no experience about desktop or GUI or other apps ...) ...

It relies on pkg_resources entry points support in order to «load» the
plugins ...

Besides you can read Trac docs for further details ... AFAIK they'll
attend to PyCon'09 ... talks (... hopefully recorded ;) + sprint ...

PS: Edgewall guys have also done a great job in building another great
package for i18n ... and AFAICR it is based on a simpler pluggable
architecture relying on setuptools too ... (... CMIIW anyway ;) I am
talking about Babel ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: setuptools has divided the Python community

[Olemis Lang]

On Thu, Mar 26, 2009 at 1:54 PM, Guido van Rossum gu...@python.org wrote:
 2009/3/26 Toshio Kuratomi a.bad...@gmail.com:
 Guido van Rossum wrote:
 On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
 I think Distutils (and therefore Setuptools) should provide some APIs
 to play with special files (like resources) and to mark them as being 
 special,
 no matter where they end up in the target system.

 Yes, this should be done. PEP 302 has some hooks but they are optional
 and not available for the default case. A simple wrapper to access a
 resource file relative to a given module or package would be easy to
 add. It should probably support four APIs:

 - Open as a binary stream
 - Open as a text stream
 - Get contents as a binary string
 - Get contents as a text string

 Depending on the definition of a resource there's additional
 information that could be needed.  For instance, if resource includes
 message catalogs, then being able to get the base directory that the
 catalogs reside in is needed for passing to gettext.

 Well the whole point is that for certain loaders (e.g. zip files)
 there *is* no base directory. If you do need directories you won't be
 able to use PEP-302 loaders, and you can just use
 os.path.dirname(some_module.__file__).


Oops didnt see this msg ... AFAICR ... this is the kind of reasons
ResourceManager is there for in pkg_resources ... CMIIW anyway ...

However GvR was talking about PEP 302 loaders ... well ... the only
thing I can say is that bundling message catalogs in egg files (they
'r zip files anyway ;) and using them with Babel (... similar to
gettext ... I think ...) works fine for me using the aforementioned
functions in pkg_resources ... About whether PEP 302 loaders should
(look like | implement functions in) pkg_resources.ResourceManager or
not ... I'm not very sure ...

... and I'm talking about ...

{{{
 [x for x in dir(pkg_resources) if 'resource_' in x]
['resource_exists', 'resource_filename', 'resource_isdir',
'resource_listdir', 'resource_stream', 'resource_string']

}}}

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?



-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw ba...@python.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote:

 One thing that /would/ be helpful though is the ability to list all the
 resources under a specific package path.  This is (I think) one use case
 that pkg_resource fails to support and it's the one place that I've had
 to
 drop down to file system introspection.


Really ... ? What are all these for ?

{{{
 [x for x in dir(pkg_resources) if all(y in x for y in ['dir', 'resource_'])]
['resource_isdir', 'resource_listdir']

}}}

--
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Barry Warsaw wrote:
 On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:

 For case one, where I want to install additional functionality into my
 system Python interpreter forever, it would be great to have my
 system
 manage this.

 In fact, I think it /has/ to.  I'll go further and say that I'm very
 wary of using easy_install and the like to install non-distro provided
 packages into the system Python.  Many Linux distros require a
 functioning system Python to operate and the distros (should) take
 great care to make sure that if you install package X for application
 Y, you won't break essential system service Z.  Once you start
 installing your own stuff in the system Python's site-packages, you
 break the warranty.

 Exactly:  I never use easy_isntall to put packages into the system
 python.  in fact, I only use it inside a virtalenv-generated isolated
 environment.



What about the proposal I made about the smarter easy_install ...
isn't that just enough ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setuptools has divided the Python community

[Olemis Lang]

On Thu, Mar 26, 2009 at 2:47 PM, Olemis Lang ole...@gmail.com wrote:
 On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver tsea...@palladion.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Barry Warsaw wrote:
 On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:

 For case one, where I want to install additional functionality into my
 system Python interpreter forever, it would be great to have my
 system
 manage this.

 In fact, I think it /has/ to.  I'll go further and say that I'm very
 wary of using easy_install and the like to install non-distro provided
 packages into the system Python.  Many Linux distros require a
 functioning system Python to operate and the distros (should) take
 great care to make sure that if you install package X for application
 Y, you won't break essential system service Z.  Once you start
 installing your own stuff in the system Python's site-packages, you
 break the warranty.

 Exactly:  I never use easy_isntall to put packages into the system
 python.  in fact, I only use it inside a virtalenv-generated isolated
 environment.



 What about the proposal I made about the smarter easy_install ...
 isn't that just enough ?

 --
 Regards,

 Olemis.

 Blog ES: http://simelo-es.blogspot.com/
 Blog EN: http://simelo-en.blogspot.com/

 Featured article:
 Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?


I apologize but I was sending a few messages before and I didnt post
them to the list ... sorry I'll  do it right now ... sorry if you
receive multiple copies ... :(

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Comandos : Pipe Viewer ... ¿Qué está pasando por esta tubería?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com