[Python-Dev] Migrating to subversion

2005-03-06 Thread Martin v. Löwis 
I don't know whether anybody has done this before,
but I just tried to run cvs2svn on the Python repository.
The conversion took 7 hours, and the result is now
available at
http://www.dcl.hpi.uni-potsdam.de/python/branches/
Because of the load that the conversion produces on
the machine, I cannot run the entire conversion every
day. Reportedly, cvs2svn is able to run in incremental
mode, but I haven't tried this out yet.
On close inspection, you might notice a few things:
- A few branches/tags are missing, namely
  r16b1|cnri-16-start|descr-branch|release152p1-patches|after-c
all-reorg|r22a1|before-call-reorg|release16|r161|r161-branch|r16a2|release152p2
  I had to manually exclude these tags, because cvs2svn complained
  that they (some of them) are tags on some files, and branches
  on other files. When I excluded these, it then complained that
  some other tags depend on the excluded ones, so I had to exclude
  these as well.
  I suspect that this can be fixed by modifying the CVS repository
  before the conversion, typically by converting the version tags
  to branch tags. cvs2svn did not report what files specifically
  caused the problems, and I don't know the proper cvs/rcs
  incantation to fix these. So if anybody has done that before,
  or knows how to, please let me know.
- A few tags are useless, most notably the "vendor" branches.
  I think they should be excluded in the conversion.
  I don't know where the "unlabeled" branches come from, but
  they appear to be useless as well.
- It has imported the CVSROOT directory as well. I don't
  know whether this is deliberate/useful.
Anyway, this  repository is now online for anonymous read-only
access. Anybody interested in playing with it is welcome to
do so.
For those interested in server side issues: the repository
is an 1.1.1 fsfs repository. The CVS repository consumes
368MiB; the SVN repository 797MiB.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Migrating to subversion

2005-03-06 Thread Greg Ward 
On 06 March 2005, "Martin v. Löwis" said:
> - It has imported the CVSROOT directory as well. I don't
>   know whether this is deliberate/useful.

This is just an artifact of how SourceForge CVS repositories are
organized.  When I converted Optik's CVS to Subversion, I just did this:

  cvs2svn -s /home/svn/optik /home/cvs/optik/optik

where /home/cvs/optik is what I got after unpacking the tarball
downloaded from SF.

Presumably for Python's repository, this would work:

  cvs2svn -s /home/svn/python /home/cvs/python/python

...except, umm, isn't distutils a separate top-level directory in the
Python repository or something?  That'll probably have to be fixed
manually.

Greg
-- 
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
The NSA.  We care: we listen to our customers.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: Useful thread project for 2.5?

2005-03-06 Thread Fazal Majid 
Tim Peters wrote:
Florent's DeadlockDebugger in turn builds on an external C threadframe 
module:

http://www.majid.info/mylos/stories/2004/06/10/threadframe.html
Folding the functionality of that (or similar functionality) into the
core would, IMO, be a valuable addition for 2.5, and would make an
excellent intro project for an aspiring contributor interested in how
threads work in CPython (what this module does is conceptually
simple).  It belongs in the core because it's not safe to chase the
tstate chain without holding pystate.c's internal head_mutex lock
(holding the GIL isn't enough -- it's normal practice to call
PyThreadState_Delete() while not holding the GIL).
I'd do it myself (and maybe I will anyway), but this really would make
a good (finite; conceptually simple) project for someone who wants to
gain Python developer experience.
Since I started this, I might as well finish it. I do have some Python 
developer experience (hey, I even voted for comp.lang.python back 
when...) but not in the core interpreter itself.

I suspect integrating this feature (let's call it sys._current_frames() 
for the sake of argument, although it probably belongs in the threads 
module) in the core is not going to be quite as trivial as you say, as 
there are potential memory leaks. If the function returns a dictionary, 
it should probably be a weak dict to avoid a circular reference between 
the frame of the thread that calls _current_frames and its locals that 
contain the returned dictionary. But that would also mean the 
references to other threads' frames are going to be weak, thus not 
allowing the current thread to inspect their locals and backtraces at 
will as those weak references may be broken.

--
Fazal Majid Email:  [EMAIL 
PROTECTED]
Home:   +1 415 
359-0918
 Jones Apt. 1   Cell:   +1 415 
244-1337
San Francisco, CA 94109, USAWeb:www.majid.info
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Documentation for __new__

2005-03-06 Thread Greg Ward 
I've LaTeX'ified the proposed documentation for __new__() and uploaded
the patch to SF:

  
http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=124422&aid=1156412

Someone who really understands new-style classes should give this a
look.  (Guido?)  I've tested that Python 2.3.5 and 2.4 (CVS) actually
implement what's described in this doc patch, but it wouldn't hurt if
someone read it from the point of view of what the promised constract is
supposed to be!

Greg
-- 
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
I'd like some JUNK FOOD ... and then I want to be ALONE --
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Failing tests: marshal, warnings

2005-03-06 Thread Greg Ward 
Anyone else seeing test failures on the 2.4 branch right now?  I started
seeing this failure:

  test_warnings
  test test_warnings failed -- Traceback (most recent call last):
File "/scratch/src/python-2.4/Lib/test/test_warnings.py", line 57, in 
test_warn_specific_category
  warnings.warn(text, category)
File "/scratch/src/python-2.4/Lib/warnings.py", line 57, in warn
  warn_explicit(message, category, filename, lineno, module, registry)
File "/scratch/src/python-2.4/Lib/warnings.py", line 92, in warn_explicit
  raise message
  RuntimeWarning: unfiltered RuntimeWarning

yesterday, so I "cvs up"'d today to see if it had been fixed.  Now, not
only is test_warnings failing, so is test_marshal:

  test_marshal
  test test_marshal failed -- Traceback (most recent call last):
File "/scratch/src/python-2.4/Lib/test/test_marshal.py", line 88, in 
test_floats
  got = marshal.load(file(test_support.TESTFN, "rb"))
  IOError: [Errno 2] No such file or directory: '@test'

Naturally, they only fail when running the full test suite.  ;-(  I sure
hope my recent fix to textwrap isn't to blame!  I'll fiddle around a bit
in my working dir and see if I can figure out what's going on, but I'd
like to know if I'm the only one seeing these problems...

Greg
-- 
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
Never underestimate the power of human stupidity.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failing tests: marshal, warnings

2005-03-06 Thread Brett C. 
Greg Ward wrote:
Anyone else seeing test failures on the 2.4 branch right now?  I started
seeing this failure:
Both are passing for me on OS X 10.3.8 w/ a fresh cvs up as of 15:41 PT.  But I 
am getting failures for test_socket (ignoring the usual test__locale failure on 
OS X):

==
FAIL: testHostnameRes (__main__.GeneralModuleTests)
--
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 273, in testHostnameRes
self.fail("Error testing host resolution mechanisms.")
AssertionError: Error testing host resolution mechanisms.

Don't know if this is an "OS X" issue or a "my system" issue.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failing tests: marshal, warnings

2005-03-06 Thread Greg Ward 
On 06 March 2005, I said:
> Anyone else seeing test failures on the 2.4 branch right now?  I started
> seeing this failure:
> 
>   test_warnings
>   test test_warnings failed -- Traceback (most recent call last):
> File "/scratch/src/python-2.4/Lib/test/test_warnings.py", line 57, in 
> test_warn_specific_category
>   warnings.warn(text, category)
> File "/scratch/src/python-2.4/Lib/warnings.py", line 57, in warn
>   warn_explicit(message, category, filename, lineno, module, registry)
> File "/scratch/src/python-2.4/Lib/warnings.py", line 92, in warn_explicit
>   raise message
>   RuntimeWarning: unfiltered RuntimeWarning
[...]
> Naturally, they only fail when running the full test suite.

OK, I've narrowed it down: test_warnings fails when run after
test_descr:

  $ ./python -E Lib/test/regrtest.py test_descr test_warnings
  test_descr
  test_warnings
  test test_warnings failed -- Traceback (most recent call last):
File "/scratch/src/python-2.4/Lib/test/test_warnings.py", line 57, in 
test_warn_specific_category
  warnings.warn(text, category)
File "/scratch/src/python-2.4/Lib/warnings.py", line 57, in warn
  warn_explicit(message, category, filename, lineno, module, registry)
File "/scratch/src/python-2.4/Lib/warnings.py", line 92, in warn_explicit
  raise message
  RuntimeWarning: unfiltered RuntimeWarning

Does this ring alarm bells with anyone?

Greg
-- 
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
Gee, I feel kind of LIGHT in the head now, knowing I can't make my
satellite dish PAYMENTS!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failing tests: marshal, warnings

2005-03-06 Thread Greg Ward 
On 06 March 2005, I said:
> OK, I've narrowed it down: test_warnings fails when run after
> test_descr:

Raymond Hettinger, step right up!  You're the next contestant on The
Tests Are Failing!  Your recent checkins include...

  working file: Lib/test/test_descr.py; sticky tag: release24-maint
  revision: 1.202.2.1
  date: 2005/03/03 16:55:53;  author: rhettinger;  lines: +13 -0
  SF bug #1155938: Missing None check for __init__().
  
  revision: 1.202.2.2
  date: 2005/03/04 04:47:04;  author: rhettinger;  lines: +7 -1
  Convert "__init__ should return None" from an exception to a warning.

If I revert test_descr.py to 1.202 (the branch point for 2.4), then
running

  ./python -E Lib/test/regrtest.py test_descr test_warnings

works just fine.  If I revert to 1.202.2.1, then test_descr fails, but
test_warnings passes.  If I update to the latest, 1.202.2.2, then
test_desc passes, but test_warnings fails.

[...a few minutes of tinkering and reading up on warning filters...]

A-ha!  I get it.  There are two mistakes in test_descr.py:test_init():
lack of "finally" clause, and failure to make a copy of
warnings.filters.  This patch fixes both:

"""
--- Lib/test/test_descr.py  4 Mar 2005 04:47:04 -   1.202.2.2
+++ Lib/test/test_descr.py  7 Mar 2005 00:54:00 -
@@ -3973,15 +3973,18 @@
 def __init__(self):
 return 10

-oldfilters = warnings.filters
-warnings.filterwarnings("error", category=RuntimeWarning)
+oldfilters = warnings.filters[:]
 try:
-Foo()
-except RuntimeWarning:
 pass
-else:
-raise TestFailed, "did not test __init__() for None return"
-warnings.filters = oldfilters
+warnings.filterwarnings("error", category=RuntimeWarning)
+try:
+Foo()
+except RuntimeWarning:
+pass
+else:
+raise TestFailed, "did not test __init__() for None return"
+finally:
+warnings.filters = oldfilters


 def test_main():
"""

I'll check this in and merge to the trunk once I see all tests passing.

Greg
-- 
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
I hope something GOOD came in the mail today so I have a REASON to live!!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failing tests: marshal, warnings

2005-03-06 Thread Brett C. 
Greg Ward wrote:
[SNIP]
A-ha!  I get it.  There are two mistakes in test_descr.py:test_init():
lack of "finally" clause, and failure to make a copy of
warnings.filters.  This patch fixes both:
"""
--- Lib/test/test_descr.py  4 Mar 2005 04:47:04 -   1.202.2.2
+++ Lib/test/test_descr.py  7 Mar 2005 00:54:00 -
@@ -3973,15 +3973,18 @@
 def __init__(self):
 return 10
-oldfilters = warnings.filters
-warnings.filterwarnings("error", category=RuntimeWarning)
+oldfilters = warnings.filters[:]
 try:
-Foo()
-except RuntimeWarning:
 pass
-else:
-raise TestFailed, "did not test __init__() for None return"
-warnings.filters = oldfilters
+warnings.filterwarnings("error", category=RuntimeWarning)
+try:
+Foo()
+except RuntimeWarning:
+pass
+else:
+raise TestFailed, "did not test __init__() for None return"
+finally:
+warnings.filters = oldfilters
 def test_main():
"""
I'll check this in and merge to the trunk once I see all tests passing.
Well, I just checked in the list copy fix, so you only have to worry about 
adding the 'finally' clause to the 'try' statement.

-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failing tests: marshal, warnings

2005-03-06 Thread Brett C. 
Brett C. wrote:
Greg Ward wrote:
[SNIP]
A-ha!  I get it.  There are two mistakes in test_descr.py:test_init():
lack of "finally" clause, and failure to make a copy of
warnings.filters.  This patch fixes both:
"""
--- Lib/test/test_descr.py  4 Mar 2005 04:47:04 -   1.202.2.2
+++ Lib/test/test_descr.py  7 Mar 2005 00:54:00 -
@@ -3973,15 +3973,18 @@
 def __init__(self):
 return 10
-oldfilters = warnings.filters
-warnings.filterwarnings("error", category=RuntimeWarning)
+oldfilters = warnings.filters[:]
 try:
-Foo()
-except RuntimeWarning:
 pass
-else:
-raise TestFailed, "did not test __init__() for None return"
-warnings.filters = oldfilters
+warnings.filterwarnings("error", category=RuntimeWarning)
+try:
+Foo()
+except RuntimeWarning:
+pass
+else:
+raise TestFailed, "did not test __init__() for None return"
+finally:
+warnings.filters = oldfilters
 def test_main():
"""
I'll check this in and merge to the trunk once I see all tests passing.
Well, I just checked in the list copy fix, so you only have to worry 
about adding the 'finally' clause to the 'try' statement.

nm, the commit failed because Greg beat me to the checkin by like a second.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failing tests: marshal, warnings

2005-03-06 Thread Greg Ward 
On 06 March 2005, I said:
> I'll check this in and merge to the trunk once I see all tests passing.

Checked in on 2.4 branch.  Not merged to trunk since Raymond hasn't
merged his stuff to the trunk yet.

Greg
-- 
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
I repeat myself when under stress I repeat myself when under stress I repeat---
___
Python-Dev mailing list
[email protected]
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 for 2005-02-01 through 2005-02-14[draft]

2005-03-06 Thread Tony Meyer 
Somewhat slower, but here are two more threads from me (email is mostly a
weekday thing for me, and the last few days were full of sun, wine, food and
jazz.  Well, and work.  But working with sun, wine, food and jazz, so it's
hard to complain too much).  Feedback will not be ignored :)

--
More licensing issues - redistribution
--

As most people know, one of the major changes between the Windows builds of
Python 2.3 and 2.4 is that 2.4 is built with VC7, rather than VC6.  One of
the consequences of this change is that 2.4 links with the Microsoft DLL
msvcr71.dll, which only some people have, rather than msvcr.dll, which
pretty much all Windows users have.

The Windows Python 2.4 distribution installs msvcr71.dll, so it's there when
needed.  However, those building frozen applications (e.g. with py2exe) need
to ensure that their users have msvcr71.dll.

After going through the EULA's for both the commercial and free-to-use
Microsoft compilers, it seems that redistributing mscvr71.dll is acceptable,
if the re-distributor owns a copy of the commercial (not free) compiler,
includes an EULA agreement in one of various forms (e.g. 'click-wrap'), and
follows various other minor conditions (note that just about every message
in this thread contains "IANAL, but").

This leaves those without VC7 unable to redistribute msvcr71, unless, as
some suggested, distributing a frozen Python application can be considered
as redistributing Python (and the various other minor conditions are
followed).

In an interesting twist, it appears that the official Windows Python 2.4
distribution is in breach of the EULA, as a 'click-wrap' license is
required, and is not present.  This element of the thread died without
reaching a conclusion, however.

If you *are* a lawyer (with expertise in this area), and would like to
comment, then please do!

Contributing threads:
   - `Is msvcr71.dll re-redistributable?`__

--
Avoiding signs in memory addresses
--

Troels Walsted Hansen pointed out that builtin_id() can return a negative
number in Python 2.4 (and can generate a warning in 2.3).  Some 2.3 modules
(but no 2.4 ones) have code to work around this, but Troels suggested that a
better solution would be to simply have builtin_id() return an unsigned long
integer.  The consensus was that this would be a good idea, although nothing
has been checked in yet, and so this will probably stagnate without someone
submitting a patch (or at least a bug report).

Contributing threads: 
   - `builtin_id() returns negative numbers`__

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: Useful thread project for 2.5?

2005-03-06 Thread Phillip J. Eby 
At 02:42 PM 3/6/05 -0800, Fazal Majid wrote:
I suspect integrating this feature (let's call it sys._current_frames() 
for the sake of argument, although it probably belongs in the threads 
module) in the core is not going to be quite as trivial as you say, as 
there are potential memory leaks. If the function returns a dictionary, it 
should probably be a weak dict to avoid a circular reference between the 
frame of the thread that calls _current_frames and its locals that contain 
the returned dictionary.
Given the primary use case as a debugging tool, I don't think the 
circularity will have any significant problems.  It would be simpler to 
just document that a caller should do this:

try:
framedict = sys._current_frames()
# do stuff here
finally:
framedict = None  # break the cycle, allowing GC
___
Python-Dev mailing list
[email protected]
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 for 2005-02-15 through 2005-02-28[draft]

2005-03-06 Thread Tony Meyer 
> I am not expecting the candidates for taking of the Summaries 
> to write stuff for this one (although I wouldn't mind it  =).

In penance for being late with the other ones, here are a summaries for a
couple of skipped threads for this period:

---
Slow unit tests should be distinguished
---

Guido clarified that unit tests should distinguish between "regular" tests
and slow ones by use of the unit test 'resource' keys, as a result of Peter
Åstrand asking for comments about bug #1124637, which complained that
test_subprocess is too slow.  The suggested solution was to add another
resource for subprocess, so that generally a quick version would run, but a
longer, more thorough test would run with -uall or -usubprocess.  Along the
way, it was discovered that the reason that Windows already ran
test_subprocess quickly was because there was code special-casing it to be
fast.  The resource solution was checked in, although Windows was left
special-cased.

Contributing threads:
   - `[ python-Bugs-1124637 ] test_subprocess is far too slow (fwd)
 
`__

---
Clarification of the '5 for 1' deal
---

It seems that the offer that some python-dev'ers have made to review a patch
in exchange for reviews of five (originally ten) other patches is finally
being taken up by various people.  However, python-dev traffic has increased
with patch and bug reviews, and the question was posed whether reviews
should be posted in general, or only for this specific deal.

The answer is that the comments should also be entered via the SourceForge
tracking system, but that a brief message covering a batch (rather than
individual) of reviews is acceptable for python-dev, at least for now.  New
reports should almost never be posted to python-dev, however, and should be
entered via the tracking system.

This offer isn't official policy, but a reference to it will be added to
Brett's summary of the development process.  However, people should also
remember that it may take developers some time to find time to deal with
reviews, and so have patience after posting their review.

Contributing threads:
   - `discourage patch reviews to the list?
 
`__
   - `Some old patches
 
`__
   - `Five review rule on the /dev/ page?
 
`__

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Useful thread project for 2.5?

2005-03-06 Thread Tim Peters 
[Phillip J. Eby]
> What would you suggest calling it?  sys._current_frames(), returning a
> dictionary?

I don't fight about names -- anything that doesn't make Guido puke
works .  I channel that sys._current_frames() would be fine.  A
dict mapping thread id to current thread frame would be lovely!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: Useful thread project for 2.5?

2005-03-06 Thread Tim Peters 
[Fazal Majid]
> Since I started this, I might as well finish it. I do have some Python
> developer experience (hey, I even voted for comp.lang.python back
> when...) but not in the core interpreter itself.

Cool!  WRT your current module, it would need changes to follow
Python's C coding style, to check _every_ C API call for an error
return, and to grab head_mutex while crawling over the tstate chain.

> I suspect integrating this feature (let's call it sys._current_frames()
> for the sake of argument, although it probably belongs in the threads
> module)

I expect that Phillip's thought here is that the sys module already
has a _getframe() function, so everyone who knows that would likely
expect a new frame-retrieval function to be exposed in sys too.

> in the core is not going to be quite as trivial as you say, as there are
> potential memory leaks.

Good news:  I don't think so.

> If the function returns a dictionary, it should probably be a weak dict to 
> avoid
> a circular reference between the frame of the thread that calls 
> _current_frames
> and its locals that contain the returned dictionary. But that would also mean 
> the
> references to other threads' frames are going to be weak, thus not allowing 
> the
> current thread to inspect their locals and backtraces at will as those weak
> references may be broken.

dicts and frames both participate in cyclic gc in recent Pythons.  For
example, you can run this all day in 2.4 and not see memory grow
(provided you don't disable cyclic gc):

def f():
import sys
myframe = sys._getframe()

while 1:
f()

Frames aren't weakly referenceable anyway:

>>> import weakref
>>> import sys
>>> f = sys._getframe()
>>> weakref.ref(f)
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: cannot create weak reference to 'frame' object
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36

2005-03-06 Thread Anthony Baxter 
Greg,

Um, unless I misread this, you added new attributes to the ossaudiodev objects
in the 2.4 branch. Please don't do this - this is a new feature, and suddenly 
people who want to use those new attributes have to either test for version
>= 2.4.1, or else do a hasattr test. Please see the bugfix PEP for more 
rationale on this...

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com