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

[Olemis Lang]

On 11/23/14, Mark Shannon  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] 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  wrote:
> 2014-11-28 3:49 GMT+01:00 Nick Coghlan :
>
[...]
>
> 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  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] PEP 479 and asyncio

[Olemis Lang]

On 11/28/14, Guido van Rossum  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 ...


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 .


-- 
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] Automated testing of patches from bugs.python.org

[Olemis Lang]

On 5/19/15, Terry Reedy  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] 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] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8

[Olemis Lang]

On 4/3/13, Charles-François Natali  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] 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  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  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 '' or '' (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. Encaps

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

[Olemis Lang]

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

On 5/20/13, Antoine Pitrou  wrote:
> On Sat, 18 May 2013 23:41:59 -0700
> Raymond Hettinger  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  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  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), "")
>
>
> 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

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  wrote:
>
> On 20 May 2013, at 18:26, Mark Janssen  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  wrote:
[...]
> On 5/20/13, Michael Foord  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] Purpose of Doctests [Was: Best practices for Enum]

[Olemis Lang]

On 5/20/13, Mark Janssen  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] doctest and pickle

[Olemis Lang]

On 6/7/13, Ethan Furman  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] doctest and pickle

[Olemis Lang]

On 6/8/13, Ethan Furman  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.
>


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 .


.. [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] Reduce memory footprint of Python

[Olemis Lang]

On 10/6/13, Benjamin Peterson  wrote:
> 2013/10/6 Victor Stinner :
>> 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 .


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 .


-- 
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 
Date: Sun, 6 Oct 2013 17:09:38 -0500
Subject: Re: [Python-Dev] Reduce memory footprint of Python
To: Benjamin Peterson 

On 10/6/13, Benjamin Peterson  wrote:
> 2013/10/6 Victor Stinner :
>> 2013/10/6 Benjamin Peterson :
>>> 2013/10/6 Victor Stinner :
>>>> 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?
>


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/


-- 
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] Peephole Optimization

[Olemis Lang]

On Thu, Feb 19, 2009 at 8:53 AM, Venkatraman S  wrote:
> Hi,

Hi ...

>
> If there are some optimizations that can be done in the bytecodes, then
> 'where' would be
> the suggested place to incorporate the same;

The way I modify function's bytecode now (... but I am open to further
suggestions ... ;) is writing decorators ... but this is not valid for
more general transformations (AFAICS ...).

-- 
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] "setuptools has divided the Python community"

[Olemis Lang]

On Wed, Mar 25, 2009 at 7:25 AM, Antoine Pitrou  wrote:
> Paul Moore  gmail.com> writes:
>>
>> 3. Setuptools, unfortunately, has divided the Python distribution
>> community quite badly.
>
> Wait a little bit, and it's gonna be even worse, now that buildout and pip 
> seem
> to become popular. For example, the TurboGears people are considering 
> switching
> from setuptools to pip...
>

Yes ... this is certainly true ...

> Tarek is now doing a lot of very useful work on distutils (thanks Tarek!), but
> I'm not sure it'll be enough to stop people from converting to whatever of the
> many build/packaging systems which have been popping up recently.

Sometimes it also happens that, once one such build/packaging systems
is adopted, it is difficult to switch to using another one, since apps
(... and plugins systems ...) are frequently hard-coupled to the pkg
sys «exotic features» and support (... what comes to my mind right now
is Trac plugins which are a little bit dependant on setuptools entry
points and so on ...).

>
>> My (unfounded) suspicion is that the argument
>> was "having to use a separate installer is more complex than just
>> using easy_install" - which is a highly debatable (and frequently
>> debated!) point of view.
>
> I'm not a Windows user, but I suppose it boils down to whether people are
> comfortable with the command-line or not (which even many Windows /developers/
> aren't).

Perhaps there is a little bit more contextual info that I miss ...
however I wanted to say something about this ... I'm not a Windows
user either (... although I do use Windows hosts pretty often for
testing or development purposes ;). In my case I use Ubuntu Hardy and
«Debian-children-or-brothers» ...

At least I see a point in using easy_install since ...

- it is quite easy to install the latest pkgs directly from PyPI ...
- Fresh dependencies are also retrieved from there ...

... but I dont actually use it (... I do use setuptools since apps are
tightly coupled with it ;), what I do is to use distutils exts to
build deb pkgs. Those are the ones that get actually installed in my
PC ... I prefer this way since:

- I avoid the kind of chaos created by easy_install due to the fact
that I cant control and manage my file/pkg associations and inter-pkg
dependencies ... so there are some kind of «dangling» references to
files ... and I dont like that ... I like philosophies like the one
behind dpkg + apt  ...

- I can safely remove the packages formerly installed, including
dependencies and so on ...

... however this means that ...

- Quite often distros only include stable pkgs and sometimes official
debs are not up to date, ... I dont like that ...

- Packaging involves an extra effort ...

I definitely would like to see the day when :

- easy_install allow me to control in detail my installs, pks, deps &
uninsts ... and `--record` is not enought for that ... IMO

- distutils extensions for debs be distributed with core (similar to
rpms | msi ...), however it is possible that some dependency issues be
around ... I know this is a potentially long debate possibly for
distutils SIG ;)

- debs can be uploaded to & distributed in PyPI ... this way it could
be even possible to make easy_install use these debs and try to
install them using the underlying Debian support libs ... in case they
be installed ... and this is nothing but some kind of crazy «random
idea» ...

... and since that day on I think I'll be seriously considering
easy_install as a candidate for my installs, even if there are some
other side-effects while using setuptools ... ;)

> Since having GUIs for everything is part of the Windows philosophy,
> it's a fair expectation that Python libraries come with graphical Windows
> installers.
>

Possibly yes ... in my case, I dont pretty like GUI installers (but I
understand that other people might like them ...) and still I build
them for Py pkgs in Win32 systems, since doing so I can control what's
happenning with them (not as well as with apt + dpkg ... but at least
I can cleanly remove them ;), however I need to handle dependencies by
hand ... :$

Well ... all this is IMO ... and I am not a proficient easy_install
user either, so CMIIW ... ;)

-- 
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] "setuptools has divided the Python community"

[Olemis Lang]

On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé  wrote:
> On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou  wrote:
>> Paul Moore  gmail.com> writes:
>>>
>>> 3. Setuptools, unfortunately, has divided the Python distribution
>>> community quite badly.
>>
>> Wait a little bit, and it's gonna be even worse, now that buildout and pip 
>> seem
>> to become popular. For example, the TurboGears people are considering 
>> switching
>> from setuptools to pip...
>>
>> Combined with
>> the current trend that everything must be exploded into lots of 
>> interdependent
>> but separately packaged libraries (the paste/pylons syndrome... try pulling
>> something like TurboGears2 and see how many third-party packages it 
>> installs), I
>> fear this is going to generate a very painful user/developer experience :-(
>>
>
> I think we are in a point in Python development where we need to clearly 
> define
> how dependencies work.

+1

> And this has to be defined in Python (in Distutils)
> for the sake of standardization.
>

Well, I mentionned I did it using apt + insinstall support ... but I'd
love to have all these things in Python ... with or without relying on
OS-specific infrastructure for managing pkgs, deps and so on ... It is
possible to have two approaches :

- a thin layer on top of OS-specific (dpkg + apt, rpm + yum,
wininstall, mac os ... ) pkg managers so that distutils be able to use
them directly whille still keeping a single model from the end-user
perspective ... At least there exists some kind of python-debian pkg
...

{{{
$ apt-cache show python-debian
Package: python-debian
Priority: optional
Section: universe/devel
Installed-Size: 268
Maintainer: Ubuntu MOTU Developers 
Original-Maintainer: Debian python-debian Maintainers

Architecture: all
Version: 0.1.9
[...]
Depends: python (>= 2.4), python-support (>= 0.7.1)
Recommends: python-apt
[...]
Size: 43662
[...]
Description: python modules to work with Debian-related data formats
 This package provides python modules that abstract many formats of Debian
 related files. Currently handled are:
 * Debtags information (debian_bundle.debtags module)
 * debian/changelog (debian_bundle.changelog module)
 * Packages files, pdiffs (debian_bundle.debian_support module)
 * Control files of single or multple RFC822-style paragraphs, e.g
   debian/control, .changes, .dsc, Packages, Sources, Release, etc.
   (debian_bundle.deb822 module)
 * Raw .deb and .ar files, with (read-only) access to contained
   files and meta-information
[...]
}}}

Since there are a lot such systems (at least for Linux ...) ... this
could also mean that it could be very complex to handle all this
diversity ... However there are a few which are highly influential ...
but this is certainly a concern ...

- A fully fledged implementation from scratch so that distutils be in
charge, all apps be consistent with Py-std ... and users have
potentially two pkg systems (.. the built-in and the Py-specific ;) ;
and I say potentially since it's quite sudden so far and perhaps there
is a way to smoothly integrate both systems (which are potentially
many of them ;)

> I think the Language Summit tomorrow is a good place to discuss about
> these problems,

Hope it be available (recorded ?) some day so as to hear some opinions ... ;)

> and to make sure pip, setuptools and zc.buildout rely on the same
> standards and pieces.
>

Oh yes !
+1

> PEP 376 is my first attempt to make it happen, and my goal is to see another
> pre-PEP coming out of thea language summit, adressing the dependencies 
> problem.
>

;)

> I can't hear that setuptools has divided the Python community.

Said like this ... some might think that setuptools is responsible for
someone else's choices and actions ... and I dont think so ...

> It has provided
> solutions to real problems we had in web development. It's unperfect,
> and it has to be
> fixed and integrated into Python. But it should not be done outside Python 
> imho.
>

I mostly agree with all this, but I would like to know something ...
in case a single pkg management sys be ready for Py (... I mean
integrated into Py ...) and so on ... Why will we need distutils
comands like :

bdist_msi
bdist_wininst
bdist_rpm
<... more «non-standard» candidates like py2exe, stdeb, ...>

? Will all this still be necessary and maintained ? As long as
installing /uninstalling them be handled correctly in built-in as well
as Py systems (considering the duplicate «package repositories» ...)
... I think this could be fine ... but details are details ... ;)

> If you had worked with Zope 5 years ago, you would understand what
> setuptools and
> zc.buildout brought to these communities. And today's experience is a
> whole less painful trust me.
>

Yes ... setuptools has undoubtedly its own value ... :o)

> But I agree that the sizes of the packages are too small now, and it has gone
> to far. Installing a web app like Plone is scary (+100 packages)
>
> But this is the responsability of Zope, TG, etc to distr

Re: [Python-Dev] "setuptools has divided the Python community"

[Olemis Lang]

On Wed, Mar 25, 2009 at 9:31 AM, P.J. Eby  wrote:
> At 08:32 AM 3/25/2009 -0500, Olemis Lang wrote:
>>
>> Sometimes it also happens that, once one such build/packaging systems
>> is adopted, it is difficult to switch to using another one, since apps
>> (... and plugins systems ...) are frequently hard-coupled to the pkg
>> sys «exotic features» and support (... what comes to my mind right now
>> is Trac plugins which are a little bit dependant on setuptools entry
>> points and so on ...).
>
> Please note that entry points are not coupled to easy_install.

Yes u'r right and I know ... perhaps there are better examples to
illustrate what I was saying ... which is that ... distutils
architecture is great since I can code «my own» extension (e.g.
setuptools ;) with «my» potentially non-standard | conflicting
features ... (e.g.  entry points ... AFAIK they'r only de-facto
standards, not in approved final PEPs ;)

Note: ... I'm not saying that I've contributed to setuptools (the «my»
thing ...), it's just a way of talking ... hope you dont mind ... ;)

>  They have a
> documented file format and API that's *distributed* with setuptools, but is
> not dependent on it and does not require .egg files, either.

... but Trac plugins *do require* egg files ... (AFAIK after reading
Trac docs and implementation of plugin upload from /admin/plugins, egg
cache for plugins ... and so on ...) and this is what I was talking
about ... apps (e.g. Trac) depending *today* on setuptools (e.g. egg
files ...) ... not easy_install since, in fact I could install plugins
with apt (... or similar ;) too ... although I always build egg files,
but this is my own decision BTW since I prefer to inherit configs &
plugins for all envs ... but this is a little bit OT here since its
specific to Trac ... ;)

>  There's
> nothing stopping an independent implementation in the stdlib, ala PEP 376's
> metadata API, which is designed to be backward compatible with setuptools.

Of course there is nothing «stopping an independent implementation in
the stdlib [...] designed to be backward compatible with setuptools.»,
but it is still not there ... AFAIK ... and that's what I was talking
about ... considering my example ...

I'd like it in there ... 2 ;)

Like I said I like the idea behind easy_install, but not the «holes» I
mentioned ... but I wanna see filled out ... maybe its just a matter
of time ... :)

>  It could be extended to support entry points as well.
>

... and then Trac plugins (falling-back to my example ;) will rely on
std features ... in a near future ... ok ...

-- 
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] "setuptools has divided the Python community"

[Olemis Lang]

On Wed, Mar 25, 2009 at 11:04 AM, P.J. Eby  wrote:
> At 10:11 AM 3/25/2009 -0500, Olemis Lang wrote:
>>
>> ... but Trac plugins *do require* egg files ... (AFAIK after reading
>> Trac docs and implementation of plugin upload from /admin/plugins, egg
>> cache for plugins ... and so on ...) and this is what I was talking
>> about ... apps (e.g. Trac) depending *today* on setuptools (e.g. egg
>> files ...)
>
> Trac uses entry points to access plugins.  Those plugins do not require .egg
> files, unless Trac specifically wrote code of their own that requires .egg
> files.
>

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.

> If you install a plugin from source using pip

Like you said setuptools is already there ... pip depends on
setuptools ... isn't it?

> or a system package manager,
> no .egg file is involved -- you'll have an .egg-info directory instead,
> alongside the installed code.  The pkg_resources API for accessing entry
> points works with either .egg files or .egg-info directories.
>

Like I just said setuptools AFAIK *MUST* be there ... isnt it ? Am I
still wrong ?

BTW ... if you (or anyone else ;) suggests me another pkg «like»
setuptools (supporting entry points and so on ...) so that I can try
how to install and use Trac plugins without setuptools + pkg_* in the
middle ... I'll be open to try it out ... and learn a little ;)

PS: Sorry if I insist «too much» ... BTW I am not very sure about
whether this getting a little bit OT or not ... hope this isnt the
case ... but if it is, pls let me know ASAP ... ;)

-- 
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] "setuptools has divided the Python community"

[Olemis Lang]

2009/3/25 Tennessee Leeuwenburg :
> 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

[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  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  wrote:
> 2009/3/26 Toshio Kuratomi :
>> Guido van Rossum wrote:
>>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé  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(.__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  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  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  wrote:
> On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver  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

[Python-Dev] "setuptools has divided the Python community"

[Olemis Lang]

On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé  wrote:
> On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou  wrote:
>> Paul Moore  gmail.com> writes:
>>>
>>> 3. Setuptools, unfortunately, has divided the Python distribution
>>> community quite badly.
>>
>> Wait a little bit, and it's gonna be even worse, now that buildout and pip 
>> seem
>> to become popular. For example, the TurboGears people are considering 
>> switching
>> from setuptools to pip...
>>
>> Combined with
>> the current trend that everything must be exploded into lots of 
>> interdependent
>> but separately packaged libraries (the paste/pylons syndrome... try pulling
>> something like TurboGears2 and see how many third-party packages it 
>> installs), I
>> fear this is going to generate a very painful user/developer experience :-(
>>
>
> I think we are in a point in Python development where we need to clearly 
> define
> how dependencies work.

+1

> And this has to be defined in Python (in Distutils)
> for the sake of standardization.
>

Well, I mentionned I did it using apt + insinstall support ... but I'd
love to have all these things in Python ... with or without relying on
OS-specific infrastructure for managing pkgs, deps and so on ... It is
possible to have two approaches :

- a thin layer on top of OS-specific (dpkg + apt, rpm + yum,
wininstall, mac os ... ) pkg managers so that distutils be able to use
them directly whille still keeping a single model from the end-user
perspective ... At least there exists some kind of python-debian pkg
...

{{{
$ apt-cache show python-debian
Package: python-debian
Priority: optional
Section: universe/devel
Installed-Size: 268
Maintainer: Ubuntu MOTU Developers 
Original-Maintainer: Debian python-debian Maintainers

Architecture: all
Version: 0.1.9
[...]
Depends: python (>= 2.4), python-support (>= 0.7.1)
Recommends: python-apt
[...]
Size: 43662
[...]
Description: python modules to work with Debian-related data formats
 This package provides python modules that abstract many formats of Debian
 related files. Currently handled are:
 * Debtags information (debian_bundle.debtags module)
 * debian/changelog (debian_bundle.changelog module)
 * Packages files, pdiffs (debian_bundle.debian_support module)
 * Control files of single or multple RFC822-style paragraphs, e.g
   debian/control, .changes, .dsc, Packages, Sources, Release, etc.
   (debian_bundle.deb822 module)
 * Raw .deb and .ar files, with (read-only) access to contained
   files and meta-information
[...]
}}}

Since there are a lot such systems (at least for Linux ...) ... this
could also mean that it could be very complex to handle all this
diversity ... However there are a few which are highly influential ...
but this is certainly a concern ...

- A fully fledged implementation from scratch so that distutils be in
charge, all apps be consistent with Py-std ... and users have
potentially two pkg systems (.. the built-in and the Py-specific ;) ;
and I say potentially since it's quite sudden so far and perhaps there
is a way to smoothly integrate both systems (which are potentially
many of them ;)

> I think the Language Summit tomorrow is a good place to discuss about
> these problems,

Hope it be available (recorded ?) some day so as to hear some opinions ... ;)

> and to make sure pip, setuptools and zc.buildout rely on the same
> standards and pieces.
>

Oh yes !
+1

> PEP 376 is my first attempt to make it happen, and my goal is to see another
> pre-PEP coming out of thea language summit, adressing the dependencies 
> problem.
>

;)

> I can't hear that setuptools has divided the Python community.

Said like this ... some might think that setuptools is responsible for
someone else's choices and actions ... and I dont think so ...

> It has provided
> solutions to real problems we had in web development. It's unperfect,
> and it has to be
> fixed and integrated into Python. But it should not be done outside Python 
> imho.
>

I mostly agree with all this, but I would like to know something ...
in case a single pkg management sys be ready for Py (... I mean
integrated into Py ...) and so on ... Why will we need distutils
comands like :

bdist_msi
bdist_wininst
bdist_rpm
<... more «non-standard» candidates like py2exe, stdeb, ...>

? Will all this still be necessary and maintained ? As long as
installing /uninstalling them be handled correctly in built-in as well
as Py systems (considering the duplicate «package repositories» ...)
... I think this could be fine ... but details are details ... ;)

> If you had worked with Zope 5 years ago, you would understand what
> setuptools and
> zc.buildout brought to these communities. And today's experience is a
> whole less painful trust me.
>

Yes ... setuptools has undoubtedly its own value ... :o)

> But I agree that the sizes of the packages are too small now, and it has gone
> to far. Installing a web app like Plone is scary (+100 packages)
>
> But this is the responsability of Zope, TG, etc to distr

[Python-Dev] "setuptools has divided the Python community"

[Olemis Lang]

2009/3/26 Toshio Kuratomi :
> Guido van Rossum wrote:
>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé  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.
[...]
>>
>> - 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 ... considering my experience with Babel (... gettext is similar
too ;) & bundling message catalogs (.MO ...) for Trac plugins needing
i18n support (... I even wrote some kind of i18n architecture for Trac
< 0.12 ... ;), pkg_resources handles these cases too ... dont remember
very well right now how but I think it is some knid of

{{{
>>> import pkg_resources
>>> help(pkg_resources.resource_filename)

resource_filename(self, package_or_requirement, resource_name) method
of pkg_resources.ResourceManager instance
   Return a true filesystem path for specified resource
}}}

Don't know whether this is enough or not ... but anyway ... it's
already there, and many people should be using things like this ... Is
it a bad idea to keep it there too ? I mean together with open/get
features mentioned by GvR ...

Q: Will pkg_resources.ResourceManager or equivalent remain ? AFAIK
this is to load resources from multiple sources ... FS, zip | egg
files and so on ... CMIIW ... ;)

--
Regards,

Olemis.

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

Featured article:



-- 
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:52 PM, Barry Warsaw  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> 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 ...

-- 
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:53 PM, Barry Warsaw  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
>
>> {{{
>>>>>
>>>>> [x for x in dir(pkg_resources) if all(y in x for y in ['dir',
>>>>> 'resource_'])]
>>
>> ['resource_isdir', 'resource_listdir']
>
> BTW, under a better name, I would support putting pkg_resources in the
> stdlib.
>

... or a subset of it ? or integrating its features with PEP 302 ? ...
Sounds interesting to me ...

/me thinking aloud

... perhaps unifying these features with loaders in standard PEP 302
is the way ... :-§ ... dont see the point of having an isolated module
for doing what loaders should do ... including that there are plans to
do it already ... thereby duplicating functionality in loaders and
ResourceManager, and so on ...

And'u ? What d'u think ?

-- 
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 3:03 PM,   wrote:
>
>    Tres> Exactly: I never use easy_isntall to put packages into the system
>    Tres> python.  in fact, I only use it inside a virtalenv-generated
>    Tres> isolated environment.
>
> While standing in line for lunch today, someone (don't know his name)
> suggested that easy_install needs an --i-am-an-idiot flag which would have

... since I am feeling like an idiot right now ... perhaps I'd name it
some kind of 
--let-me-do-the-best-i-can-do-for-you-else-i-will-do-it-my-own-way-even-if-it-is-a-pain-in-your-s-since-i-am-not-smart-enought-yet
...

... well ... it is too long ... :-§ ... perhaps it is better this way ...
--lmdtbicdfyeiwdimoweiiiapiyssiansey ... :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 Thu, Mar 26, 2009 at 4:48 PM, Barry Warsaw  wrote:
> On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote:
>> On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw  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  wrote:
> 2009/3/26 Barry Warsaw :
>> 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  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  wrote:
> 2009/3/27 Guido van Rossum :
>> - 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  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  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  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]

On Fri, Mar 27, 2009 at 4:27 PM, Barry Warsaw  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] unittest package

[Olemis Lang]

On Thu, Apr 2, 2009 at 6:07 PM, Barry Warsaw  wrote:
> On Apr 2, 2009, at 4:58 PM, Michael Foord wrote:
>
>> The unittest module is around 1500 lines of code now, and the tests are
>> 3000 lines.
>>
>> It would be much easier to maintain as a package rather than a module.
>> Shall I work on a suggested structure or are there objections in principle?
>
> +1/jfdi :)
>

I remember that something like this was discussed some time ago ...
perhaps the ideas mentionned that time might be valuable ... AFAICR
somebody provided an example ... ;)

+1 for unittest as a package ...

BTW ... Q: Does it means that there will be subpkgs for specific (...
yet standard ...) pkgs ?

If this is the case, and there is a space for a unittest.doctest pkg
(... or whatever ... the name may be different ;) ... and inclusion is
Ok ... and so on ... I wonder ...

Q: Is it possible that dutest module [1]_ be considered ... to live in
stdlib ... ?

The module integrates doctest + unittest ... without needing a plugin
architecture or anything like that, just unittest + doctest... (... in
fact, sometimes I dont really get the idea for having plugins in
testing framews for what can be done following unittest philosophy ...
but anyway ... this is a long OT thread ... and I dont even think to
continue ... was just a brief comment ...)

Classes
=
- DocTestLoader allows to load (using unittest-style) TestCases which
check the match made for doctests. It provides integration with
TestProgram, supports building complex TestSuites in a more natural
way, and eases the use of specialized instances of TestCases built out
of doctest examples.

- A few classes so as to allow reporting the individual results of
each and every interactive example executed during the test run. A
separate entry is created in the corresponding TestResult instance
containing the expected value and the actual result.

- PackageTestLoader class (acting as a decorator ... design pattern ;)
loads all the tests found throughout a package hierarchy using another
loader . The later is used to retrieve the tests found in modules
matching a specified pattern.

- dutest.main is an alias for dutest.VerboseTestProgram. This class
fixes a minor bug (... IMO) I found while specifying different
verbosity levels from the command line to unittest.TestProgram.

These are the classes right now, but some others (e.g.
DocTestScriptLoader ... to load doctests out of test scripts ...)
might be helpful as well ... ;o)

Download from PyPI
===
dutest-0.2.2.win32.exe  MS Windows installer  any 76KB  28
dutest-0.2.2-py2.5.egg  Python Egg  2.5  17KB   93
dutest-0.2.2.zip  Sourceany   13KB
 47

PS: Random thoughts ...

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

.. [2] "Doctest and unittest... now they'll live happily together", O.
Lang (2008) The Python Papers, Volume 3, Issue 1, pp. 31:51
 (http://ojs.pythonpapers.org/index.php/tpp/article/view/56/51)

-- 
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 ...
___
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é :
> 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é  wrote:
> On Fri, Apr 3, 2009 at 2:56 PM, Olemis Lang  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  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] Support for Python/Windows

[Olemis Lang]

Hi !

On Tue, Jul 21, 2009 at 5:32 PM, Steve Holden 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] Support for Python/Windows

[Olemis Lang]

On Wed, Jul 22, 2009 at 2:43 PM, "Martin v. Löwis" 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

[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] Application configuration (was: PEP 389: argparse)

[Olemis Lang]

On Mon, Sep 28, 2009 at 10:33 AM, Oleg Broytman  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

Re: [Python-Dev] sharing stdlib across python implementations

[Olemis Lang]

On Wed, Sep 30, 2009 at 9:28 AM, Chris Withers  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  wrote:
> Chris Withers  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  wrote:
> On Wed, Sep 30, 2009 at 9:43 AM, Antoine Pitrou  wrote:
>> Chris Withers  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] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 6:26 AM, Jens W. Klein  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  
>> > 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  wrote:
> On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum  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  wrote:
> On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan  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  wrote:
> On Mon, Oct 5, 2009 at 4:06 PM, Fred Drake  wrote:
>> On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan  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] a new setuptools release?

[Olemis Lang]

On Tue, Oct 6, 2009 at 2:16 PM, Guido van Rossum  wrote:
> On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby  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] A new way to configure logging

[Olemis Lang]

On Wed, Oct 7, 2009 at 9:49 AM, Vinay Sajip  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  wrote:
> Olemis Lang  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  wrote:
> Vinay Sajip  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 way to configure logging

[Olemis Lang]

On Thu, Oct 8, 2009 at 2:44 AM, Glenn Linderman  wrote:
> On approximately 10/7/2009 10:45 PM, came the following characters from the
> keyboard of Vinay Sajip:
>>
>> Glenn Linderman  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

[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  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] [TIP] Possible language summit topic: buildbots

[Olemis Lang]

On Sun, Oct 25, 2009 at 9:13 AM,   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  wrote:
> On Fri, Oct 30, 2009 at 11:42:30AM -0500, Olemis Lang wrote:
>> On Sun, Oct 25, 2009 at 9:13 AM,   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

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

[Olemis Lang]

On Wed, Oct 7, 2009 at 11:26 AM, Olemis Lang  wrote:
> On Wed, Oct 7, 2009 at 10:49 AM, Vinay Sajip  wrote:
>> Olemis Lang  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] PyPI comments and ratings, *really*?

[Olemis Lang]

On Thu, Nov 12, 2009 at 8:38 AM, Steven D'Aprano  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  wrote:
> On Thu, Nov 12, 2009 at 9:25 AM, 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 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  wrote:
> On Thu, Nov 12, 2009 at 10:30 AM, Terry Reedy  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  wrote:
> On Thu, Nov 12, 2009 at 2:30 PM, Guido van Rossum  wrote:
>> On Thu, Nov 12, 2009 at 11:25 AM, Jesse Noller  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] Unittest/doctest formatting differences in 2.7a1?

[Olemis Lang]

On Wed, Dec 9, 2009 at 11:34 AM, Michael Foord
 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  wrote:
> On Wed, Dec 9, 2009 at 11:34 AM, Michael Foord
>  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 
{{{
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  wrote:
> On Wed, Dec 9, 2009 at 17:43, Fred Drake  wrote:
>> On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson  
>> 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  wrote:
> On Wed, Dec 9, 2009 at 11:23 AM, Lennart Regebro  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() # +python<2.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()
 
... else :
...   throw_an_exception() # +python>=2.7
...
 
}}}

I'd definitely prefer something like that or like what you've
mentioned before (i.e. # +python<2.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] Pronouncement on PEP 389: argparse?

[Olemis Lang]

On Mon, Dec 14, 2009 at 1:43 PM, Steven Bethard
 wrote:
> On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking  wrote:
>> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
>>  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
 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
 wrote:
> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang  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  wrote:
> Steven Bethard wrote:
>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang  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

[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  wrote:
> Steven Bethard  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] Question over splitting unittest into a package

[Olemis Lang]

On Wed, Dec 30, 2009 at 3:04 PM, Benjamin Peterson  wrote:
> 2009/12/30 Martin (gzlist) :
>> 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:
>> 
>>
>>    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

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

[Olemis Lang]

On Thu, Dec 31, 2009 at 10:30 AM, Martin (gzlist)  wrote:
> Thanks for the quick response.
>
> On 30/12/2009, Benjamin Peterson  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:
> 
> 
> 
>

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 Mon, Jan 4, 2010 at 9:24 AM, Olemis Lang  wrote:
> On Thu, Dec 31, 2009 at 10:30 AM, Martin (gzlist)  
> wrote:
>> Thanks for the quick response.
>>
>> On 30/12/2009, Benjamin Peterson  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] Improve open() to support reading file starting with an unicode BOM

[Olemis Lang]

> On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
>  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  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  wrote:
> Olemis Lang wrote:
>>> On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
>>>  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  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] PEP 391 - Please Vote!

[Olemis Lang]

On Thu, Jan 14, 2010 at 4:23 AM, Vinay Sajip  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] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
 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  wrote:
> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>  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  wrote:
> On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang  wrote:
>> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>>  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  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  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  wrote:
> On Tue, Feb 9, 2010 at 12:29, Olemis Lang  wrote:
>>
>> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>>  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  wrote:
> Michael Foord  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  wrote:
> Michael Foord  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] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel  wrote:
> On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney  
> wrote:
>> Michael Foord  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,   wrote:
> On 10:42 pm, fuzzy...@voidspace.org.uk wrote:
>>
>> On 09/02/2010 21:57, Ben Finney wrote:
>>>
>>> Michael Foord  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  wrote:
> Michael Foord  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
 wrote:
> On 10/02/2010 01:07, Ben Finney wrote:
>> Michael Foord  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  wrote:
> On Wed, 10 Feb 2010 09:45:41 -0500, Olemis Lang  wrote:
>> On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel  
>> wrote:
>> > On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney  
>> > wrote:
>> >> Michael Foord  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

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

[Olemis Lang]

On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
 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  wrote:
> On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord
>  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