Re: [Python-Dev] Tweaking the stdlib test infrastructure

[Walter Dörwald]

Collin Winter wrote:
> Fast and simple: I want all stdlib test cases to stop subclassing
> unittest.TestCase and start subclassing test_support.TestCase.
> 
> Why: With a single parent class common to the entire stdlib, adding
> new functionality/testing instruments to *every single test at once*
> becomes trivial. One example would be to move "regrtest -R"'s focus
> from module-level refleaks to test case-level refleaks (that is,
> looped execution of individual test cases, rather than test modules).
> I intend to implement this new refleak checking soon, if this base
> change goes ahead.
> 
> How: At first, test_support.TestCase could be as simple as "TestCase =
> unittest.TestCase". Once we want to extend the test harness's
> capabilities, we change it to "class TestCase(unittest.TestCase): blah
> blah blah". All code under Lib/test/ is changed to subclass the proper
> class. test_support.run_unittest() can be modified to make sure that
> incoming classes inherit as they're supposed to.

+1

> [...]

Servus,
Walter
___
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] Clarifications for import PEPs (302 and 328)

[Paul Moore]

On 24/04/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Not if you read the PEP.  It doesn't explicitly say what should happen.
>
> I want to standardize on raising ImportError.  The PEP itself has two
> ways of signaling an error; find_module() returns None instead of
> raising an error to signal it can't do something while path hooks
> raise ImportError.  I just want to be as explicit as possible.

I'm happy with that. As far as I remember, that was the original
intention - and you're right, it should be made explicit.

Paul.
___
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] Python-Dev Summary Draft (April 1-15, 2007)

[Calvin Spealman]

I have not gotten any replies about this. No comments, suggestions for
not skipping any missed threads, or corrections. Is everyone good with
this or should I give it another day or two?

On 4/22/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> There were a good number of skipped threads, but I've been out of the
> loop with a lot of busy things keeping me away from such things. Now
> that I'm getting back into it, I'll keep up with things again. So, let
> me know if any of the skipped threads should be brought in.
> Corrections and comments welcome as always.
>
> =
> Announcements
> =
>
> =
> Summaries
> =
>
> ---
> About SSL tests
> ---
>
> An open bug about missing SSL tests (#451607) was brought up to close or keep
> open. Jean-Paul Calderone mentioned an improved testing method by spawning a
> 'openssl s_server' for testing purposes. This sparked some talk about the
> terminating of subprocesses in a cross-platform manner (See `Cross-Platform
> Subprocess Termination`).
>
> Contributing thread:
>
> - `About SSL tests
> `__
>
> -
> Cross-Platform Subprocess Termination
> -
>
> Because os.kill only works on *nix and OS X platforms, leaving Windows
> platforms uncovered. Although subprocess.TerminateProcess exists for Windows
> platforms, it requires the use of handles and additional overhead for use.
> Support was overall given for adding a UNIX-only signal() method and a cross-
> platform terminate() method to Popen instances. Nothing was said of actually
> incorporating these changes into the subprocess module, although code was
> given.
>
> Contributing thread:
>
> - (This was mixed in with the `About SSL tests` thread.)
>
> 
> Extended buffer protocol
> 
>
> Updates to the buffer protocol are discussed, along with the proposal pre-PEP
> documenting the updates for Python 3000, but brought to Python-Dev, due so the
> plans of backporting to 2.6 afterwards.
>
> (Note: I couldn't summarize this well enough to cover much of it do any real
> degree, but it is currently a Py3k issue, so maybe that is OK. If no one wants
> to add to the summary, it will stay short.)
>
> Contributing threads:
>
> - `Extended buffer PEP
> `__
> - `PEP 3118: Extended buffer protocol (new version)
> `__
> - `Extended Buffer Protocol - simple use examples
> `__
>
> -
> function for counting items in a sequence
> -
>
> A patch was submitted by Steven Bethard (http://bugs.python.org/1696199),
> implemented a discussed collections.counts() function to provide a mapping
> between items in an iterable and the number of times they appear. There were
> suggested names, but none overthrew the original 'counts()' and a question of
> items not appearing being counted as 0 or raising a KeyError, with 0 winning
> due to a just-makes-sense factor.
>
> Contributing thread:
>
> - `function for counting items in a sequence
> `__
>
> 
> context manager - generator interaction?
> 
>
> A problem was brought up with iterator context managers and iteration inside
> the with-block raising its StopIteration, but being caught by the context
> manager mechanics. It was also responded that the problem would not exist
> without the use of overly broad try blocks, and this lead to the addition of
> a formal note in PEP 8 about keeping narrow try blocks.
>
> Contributing thread:
>
> - `context manager - generator interaction?
> `__
>
> -
> proposed which.py replacement
> -
>
> Suggestion of replacing the which.py script in the Tools directory migrated to
> its proposal for inclusion into the standard library. A patch and tests have
> yet to be provided.
>
> Contributing thread:
>
> - `proposed which.py replacement
> `_
>
> ---
> minidom and DOM level 2
> ---
>
> What is missing for DOM Level 2 support in minidom was highlighted and
> some work jumpstarted.
>
> Contributing thread:
>
> - `minidom and DOM level 2
> `__
>
> --
> test_pty.py hangs in verbose mode on Mac OS X?
> --
>
> Differing buffering beha

Re: [Python-Dev] Tweaking the stdlib test infrastructure

[glyph]

On 12:39 am, [EMAIL PROTECTED] wrote:

Fast and simple: I want all stdlib test cases to stop subclassing
unittest.TestCase and start subclassing test_support.TestCase.



So: any objections to making this change?


Not an objection so much as a question - if these feature additions are 
generally interesting (and the ones you mentioned sounded like they are) 
why not simply add them to unittest.TestCase itself?  After all, that is 
in the stdlib itself already.
___
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] Python-Dev Summary Draft (April 1-15, 2007)

[Talin]

Calvin Spealman wrote:
> I have not gotten any replies about this. No comments, suggestions for
> not skipping any missed threads, or corrections. Is everyone good with
> this or should I give it another day or two?

Part of the issue, for me anyway, is that many of the really 
"interesting" conversations have moved to Python-3000 and Python-ideas.

That being said: There are a few threads in the "skipped" section that I 
would have liked to understand better, without having to read through 
all those messages, such as the various "decimal" threads.

Other than that, the summaries remain very valuable. Thank you :)

-- Talin
___
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] Tweaking the stdlib test infrastructure

[Collin Winter]

On 4/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 12:39 am, [EMAIL PROTECTED] wrote:
> >Fast and simple: I want all stdlib test cases to stop subclassing
> >unittest.TestCase and start subclassing test_support.TestCase.
>
> >So: any objections to making this change?
>
> Not an objection so much as a question - if these feature additions are
> generally interesting (and the ones you mentioned sounded like they are) why
> not simply add them to unittest.TestCase itself?  After all, that is in the
> stdlib itself already.

Because something like per-test refleak checking is completely useless
when testing pure-python code. More generally, because not everything
that will be useful for the stdlib's test suite will be useful to
every single third-party test suite. It's also an issue of support: I
want the freedom to add functionality to the stdlib's test suite
without worrying about the impact on third-party unittest code.

Collin Winter
___
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] Tweaking the stdlib test infrastructure

[glyph]

On 04:36 pm, [EMAIL PROTECTED] wrote:

On 4/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

On 12:39 am, [EMAIL PROTECTED] wrote:
>Fast and simple: I want all stdlib test cases to stop subclassing
>unittest.TestCase and start subclassing test_support.TestCase.

>So: any objections to making this change?

Not an objection so much as a question - if these feature additions 
are
generally interesting (and the ones you mentioned sounded like they 
are) why
not simply add them to unittest.TestCase itself?  After all, that is 
in the

stdlib itself already.


Because something like per-test refleak checking is completely useless
when testing pure-python code.


Not everybody outside the stdlib is using the python unittest module to 
test pure-python code.

More generally, because not everything
that will be useful for the stdlib's test suite will be useful to
every single third-party test suite.


I don't think that every single third-party test suite is using every 
single feature of the existing unittest module either, though.

It's also an issue of support: I
want the freedom to add functionality to the stdlib's test suite
without worrying about the impact on third-party unittest code.


This makes sense to me, and I won't belabor the point.  I just wanted to 
give a gentle reminder that if this functionality is useful to the 
standard library, it's likely that there are other libraries it would be 
useful to.  Not putting it into the supported library right away makes 
sense, but if this functionality does prove useful, please consider 
making it standard.
___
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] Clarifications for import PEPs (302 and 328)

[Brett Cannon]

On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:23 PM 4/23/2007 -0700, Brett Cannon wrote:
> >On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > At 03:16 PM 4/23/2007 -0700, Brett Cannon wrote:
> > > >The PEP does not explicitly state how to signal that a loader cannot
> > > >load a module it is asked to.  This could happen if someone called a
> > > >loader without consulting its respective importer.  I would want to
> > > >add something like:
> > > >"""
> > > >If the loader is unable to load the specified module and a specific
> > > >exception is not raised in determining this, ImportError is raised.
> > > >This may occur if a loader is called without first consulting an
> > > >importer as to if the loader can load the specified module but the
> > > >loader is aware of the fact it cannot fulfill the request made.
> > > >"""
> > >
> > > Okay, now I understand what you're trying to say, but I still don't
> > > understand what the purpose is.  I mean, what else would you do except
> > > raise an error?  I.e., isn't the actual contract "load the specified 
> > > module
> > > or raise an exception of some kind"?
> >
> >Not if you read the PEP.  It doesn't explicitly say what should happen.
> >
> >I want to standardize on raising ImportError.  The PEP itself has two
> >ways of signaling an error; find_module() returns None instead of
> >raising an error to signal it can't do something while path hooks
> >raise ImportError.  I just want to be as explicit as possible.
>
> Ok, so this should at least lose the passive voice ("ImportError is
> raised") -- it should say that it's the loader's job to raise
> ImportError.  Otherwise, it's not actually removing any ambiguity.
>

Yeah, the paragraph was from the cuff.

> I also don't find the "This may occur" sentence to be helpful; it seems we
> should just say, "load_module() must return a loaded module or raise an
> error, preferably an ImportError unless an existing exception is being
> propagated."
>
> Meanwhile, if you also mean to say that load_module() is explicitly allowed
> to fail with an ImportError when it's asked for any module other than the
> one it was obtained for (via find_module()), then let's say that, too.
>

Yes, I do mean that.

> Notice, by the way, that this is a stronger condition than the one you
> proposed, yet it doesn't imply that there is or should be an ongoing
> relationship between the loader and the importer.  It also doesn't imply
> that perhaps it's okay for a loader to not succeed in reloading the *same*
> module!  (i.e., as I understand it, a module can currently invoke
> __loader__.load_module(__name__) as a rough synonym for reload().)

Makes sense.

I will make the changes when I have a working laptop again.  Thanks
for the input, Phillip!

-Brett
___
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] test_pty fails on Sparc Solaris 10 for trunk

[Grig Gheorghiu]

This is happening both in the Python buildbot farm, and in the
community buildbot farm.

See:

http://www.python.org/dev/buildbot/trunk/sparc%20solaris10%20gcc%20trunk/builds/1960/step-test/0
http://www.python.org/dev/buildbot/community/trunk/sparc%20Solaris%2010%20trunk/builds/484/step-test/0

Grig

-- 
http://agiletesting.blogspot.com
___
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] Python-Dev Summary Draft (April 1-15, 2007)

[Brett Cannon]

On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> I have not gotten any replies about this. No comments, suggestions for
> not skipping any missed threads, or corrections. Is everyone good with
> this or should I give it another day or two?
>

Up to you.  Usually if anyone is going to reply without prodding it
happens within a 24 hours (if you send out the draft on the weekend I
tended to wait until Monday evening).

-Brett
___
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] Tweaking the stdlib test infrastructure

[Brett Cannon]

On 4/23/07, Collin Winter <[EMAIL PROTECTED]> wrote:
[SNIP - Adding test.test_support.TestCase]
>
> So: any objections to making this change?

God no!  I am dying for you to write your replacement for unittest and
get it into the stdlib!  I am tired of camelCase method names in all
of my test code.

-Brett
___
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] Python-Dev Summary Draft (April 1-15, 2007)

[Calvin Spealman]

On 4/24/07, Talin <[EMAIL PROTECTED]> wrote:
> Calvin Spealman wrote:
> > I have not gotten any replies about this. No comments, suggestions for
> > not skipping any missed threads, or corrections. Is everyone good with
> > this or should I give it another day or two?
>
> Part of the issue, for me anyway, is that many of the really
> "interesting" conversations have moved to Python-3000 and Python-ideas.
>
> That being said: There are a few threads in the "skipped" section that I
> would have liked to understand better, without having to read through
> all those messages, such as the various "decimal" threads.
>
> Other than that, the summaries remain very valuable. Thank you :)
>
> -- Talin
>

Yes, I plan to solve this by pulling them for summaries, as well. I'm
not sure at the moment if its better to pull them into one summary or
three. I would think one, with all the cross over that happens these
days. Any opinions?

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
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] Python-Dev Summary Draft (April 1-15, 2007)

[Aahz]

On Tue, Apr 24, 2007, Brett Cannon wrote:
> On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
>>
>> I have not gotten any replies about this. No comments, suggestions for
>> not skipping any missed threads, or corrections. Is everyone good with
>> this or should I give it another day or two?
> 
> Up to you.  Usually if anyone is going to reply without prodding it
> happens within a 24 hours (if you send out the draft on the weekend I
> tended to wait until Monday evening).

Actually, my schedule is such that I usually don't read it UNTIL the
weekend, so waiting until the Monday after sending out a draft probably
doesn't hurt.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"...string iteration isn't about treating strings as sequences of strings, 
it's about treating strings as sequences of characters.  The fact that
characters are also strings is the reason we have problems, but characters 
are strings for other good reasons."  --Aahz
___
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] EuroPython 2007 - call for refereed papers

[arigo]

Hi all,

He're a reminder to submit a talk at EuroPython!

Like each year, we have both the regular conference (see call at
http://indico.cern.ch/conferenceCFA.py?confId=13919) and a somewhat
separated Refereed Papers section.  Here is the call for the latter.

The deadline for both is the 18th of May.



   EuroPython 2007
Vilnius, Lithuania  9-11 July

  Call for Refereed Papers

 http://www.europython.org/


EuroPython is the only conference in the Python world that has a
properly prestigious peer-reviewed forum for presenting technical and
scientific papers. Such papers, with advanced and highly innovative
contents, can equally well stem from academic research or industrial
research. We think this is an important function for EuroPython, so we
are even making some grants available to help people with travel costs.

We will be happy to consider papers in subject areas including, but not
necessarily limited to, the following:

* Python language and implementations
* Python modules (in the broadest sense)
* Python extensions
* Interoperation between Python and other languages / subsystems
* Scientific applications of Python
* Python in Education
* Games
* Agile Methodologies and Testing
* Social Skills

We are looking for Python-related scientific and technical papers of
advanced, highly innovative content that present the results of original
research (be it of the academic or "industrial research" kind), with
proper attention to "state of the art" and previous relevant
literature/results (whether such relevant previous literature is itself
directly related to Python or not).

We do not intend to let the specific subject area block a paper's
acceptance, as long as the paper satisfies other requirements:
innovative, Python-related, reflecting original research, with proper
attention to previous literature.

Abstracts
=

Please submit abstracts of no more than 200 words to the refereeing
committee. You can send submissions no later than 18 May 2007. We shall
inform you whether your paper has been selected and announce the
conference schedule on the 25 May 2007. For all details regarding the
submission of abstracts, please see the EuroPython website
(http://www.europython.org). WARNING: Independently of their topic, all
abstracts must be submitted *in the Refereed Papers track* in order to
be considered by the refereeing committee!

If your abstract is accepted, you must submit your corresponding paper
before 29 June 2006. Last-minute changes will be accepted until the start
of the conference. You should submit the paper as a PDF file, in A4
format, complete, "stand-alone", and readable on any standards-compliant
PDF reader (basically, the paper must include all fonts and figures it
uses, rather than using external pointers to them; by default, most
PDF-preparation programs typically produce such valid "stand-alone" PDF
documents). There are no strict typesetting rules.

Refereeing
==

The refereeing committee, selected by Armin Rigo, will examine all
abstracts and papers. The committee may consult external experts as it
deems fit. Referees may suggest or require certain changes and editing
in submissions, and make acceptance conditional on such changes being
performed. We expect all papers to reflect the abstract as approved and
reserve the right, at our discretion, to reject a paper, despite having
accepted the corresponding abstract, if the paper does not substantially
correspond to the approved abstract.

Presentation


The paper must be presented at EuroPython by one or more of the
authors. Presentation time will be between half an hour and an hour,
including time for questions and answers, depending on each paper's
details, and also on the total number of talks approved for
presentation.

Proceedings
===

We will publish the conference's proceedings in purely electronic
form. By presenting a paper, authors agree to give the EuroPython
conference non-exclusive rights to publish the paper in electronic forms
(including, but not limited to, partial and total publication on web
sites and/or such media as CDROM and DVD-ROM), and warrant that the
papers are not infringing on the rights of any third parties. Authors
retain all other intellectual property rights on their submitted
abstracts and papers excepting only this non-exclusive license.

Subsidised travel
=

We have funds available to subsidise travel costs for some presenters
who would otherwise not be able to attend EuroPython. When submitting
your abstract, please indicate if you would need such a subsidy as a
precondition of being able to come and present your paper. (Yes, this
possibility does exist even if you are coming 

[Python-Dev] Summaries and the New Lists

[Calvin Spealman]

Now that I should be able to actually keep up with my summary duties,
I need to figure out how to tackle the changing landscape of the
development lists. The old summaries were no problem, before my time.
When the python-3000 list was created, nearly everything was just
conceptual, floaty talk that didn't have place in the concrete world
of real development conversation in python-dev. The day recently came
when python-3000 got to the point of being "real" enough to warrant a
third list, python-ideas, for real floaty ideas and now conversations
routinely cross all three. Something might be brought up in ideas,
move to 3000 to be solidified, and then to dev to discuss backporting
to 2.6 or so. Obviously, we're missing out on a lot for the summaries.

So, the question I pose is how would everyone like to see this
resolved? As I see it, there are two things I can do. I can either
summaries each list separately, and try to sort out the cross overs.
Or, I can start pulling in all three development lists into all the
summaries. I prefer the second option, but I want to clear with
everyone else. I hope no one has a problem with getting more with the
summaries from now on? If not, I'll begin with the second half of
April.

Along with that, I need to know if my svn rights for submitting the
summaries extends to the actual summary scripts? I'll need to change
them to pull in extra lists. I'm actually thinking lots of projects
could use such a script, so while I'm at it I want to just generalize
it a bit and put it somewhere for anyone else to use, if no one has
issues with that.

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
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] Summaries and the New Lists

[Oleg Broytmann]

On Tue, Apr 24, 2007 at 04:37:14PM -0400, Calvin Spealman wrote:
> So, the question I pose is how would everyone like to see this
> resolved? As I see it, there are two things I can do. I can either
> summaries each list separately, and try to sort out the cross overs.
> Or, I can start pulling in all three development lists into all the
> summaries. I prefer the second option

   I prefer the second, too.

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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] Automatic Scope Macros

[Calvin Spealman]

Could we use and add this macro to object.h? It could be a much
cleaner and safer way of dealing with new references you want to clean
up in the same scope. The first one will make sure to decref your new
reference when you are done with it. The second one will make sure to
set a borrowed reference to NULL afterward, so you can't access it
after you are done with it. The second might be useless, but it seems
like it might be useful for debugging and being sure you stopped using
a reference when you thought you did.

Anyone, please let me know if this is a dumb idea.

/* Obtain a New Reference and clean it up at the end of the scope. */
#define Py_CLEANREF(_refname, _newref, _scopecode)\
(PyObject *) _refname = _newref;\
_scopecode;\
Py_XDECREF(_refname);

/* Obtain a Borrowed Reference and forget about it at the end of the scope. */
#define Py_FORGETREF(_refname, _newref, _scopecode)\
(PyObject *) _refname = _newref;
_scopecode;\
_refname = NULL;

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
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] Summaries and the New Lists

[Steven Bethard]

On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> So, the question I pose is how would everyone like to see this
> resolved? As I see it, there are two things I can do. I can either
> summaries each list separately, and try to sort out the cross overs.
> Or, I can start pulling in all three development lists into all the
> summaries.

I think putting all three into the same summaries is fine.

> Along with that, I need to know if my svn rights for submitting the
> summaries extends to the actual summary scripts?

Feel free to modify those as you see fit -- they were really just my
scripts, so I'd be amazed if changing them bothered anyone else. If
you think you can make them more generally useful, that'd be great.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] Automatic Scope Macros

[Georg Brandl]

Calvin Spealman schrieb:
> Could we use and add this macro to object.h? It could be a much
> cleaner and safer way of dealing with new references you want to clean
> up in the same scope. The first one will make sure to decref your new
> reference when you are done with it. The second one will make sure to
> set a borrowed reference to NULL afterward, so you can't access it
> after you are done with it. The second might be useless, but it seems
> like it might be useful for debugging and being sure you stopped using
> a reference when you thought you did.
> 
> Anyone, please let me know if this is a dumb idea.
> 
> /* Obtain a New Reference and clean it up at the end of the scope. */
> #define Py_CLEANREF(_refname, _newref, _scopecode)\
>   (PyObject *) _refname = _newref;\
>   _scopecode;\
>   Py_XDECREF(_refname);
> 
> /* Obtain a Borrowed Reference and forget about it at the end of the scope. */
> #define Py_FORGETREF(_refname, _newref, _scopecode)\
>   (PyObject *) _refname = _newref;
>   _scopecode;\
>   _refname = NULL;

In most cases, you will have error checking in _scopecode which DECREFs the
variable and returns, or jumps to a "cleanup" label. I can't see how this would
be possible with these macros.

Georg

___
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] Summaries and the New Lists

[Brett Cannon]

On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Now that I should be able to actually keep up with my summary duties,
> I need to figure out how to tackle the changing landscape of the
> development lists. The old summaries were no problem, before my time.
> When the python-3000 list was created, nearly everything was just
> conceptual, floaty talk that didn't have place in the concrete world
> of real development conversation in python-dev. The day recently came
> when python-3000 got to the point of being "real" enough to warrant a
> third list, python-ideas, for real floaty ideas and now conversations
> routinely cross all three. Something might be brought up in ideas,
> move to 3000 to be solidified, and then to dev to discuss backporting
> to 2.6 or so. Obviously, we're missing out on a lot for the summaries.
>
> So, the question I pose is how would everyone like to see this
> resolved? As I see it, there are two things I can do. I can either
> summaries each list separately, and try to sort out the cross overs.
> Or, I can start pulling in all three development lists into all the
> summaries. I prefer the second option, but I want to clear with
> everyone else. I hope no one has a problem with getting more with the
> summaries from now on? If not, I'll begin with the second half of
> April.
>

All in one is fine.  Just be *very* wary of getting burned out.  I
especially would watch out for python-ideas as any random idea can end
up there and just go on and on with no resolution.  I think only
worrying about python-dev is fine, and if you want to pull in
python-3000 that's great.  But I personally consider python-ideas too
wild to worry about summarizing.

-Brett
___
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] Automatic Scope Macros

[Kristján Valur Jónsson]

What you really want is to use C++.
However, that is a brash and immature language that is still awaiting wider 
acceptance
and is therefore not supported.
K

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Georg Brandl
Sent: Tuesday, April 24, 2007 21:00
To: python-dev@python.org
Subject: Re: [Python-Dev] Automatic Scope Macros

Calvin Spealman schrieb:
> Could we use and add this macro to object.h? It could be a much
> cleaner and safer way of dealing with new references you want to clean
> up in the same scope.

In most cases, you will have error checking in _scopecode which DECREFs the
variable and returns, or jumps to a "cleanup" label. I can't see how this would
be possible with these macros.


___
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] Deallocation of a pointer not malloced, any tips?

[Kumar McMillan]

On 4/20/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> You may want the python-list mailing list or the equivalent
> comp.lang.python newsgroup, unless this is a bug with Python itself (you
> may try running Python 2.4.4, which is the next bugfix of the Python 2.4
> series).

yes, seems like it's either a bug in python or the mac os x malloc library.

>
> Regardless, you can help those who want to help you by providing the
> code that you have written that causes the error.  A doubly nested
> try/except isn't all that exciting, so I would guess many would be
> surprised that you are getting double free errors.

again, sorry for being vague.  i tried my best at reproducing it in a
test case but couldn't.  However, I finally experimented with trying
to force deallocation within the block of code and got something that
worked!

Here is a very small portion of it, with the fix, which was putting a
ref to the exc_info vars outside the tries and specifically del'ing
them in the finally block:

def load_or_rescue(self, load):
etype, val, tb = None, None, None
try:
try:
try:
load()
except Exception, exc:
etype, val, tb = sys.exc_info()
if not self.rescue_load((etype, val, tb), exc):
log.critical("EXCEPTION %s while processing %s",
etype, self.ext_event)
raise exc, None, tb
except NonFatalError, e:
self.handle_non_fatal_error(e)
finally:
del etype, val, tb

to put this in perspective a little more, the warning/crash happens
when the code is getting called more or less like this...

def load():
self.start_file(fileobj)
for row in self.file_reader(fileobj):
self.load_or_rescue(lambda: self.load_row(row))
self.load_or_rescue(load)
___
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] gzip Patch

[Florian Festi]

Hi!

I posted patch 1675951 a while ago that fixes a performance problem for 
small reads in the gzip stdlib module. It also removes the necessity for 
seeking while reading gzip files (allows reading from stdin now).

Is there anything I can/have to do to get the patch in?

tia

Florian Festi
___
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] Summaries and the New Lists

[Stephen J. Turnbull]

Brett Cannon writes:

 > All in one is fine.  Just be *very* wary of getting burned out.  I
 > especially would watch out for python-ideas as any random idea can end
 > up there and just go on and on with no resolution.

As basically a lurker, I second that -- these summaries (and the
weekly tracker summary) are great, and anything that keeps the
volunteers happy and healthy is really important.

Similarly, as an irregular reader, I would prefer all-in-one to the
extent that you do summarize more than one list.

However, it would be nice if the thread summaries included a list of
thread subjects occurring on any lists that don't get a verbose
summary.  For example, something automatic based on Subject header
would be fine, any extra checking for topic changes that don't get a
subject change or subject changes that don't correspond to a thread
break is above and beyond the call of the volunteer spirit.  Oh, and
as part of the boilerplate call for comments on the summaries, suggest
that people who care about a particular thread that isn't represented
due to topic-Subject skew to suggest an entry for it (one line maximum).

___
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] gzip Patch

[Kevin Jacobs <[EMAIL PROTECTED]>]

I've tested the patch and it works as advertised for me.

On 4/23/07, Florian Festi <[EMAIL PROTECTED]> wrote:


Hi!

I posted patch 1675951 a while ago that fixes a performance problem for
small reads in the gzip stdlib module. It also removes the necessity for
seeking while reading gzip files (allows reading from stdin now).

Is there anything I can/have to do to get the patch in?

tia

Florian Festi
___
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/jacobs%40bioinformed.com

___
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] Deallocation of a pointer not malloced, any tips?

[Neal Norwitz]

On 4/24/07, Kumar McMillan <[EMAIL PROTECTED]> wrote:
>
> Here is a very small portion of it, with the fix, which was putting a
> ref to the exc_info vars outside the tries and specifically del'ing
> them in the finally block:

Kumar,

Can you create a completely self-contained code example that triggers
the problem and post a bug to Source Forge?
http://sourceforge.net/projects/python

In the bug, please note the operating system version, how long this
takes to trigger, the error message you see and all the steps
necessary to reproduce it.  Attach the code as a file, so we can
download and test our the problem.

Thanks,
n
___
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] gzip Patch

[Martin v. Löwis]

> I posted patch 1675951 a while ago that fixes a performance problem for 
> small reads in the gzip stdlib module. It also removes the necessity for 
> seeking while reading gzip files (allows reading from stdin now).
> 
> Is there anything I can/have to do to get the patch in?

If you want to prioritize processing over other patches, please review
5 other patches, then post the list  of those patches to python-dev,
and I will give your patch priority.

Regards,
Martin
___
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] whitespace normalization

[Neal Norwitz]

I just checked in a whitespace normalization change that was way too
big.  Should this task be automated?

Assuming the answer is yes, these are the questions should be answered:
 1) Which branches should this occur on:  trunk, 2.5 (last release), 3k
 2) Should there be a special user for these checkins
 3) How often should this be done
 4) Are there any other tasks that can be automated

My preferences are:
 1) all active branches (ie, trunk and currently 2.5 and p3yk)
 2) Yes, there should be a special user
 3) Once per week
 4) Not that I know of

The way to fix the files is to run:  python ./Tools/scripts/reindent.py -r Lib
At least that's what I did.  Hopefully I didn't screw anything up. :-)

n
___
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