Re: [Python-Dev] DRAFT: python-dev Summary for 2005-12-16 through 2005-12-31

[Thomas Heller]

Tony Meyer <[EMAIL PROTECTED]> writes:

> --
> Adding zlib module to python25.dll
> --
>
> Thomas Heller and Martin Heller had been discussing whether the zlib

Should be 'Martin v. Löwis', as we all know.

> module should become builtin, at least on Windows (i.e. part of
> python25.dll). This would simplify both the build process and py2exe,
> the latter could then bootstrap extraction from the compressed file
> just with pythonxy.dll, but this is currently not done, because the
> pythoncore.vcproj would then not be buildable anymore unless you also
> have the right version of zlib on disk.  To solve this problem, Thomas
> proposed that the Python release could incorporate a copy of zlib,
> primarily for use on Windows (with the project files appropriately
> adjusted).  This change was later made.
>
> Contributing thread:
>
>  - `Incorporation of zlib sources into Python subversion
> `__

___
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] Ph.D. dissertation ideas?

[Ian Bicking]

Brett Cannon wrote:
> Hmm.  It's an idea.  I also thought of Python -> JavaScript compiler
> since JavaScript is not fun and getting to test using Python might be
> cool.  But not sure how useful that would be.  Plus I bet someone has
> does this with Java or something.

There's a Python project that compiles to Javascript: 
http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_framework

However, I think this is a bad idea.  The world doesn't need another 
compiled language with leaky abstractions that is next to impossible to 
debug.

Anyway, to chime in about something I'd really like to see, that maybe 
fits in somewhere between graphics and language implementation, is the 
ideas of Boxer (http://dewey.soe.berkeley.edu/boxer.html/) implemented 
for Python.  Basically meaning that some of what we represent with 
indentation in Python would be represented graphically (Boxer uses, 
unsurprisingly, boxes).  Also a kind of window in the runtime of the 
system -- variables in Boxer aren't names, but visual elements you can 
see as the program runs.  From what I've seen of HyperCard -- or at 
least what I choose to pay attention to ;) -- I think this kind of 
concrete runtime is part of its appeal.  I have a lot of more specific 
ideas related to this, if the idea interests you.

-- 
Ian Bicking  |  [EMAIL PROTECTED]  |  http://blog.ianbicking.org
___
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] DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15

[Tony Meyer]

Opps.  I just sent out the draft summary for the first half of
December (which might only make it to the list after this one, since
it's very long) but forgot to say anything at the top.

No-doubt everyone knows the pitch by now, but if anyone is able to
take a look at the summary (or parts of it) and send any
comments/suggestions/corrections/additions to either me or Steve, that
would be great.  Responding off-list would be best, to keep noise down
(unless you want to revitalise one of the threads, of course).

As always, thanks to all for your help!  The second half of December
draft should follow tomorrow, and hopefully the first January one next
week.

=Tony.Meyer
___
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 and stdlib

[Nick Coghlan]

Fabien Schwob wrote:
> Hello,
> 
> I've often read new PEP that are published, and they are often about new 
> additions to the core language.  Why not using them with the standard
> library.

PEPs are used to make changes to the Standard Library - there's a bunch of 
them listed in PEP 0. However, a formal PEP is often not required when there 
is no significant dissent on c.l.p or python-dev that requires a BDFL 
pronouncement - in such cases, the relevant module maintainer (or python-dev 
collectively) may just accept the change and check it in. If there's no 
controversy about a change, the overhead involved in making a PEP just isn't 
worth it.

Making changes to the core language (especially syntax changes, but also 
adding or significantly altering builtins) always requires a BDFL 
pronouncement, is almost always controversial, and hence almost always 
involves a full PEP.

(The only syntax change I know of that Guido has approved without a PEP is to 
fix the minor irritation where keyword arguments can't come after a *argument. 
However, even that should probably be made into a full PEP so that some 
potential extensions to define keyword-only arguments and function default 
values can be debated).

> Guido often say that he don't want to include new module that aren't 
> widely used in the community. It's a good thing, but it lead to the 
> creation of a lot of API incompatible modules. Why not using PEP in 
> order to create standard API like the Java world do with JSRs (Java 
> Specification Requests) ?
> 
> What do you think about that ?

Some PEP's are already about exactly such issues - there are a few listed 
under "Other Informational PEP's" in PEP 0.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

[Fredrik Lundh]

Scott David Daniels wrote:

> OK I carried the code I offered earlier in this whole thread (tweaked in
> reaction to some comments) over to comp.lang.python, gathered some
> feedback, and put up a recipe on the cookbook.  After a week or so for
> more comment, I'll be happy to submit a patch to include the broken_test
> decorator function in unittest.
>
> Here is where the recipe is, for those who want to comment further:
>  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288

my main nit is the name: the test isn't broken in itself, and doesn't need
to be fixed; it's just not expected to succeed at this time.

the usual term for this is "expected failure" (sometimes called XFAIL).

for the developer, this means that a failure is not a regression, and is pro-
bably not caused by something that the developer just did.





___
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] pystate.c changes for Python 2.4.2

[Michael Hudson]

Gabriel Becedillas <[EMAIL PROTECTED]> writes:

> Hi,
> At the company I work for, we've embedded Python in C++ application we 
> develop. Since our upgrade to Python 2.4.2 from 2.4.1 we started hitting 
> Py_FatalError("Invalid thread state for this thread") when using debug 
> builds.
> We use both multiple interpreters and thread states.

I know you've said this to me in email already, but I have no idea how
you managed to get this to work with 2.4.1 :)

> I think the problem is that PyThreadState_Delete (which is used when I
> destroy thread states and interpreters) is not making the same clean up
> that PyThreadState_DeleteCurrent is doing (which is used when we create 
> threads from python code). If a thread id is reused (obviously not 
> between two running threads), and the previous thread used 
> PyThreadState_Delete instead of PyThreadState_DeleteCurrent, then an old 
> and invalid value for autoTLSkey is still stored, and that is
> triggering the Py_FatalError when a call to PyThreadState_Swap is made.
> If I add this code at the end of PyThreadState_Delete:
>
> if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate)
>   PyThread_delete_key_value(autoTLSkey);
>
> then everything works fine.

I think I begin to understand the problem... but this is still
fragile: it relies on the fact that you delete a thread state from the
OS level thread that created it, but while a thread belonging to a
different *interpreter state* has the GIL (or at least: the
interpreter state of the thread state being deleted *doesn't* hold the
GIL).  Can you guarantee that?

It seems to me that to be robust, you need a way of saying "delete the
thread local value of autoTLSKey from thread $FOO".  But this is all
very confusing...

> Could you please confirm if this is a bug ?

Yes, I think it's a bug.

Cheers,
mwh

-- 
   Jokes around here tend to get followed by implementations.
-- from Twisted.Quotes
___
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] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

[Nick Coghlan]

Scott David Daniels wrote:
> OK I carried the code I offered earlier in this whole thread (tweaked in
> reaction to some comments) over to comp.lang.python, gathered some
> feedback, and put up a recipe on the cookbook.  After a week or so for
> more comment, I'll be happy to submit a patch to include the broken_test
> decorator function in unittest.
> 
> Here is where the recipe is, for those who want to comment further:
>  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288

Looks pretty handy to me - I've certainly experienced the "I know what the 
problem is and exactly how to provoke it, I just don't have time to fix it 
right now" problem myself.

I added a minor comment about testing for whether there were user supplied 
exceptions at definition time, rather than run time.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries

[Martin v. Löwis]

Crutcher Dunnavant wrote:
> I sorta disagree about it not being broken. Adding a feature which
> works for eval but not for exec seems pretty broken.

You "seem" to have a different notion of "to be broken", then.

Python is broken, if and only if
- the interpreter crashes, for any Python input
- the implementation does not do what the documentation says
  it would do
- the BDFL pronounces it is broken

In this specific change, the change did precisely what the requestor
of the feature wanted it to do (that eval could accept non-exact
dicts was a new feature back then also)

> It's difficult to
> reason about what will happen in the exec context, so I can't see what
> fixing it would endanger; but I'd deffinately like to see it for 2.5.

It would make Python code run which is currently rejected with an
exception. Therefore, it is a new feature (a behaviour change).

Applications relying on that feature would have to specify that
they require "2.4.3"; people would find that code that runs fine
in 2.4.3 fails in 2.4.2. This is not acceptable.

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

Re: [Python-Dev] DRAFT: python-dev Summary for 2005-12-16 through2005-12-31

[Fredrik Lundh]

Tony Meyer wrote:

> Fredrik Lundh kicked off a surprisingly long thread when he proposed
> that typing "quit" or "exit" in the interactive prompt actually exit
> (i.e. raises SystemError)

SystemExit

> >>> def exit():
> ...  print "bye"
>
>>>> # what is it?
> >>> exit
>
> $ oops!
>
> (However, one could simply type "repr(exit)" in this case).

too late:

>>> exit
$ repr(exit)
bash: syntax error near unexpected token `repr(exit)'





___
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] r42015 - peps/trunk

[M.-A. Lemburg]

David Goodger wrote:
> On 1/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> I know, but I wouldn't expect SVN to query other servers
>> than svn.python.org inside the standard repository
>> directories.
>>
>> AFAIK, this is a first in the Python repository.
> 
> True, and worth discussing.  Luckily the PEPs repository is a
> low-traffic, non-core area, so it's not urgent.

True.

>> Not sure if it's such a good idea.
> 
>>From my point of view, it's a time-saver.  No more manual updates!
> They were a pain, and rarely got done.
> 
>> Branching and tagging
>> doesn't work with external resources in Subversion,
>> so things can become inconsistent.
> 
> How so?  The "svn:externals" property is treated the same as any
> other, and is copied along with everything else by "svn copy".

Right, but Subversion doesn't store the revision of the
external resource at the time you made the copy, so
when you checkout the branch or tag, you'll still get
the most recent version of the external resource
which can break things, e.g. say you upgrade docutils
to Python 2.5, then a checkout of a tag built at
a time when Python 2.3 was current would probably
no longer work (with Python 2.3).

At least that's how things were documented the last
time I had a look at svn:externals - could be that they
modified the behavior to make it a little more clever
since.

>> Also, what if you break the code in the berlios repo
>> or the server is not reachable ?
> 
> If the code in the repo ever breaks, it will be fixed within minutes.
> The server being unreachable is only a problem for initial checkouts;
> updates will just keep the code that was already there.  In my
> experience, the berlios.de SVN server has rarely been unreachable.  If
> there's a problem, we can always back out the svn:externals property
> and install the package.
> 
> That having been said, I do see the value of installing a packaged
> release.  We just released Docutils 0.4 a few days ago; I could
> install that statically.  An alternative is to use svn:externals to
> link to a specific revision (via the -r option); I could link to the
> 0.4 release revision.  This would solve the repo-breakage issue, but
> not the server-unreachability issue.

Interesting. Last time I looked these external revisions
were not possible (or I overread the possibility).

> I don't think these issues are major, but I wouldn't mind terribly if
> we decide to go with a static install.

There are two other nits with the external reference:

* connecting to a server that people probably don't
  recognize as being an official Python source and thus
  probably don't trust right away (though this is well
  hidden by subversion, firewall software will alarm the
  user)

* being able to download the complete repository of Python
  with all the history - since the external resource is not
  part of the history, users would have to track down
  the repository of the external resource (and this might
  not be readily available for download)

>> A release copy in the
>> external/ dir would solve all these issues.
> 
> That's basically what we had before (except no explicity "external"
> directory), but it was always out of date.  The "docutils" package was
> directly in the trunk, for ease of import by the pep2html.py front end
> (easy to work around, but why bother?).

I guess that only PSF license covered software should
go into the main directories of the repository. Everything
else should first go in externals/ and then get copied
into the main trunks. It's only one additional step,
but will help a lot in the future if we ever have to
track the copyright status of things in the main
trunks.

This is not an issue for docutils, I guess, since it's
public domain, but then again, there are lawyers who
believe that there's no such thing as public domain...

http://www.linuxjournal.com/article/6225

> Another minor nit with the old way: updates "polluted" the
> python-checkins list.

I guess if you just update to new release versions, then
this will be minimal. I, for one, don't mind at all.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 12 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

[Scott David Daniels]

OK I carried the code I offered earlier in this whole thread (tweaked in
reaction to some comments) over to comp.lang.python, gathered some
feedback, and put up a recipe on the cookbook.  After a week or so for
more comment, I'll be happy to submit a patch to include the broken_test
decorator function in unittest.

Here is where the recipe is, for those who want to comment further:
 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288

--Scott David Daniels
[EMAIL PROTECTED]

___
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] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> What if x64 has a 64-bit value ? How do you catch
>> and process the truncation error ?
> 
> We were *both* discussing a scenario where no sizes
> exceed 2**31, right?

Right, but I don't see the point of each and every
extension having to go through these hoops when you
could add support for these checks (including error
reporting) to the few APIs in question, in particular
the PyArg_ParseTuple() API.

> Under such a scenario, this just won't happen.
> 
> OTOH, if you were discussing a scenario where sizes
> might exceed 2**31, then I don't see why you are worried
> about Py_ssize_t* parameters alone: Even
> 
>   PyString_Size()
> 
> might (of course!) return a value > 2**31 - so it
> is not just output parameters, but also return values.

Indeed - which is why I'm going to convert our tools to
Py_ssize_t throughout.

I don't expect this to happen any time soon for the ten or
twenty other 3rd party extensions we regularly use and this
would prevent an upgrade to Python 2.5.

> For more information, please read "Conversion guidelines"
> in
> 
> http://www.python.org/peps/pep-0353.html

BTW, the open issue should be reworded:

In particular, functions that currently take int* output
parameters should continue to do so. New functions should be
revised to enable Py_ssize_t* output arguments and preseve
backwards compatibility.

(This also includes the strategy to be used, so you can
remove the note on strategy)

Please also add a comment on the fact that extensions
which haven't been recompiled for the Python 2.5 API
will not get imported (the API_LEVEL check should consistently
fail for these instead of just issuing a warning).

>>> That is not necessary. Can you give in example of a module
>>> where you think it is necessary?
>>
>> If you want to port the extension to Py_ssize_t, this
>> is essentially the case.
>>
>> You might want to take the unicodeobject.c file as
>> example.
> 
> unicodeobject.c is not an extension. We were discussing
> existing extension modules.
> 
>> We could use the type flags for these. much like we
>> do for the new style numbers.
> 
> Would you like to write a specification for that?

Sure, if there's hope to get this into the code.

>> If you don't like the macro approach, why not simply
>> leave the two separate sets of APIs visible.
> 
> To simplify the porting.

Sorry, I lost you there:

I'm saying that two sets of APIs (one for int*, one
for Py_ssize_t*) will make porting easier since
updated code will only have to rename the APIs
used. Furthermore, it will allow to write code
that easily works in Python 2.1-2.4 as well as
Python 2.5.

>> All Py_ssize_t aware and compatible extensions
>> would use the new APIs instead. The old-style APIs
>> should then take care of the proper down-casting and
>> error reporting.
> 
> That is not possible. Some API does not support
> error reporting (like PyString_Size()). So callers
> don't expect it to fail.

I'm talking about the few APIs that use output parameters.
Those do support error reporting.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 13 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Ph.D. dissertation ideas?

[Brett Cannon]

On 1/12/06, Dennis Allison <[EMAIL PROTECTED]> wrote:
>
> Brett,
>
> Where are you doing your Phd and who will be your likely supervisor?
> It does make a difference.
>

University of British Columbia under Eric Wohlstadter in the Software
Practices Lab.

> Your dissertation idea list seems to me to focus on implementation
> projects and not on research.  Usually a dissertation proceeds from a
> hypothesis leading to an experiment, some measurements, and conclusions.
> Many universities tacitly expect a theorem and associated proof. The goal
> of dissertation research is a completed approved dissertation, not some
> intergalactic all encompassing contribution to human knowledge.
> Dissertation research should, IMHO, focus on a small, manageable problem.
>

The topics are a little on the implementation side partially from my
personal taste in projects; I have always had a major bent towards the
practical over theoretical (reason I love Python so much  =).  Plus
the lab I am in tends towards the practical and not into the
theoretical (e.g., the number of Eclipse plug-ins being developed as
part of theses and dissertations here).

But I am open for theoretical work (as long as it does not involve
type inference).

> Frequently, universities have a large cooperative project involving many
> graduate students, each of whom research a small, well defined topic areas
> related to the larger project.   Is this the case for your dissertation?
>

Nope.  Nothing going on at the moment here in terms of a large scoped
project with multiple parts to it.

> What are your interests?  Are you interested in language structure,
> language implementation, the formal interface between languages and
> applications, or what.
>

Tough question.  Language design is the over-reaching area that I
love.  Basically how can powerful language ideas be presented in a
easy-to-use fashion.  Could even generalize even farther to just
making programming easier through the language.  And for some reason
networking protocols and concurrent programming have always caught my
eye (have not delved deep into these topics but I always catch myself
doing stuff such as reading the ICMP standard or reading all of the
various arguments for or against threading).

> Like most folks who lurk on this list, I have my list of things I'd like
> to see someone research.  Tell us a bit more and I am sure you'll get lots
> of us to share.
>

That's the hope.  =)

-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] TAR problems under Solaris

[Steve Holden]

Barry Warsaw wrote:
> On Wed, 2006-01-04 at 22:01 +0100, Reinhold Birkenfeld wrote:
> 
>>Recently, someone on dclpy posted about an error he got
>>when he tried to unpack the Python distribution tarball
>>with Sparc Solaris 9's tar:
>>
>>tar: directory checksum error
>>
>>With GNU tar, it worked correctly.
>>
>>Is this a known issue, or is it irrelevant?
> 
> 
> Dunno, but I'm always having problems w/ Solaris tar, so I just use GNU
> tar on Solaris. ;)
> 
Yes. Back in the 1980's Sun's consulting group made good money selling 
an "extended" version of tar (that coped with longer paths than the 
standard version) to customers who could afford it. Guess they never fed 
the changes back into the trunk ...

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

___
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] New PEP: Using ssize_t as the index type

[Martin v. Löwis]

M.-A. Lemburg wrote:
>>Sure. However, most users will compile it on 32-bit
>>systems. If they find they cannot get it to work on
>>a 64-bit system, they should ask the author for help,
>>or just use it in 32-bit mode (as 64-bit mode won't
>>gain them anything, anyway).
> 
> 
> I wonder how you are going to import a 32-bit
> extension into a 64-bit binary of Python.
> It simply doesn't work.

No. They will need to run the 32-bit binary of Python
on the 64-bit system.

> I wouldn't say that PyString_AsStringAndSize() is rarely
> used and neither is PyArg_ParseTuple().

I can't find much usage of PyString_AsStringAndSize.
Even in the Python core, it is only called 8 times
outside string and strop.

> I agree that other APIs are certainly more domain
> specific and can be dealt with in the extension, but
> those two APIs need special care and so do the type
> slot functions.

For PyArg_ParseTuple, there is special care, because
there won't be compiler warnings otherwise.

For PyString_AsStringAndSize, the compiler will
warn about incorrect pointer types.

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] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  384 open ( +2) /  3016 closed (+13) /  3400 total (+15)
Bugs:  909 open ( +6) /  5500 closed (+21) /  6409 total (+27)
RFE :  208 open ( +5) /   196 closed ( +1) /   404 total ( +6)

New / Reopened Patches
__

add support for thread function result storage  (2006-01-02)
   http://python.org/sf/1395552  opened by  tosi-in

Nit: incorrect subsection LaTeX label in cookielib docs  (2006-01-03)
CLOSED http://python.org/sf/1395715  opened by  John J Lee

Further .vcproj cleanups  (2006-01-03)
   http://python.org/sf/1396093  opened by  Adal Chiriliuc

FreeBSD is system scope threads capable  (2006-01-04)
   http://python.org/sf/1396919  opened by  Valts

Fix dict and set docs, re: immutability  (2006-01-05)
   http://python.org/sf/1397711  opened by  Collin Winter

dictnotes.txt  (2006-01-05)
   http://python.org/sf/1397848  opened by  Jim Jewett

File-iteration and read* method protection  (2006-01-05)
   http://python.org/sf/1397960  opened by  Thomas Wouters

ConfigParser to save with order  (2006-01-07)
   http://python.org/sf/1399309  opened by  Facundo Batista

enhance unittest to define tests that *should* fail  (2006-01-08)
   http://python.org/sf/1399935  opened by  Neal Norwitz

unicode formats floats according to locale  (2006-01-09)
CLOSED http://python.org/sf/1400181  opened by  Neal Norwitz

Need warning that `dl` module can cause segfaults/crashes  (2006-01-10)
   http://python.org/sf/1402224  opened by  Tim Delaney

Fix dictionary subclass semantics when used as global dicts.  (2006-01-10)
   http://python.org/sf/1402289  opened by  crutcher

Suggested patch for #1403410  (2006-01-13)
CLOSED http://python.org/sf/1404357  opened by  Peter van Kampen

Patch for #1394565  (2006-01-13)
CLOSED http://python.org/sf/1404374  opened by  Peter van Kampen

Patches Closed
__

dict.merge  (2005-12-27)
   http://python.org/sf/1391204  closed by  gvanrossum

cookielib LWPCookieJar and MozillaCookieJar exceptions  (2005-02-06)
   http://python.org/sf/1117398  closed by  nnorwitz

Nit: incorrect subsection LaTeX label in cookielib docs  (2006-01-03)
   http://python.org/sf/1395715  closed by  birkenfeld

mingw compile  (2004-10-25)
   http://python.org/sf/1053879  closed by  loewis

skip winsound for Windows/IA64 build  (2005-03-09)
   http://python.org/sf/1160169  closed by  loewis

PCbuild vcproj project files need a cleanup  (2005-09-29)
   http://python.org/sf/1307806  closed by  loewis

look in libbsd.a also for openpty and forkpty  (2004-01-22)
   http://python.org/sf/881820  closed by  loewis

UTF-8-Sig codec  (2005-04-05)
   http://python.org/sf/1177307  closed by  loewis

fix for distutils "upload" command  (2005-09-23)
   http://python.org/sf/1299675  closed by  loewis

unicode formats floats according to locale  (2006-01-09)
   http://python.org/sf/1400181  closed by  nnorwitz

Python crashes in pyexpat.c if malformed XML is parsed  (2005-03-31)
   http://python.org/sf/1173998  closed by  nnorwitz

Suggested patch for #1403410  (2006-01-13)
   http://python.org/sf/1404357  closed by  birkenfeld

Patch for #1394565  (2006-01-13)
   http://python.org/sf/1404374  closed by  birkenfeld

New / Reopened Bugs
___

errata  (2006-01-01)
CLOSED http://python.org/sf/1394868  opened by  Chad Whitacre

os.remove should behave like rm, not unlink  (2006-01-02)
CLOSED http://python.org/sf/1395442  opened by  Chad Whitacre

Please document pyc format guarantees  (2006-01-02)
CLOSED http://python.org/sf/1395511  opened by  Joe Wreschnig

module os, very small doc inconsistency  (2006-01-02)
CLOSED http://python.org/sf/1395597  opened by  tiissa

Can't build Python on POSIX w/o $HOME  (2004-05-24)
   http://python.org/sf/959576  reopened by  birkenfeld

make fails trying to run svnversion  (2006-01-03)
CLOSED http://python.org/sf/1395926  opened by  M.-A. Lemburg

TimedRotatingFileHandler at midnight rolls over at 01:00  (2006-01-03)
   http://python.org/sf/1396030  opened by  Andrew Waters

TimedRotatingFileHandler does not recover from open error  (2006-01-03)
   http://python.org/sf/1396040  opened by  Andrew Waters

KeyboardInterrupt prevents return to Windows console  (2006-01-03)
   http://python.org/sf/1396258  opened by  Vernon Cole

file.tell() returns illegal value on Windows  (2006-01-03)
   http://python.org/sf/1396471  opened by  Tom Goddard

urlparse is confused by /  (2006-01-04)
   http://python.org/sf/1396543  opened by  John Hansen

TimedRotatingFileHandler midnight rollover time increases  (2006-01-04)
   http://python.org/sf/1396622  opened by  Andrew Waters

bsddb.__init__ causes error  (2006-01-04)
   http://python.org/sf/1396678  opened by  Fabian_M

%ehrntDRT support for time.strptime   (2006-01-04)
   http://python.org/sf/1396946  opened by  Johan Dahlin

no han

Re: [Python-Dev] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)

[Martin v. Löwis]

M.-A. Lemburg wrote:
> Right, but I don't see the point of each and every
> extension having to go through these hoops when you
> could add support for these checks (including error
> reporting) to the few APIs in question, in particular
> the PyArg_ParseTuple() API.

I don't want to rename the existing APIs, so porters
to ssize_t have an easier life (just fix the compiler
warnings).

As for PyArg_ParseTuple: this already works and requires
no changes either way.

> I don't expect this to happen any time soon for the ten or
> twenty other 3rd party extensions we regularly use and this
> would prevent an upgrade to Python 2.5.

It shouldn't. It could sensibly prevent an upgrade to 64-bit
machines, but there would be no reason not to upgrade on
32-bit machines.

> In particular, functions that currently take int* output
> parameters should continue to do so. New functions should be
> revised to enable Py_ssize_t* output arguments and preseve
> backwards compatibility.
> 
> (This also includes the strategy to be used, so you can
> remove the note on strategy)

Will do.

> Please also add a comment on the fact that extensions
> which haven't been recompiled for the Python 2.5 API
> will not get imported (the API_LEVEL check should consistently
> fail for these instead of just issuing a warning).

I will add it as an open issue. I disagree that this should
actually be done.

>>Would you like to write a specification for that?
> 
> 
> Sure, if there's hope to get this into the code.

I don't know. So far, you are the only one wanting this
kind of change. If the change actually existed, more
people might be willing to voice an opinion - whether
that will be in favour of more hackishness and backwards
compatibility, or against, I cannot guess.

I would personally want to restrict hackishness to places
that the compiler doesn't warn about.

>>To simplify the porting.
> 
> 
> Sorry, I lost you there:
> 
> I'm saying that two sets of APIs (one for int*, one
> for Py_ssize_t*) will make porting easier since
> updated code will only have to rename the APIs
> used. Furthermore, it will allow to write code
> that easily works in Python 2.1-2.4 as well as
> Python 2.5.

Yes, but users of the new API (who would conceptually
do the right thing) would need more effort, just to
protect users who do nothing (which conceptually do
the wrong thing). By just editing the APIs (instead
of also renaming them), I simplify the porting.

> I'm talking about the few APIs that use output parameters.
> Those do support error reporting.

Hmm. I think I could personally accept a change that uses
macro tricks to do all that, i.e. keep the output parameters
at int* if some macro (Py_SIZE_T_CLEAN) is not defined,
and use Py_ssize_t* if it is defined. People would then get
the right warnings still, but no changes would be necessary
to "old" code.

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

Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

[Scott David Daniels]

Fredrik Lundh wrote:
> Scott David Daniels wrote:
>>  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288
> 
> my main nit is the name: the test isn't broken in itself, and doesn't need
> to be fixed; it's just not expected to succeed at this time.
> 
> the usual term for this is "expected failure" (sometimes called XFAIL).

Would "expect_fail", "expect_failure", "expected_fail", or 
"expected_failure",
work for you?

If so, could you rank them?  I don't get anything from "xfail", and I'm
not sure others will either.

--Scott David Daniels
[EMAIL PROTECTED]

___
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] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

[Nick Coghlan]

Scott David Daniels wrote:
> Fredrik Lundh wrote:
>> Scott David Daniels wrote:
>>>  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288
>> my main nit is the name: the test isn't broken in itself, and doesn't need
>> to be fixed; it's just not expected to succeed at this time.
>>
>> the usual term for this is "expected failure" (sometimes called XFAIL).
> 
> Would "expect_fail", "expect_failure", "expected_fail", or 
> "expected_failure",
> work for you?
> 
> If so, could you rank them?  I don't get anything from "xfail", and I'm
> not sure others will either.

I'd be happy with either "expect_fail" (as the shortest) or "expected_failure" 
(as the actual English term), with a slight preference for the former as being 
just as clear, and requiring slightly less typing.

There's also the fact that unittest has a large number of test case methods 
that start with "failIf" or "failUnless", so the "expect_fail" term aligns 
nicely with those.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

[Fred L. Drake, Jr.]

Scott David Daniels wrote:
 > Would "expect_fail", "expect_failure", "expected_fail", or
 > "expected_failure", work for you?

None of these use the same naming convention as the other unittest object 
attributes.  Perhaps something like failureExpected?

I'd definately prefer something that reads cleanly; mirroring the exact form 
of the word "fail" doesn't make sense; making it readable does.


  -Fred

-- 
Fred L. Drake, Jr.   
___
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