If you are addressed on this message, it means you have open issues
that need to be resolved for 2.5. Some of these issues are
documentation, others are code issues. This information comes from
PEP 356. The best way to get me to stop bugging you is to close out
these tasks. :-)
Who is the owner
[Neal Norwitz]
> ...
> I have disabled the leak warning for:
>
> LEAKY_TESTS="test_(cmd_line|ctypes|filecmp|socket|threadedtempfile|threading|urllib2)
>
> This is an attempt to reduce the spam. Would people rather me reduce
> this list so we can try to find the problems? The test runs 2 times
> p
On 4/22/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [19 Apr 2006, Neal Norwitz]
> > test_cmd_line leaked [0, 17, -17] references
> > test_filecmp leaked [0, 13, 0] references
> > test_threading_local leaked [-93, 0, 0] references
> > test_urllib2 leaked [-121, 88, 99] references
>
> Thanks to Thom
On 4/27/06, Brian C. Lum <[EMAIL PROTECTED]> wrote:
> Dear Python Community,
>
> I have been trying to research how to type-def python. I want to type-def
> python so that I can use it as a static analyzer to check for bugs. I
> have been going over research on this field and I came upon
> Brett
+1 from me too.
On 4/27/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > OTOH, if the two protocols are made orthogonal, then it's clear that the
> > manager is always the original object with the __context__ method. Then the
> > three cases are:
> >
> > - a pure context man
Nick Coghlan wrote:
> OTOH, if the two protocols are made orthogonal, then it's clear that the
> manager is always the original object with the __context__ method. Then the
> three cases are:
>
> - a pure context manager (only provides __context__)
> - a pure managed context (only provides _
>> Author: tim.peters
>> Date: Wed Apr 26 03:15:53 2006
>> New Revision: 45721
>>
>> Modified:
>>python/trunk/Lib/test/test_with.py
>> Log:
>> Rev 45706 renamed stuff in contextlib.py, but didn't rename
>> uses of it in test_with.py. As a result, test_with has been skipped
>> (due to failing i
On Tue, Apr 25, 2006, Brett Cannon wrote:
>
> So, if you could, please reply to this message with ONE thing you have
> found in a tracker other than SF that you have liked (especially
> compared to SF) and ONE thing you dislike/hate about SF's tracker. I
> will use the replies as a quick-and-dirty
At 09:54 PM 4/27/2006 +0200, M.-A. Lemburg wrote:
>Note that I was talking about the .pth file being
>writable, not the directory.
Please stop this vague, handwaving FUD. You have yet to explain how this
situation is supposed to arise. Is there some platform on which files with
a .pth extensio
We've pretty much gotten settled into our new diggs at work here
(ActiveState) so my Windows buildbot machine should have better uptime
from now on.
Cheers,
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http:
Simon Dahlbacka wrote:
> Given that, it does not really seem feasible to include them..
Ok, thanks for the investigation.
> Speaking of icons, do the bundled ico files have to be named py.ico and
> pyc.ico?
No. I think I'll try to drop them altogether, getting the icons from
python_icon.exe only
On 4/27/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Simon Dahlbacka wrote:> OTOH, the ETA for Vista is "just after" 2.5 release (end of 2006 for> OEM:s, beginning of 2007 for customers), long before 2.6>> That said, I don't have any strong preferences either way. (..but I do
> have a x64 Vista
Phillip J. Eby wrote:
> At 06:47 PM 4/27/2006 +0200, M.-A. Lemburg wrote:
>> Just read that you are hijacking site.py for setuptools'
>> "just works" purposes.
>
> "hijacking" isn't the word I'd use; "wrapping" is what it actually
> does. The standard site.py is executed, there is just some pre-
Dennis Heuer wrote:
> I hope that somebody agrees and is already starting to implement this
> new array type. My best wishes are with you.
This is off-topic for python-dev. Please post to comp.lang.python instead.
Regards,
Martin
___
Python-Dev mailing
Dennis Heuer wrote:
> The real misunderstanding lies somewhere else. I thought that the
> bitarray's instance would have more control over the long type's
> instance, like with the mutable types. I thought that the long type's
> superclass would provide methods similar to __setitem__ that would
> a
Simon Dahlbacka wrote:
> OTOH, the ETA for Vista is "just after" 2.5 release (end of 2006 for
> OEM:s, beginning of 2007 for customers), long before 2.6
>
> That said, I don't have any strong preferences either way. (..but I do
> have a x64 Vista machine running ATM)
Good to know, but unfortunate
On 4/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:38 AM 4/27/2006 -0700, Guido van Rossum wrote:
> >The change below was rolled back because it broke other stuff. But IMO
> >it is actually necessary to fix this,
>
> Huh? The change you showed wasn't reverted AFAICT; it's still on the t
At 11:38 AM 4/27/2006 -0700, Guido van Rossum wrote:
>The change below was rolled back because it broke other stuff. But IMO
>it is actually necessary to fix this,
Huh? The change you showed wasn't reverted AFAICT; it's still on the trunk.
> otherwise those few exceptions
>that don't derive fr
The change below was rolled back because it broke other stuff. But IMO
it is actually necessary to fix this, otherwise those few exceptions
that don't derive from Exception won't be printed correctly by the
traceback module:
guido:~/p/osx guido$ ./python.exe
Python 2.5a2 (trunk:45765, Apr 27 2006,
"Brian C. Lum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Brett Cannon, "Localized Type Inference of Atomic Types in Python":
> http://www.ocf.berkeley.edu/~bac/thesis.pdf
>
> I was wondering if anyone could help me contact him so that I could might
> ask him for his source cod
At 06:47 PM 4/27/2006 +0200, M.-A. Lemburg wrote:
>Just read that you are hijacking site.py for setuptools'
>"just works" purposes.
"hijacking" isn't the word I'd use; "wrapping" is what it actually
does. The standard site.py is executed, there is just some pre- and
post-processing of sys.path.
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> I could check it in, except the make-testall I ran overnight showed a small
> problem: the patch would generate a number of spurious warnings in the
> trunk:
>
> /home/thomas/python/python/trunk/Lib/gzip.py:9:
> ImportWarning: Not importing di
On Thursday 27 April 2006 11:57, Bill Janssen wrote:
> By the way, check out the new Python/Mac iconography that Jacob Rus
> has put together (with lots of advice from others :-), at
> http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png.
Very nice! I just might have to start using some
Phillip J. Eby wrote:
> Please see
> http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt for
> source, or http://peak.telecommunity.com/DevCenter/EggFormats for an
> HTML-formatted version.
>
> Included are summary descriptions of the formats of all of the standard
> metada
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 4/27/06, Gustavo Carneiro <
[EMAIL PROTECTED]> wrote:
Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages.
It *is* a solution for my problem. I don't need
By the way, check out the new Python/Mac iconography that Jacob Rus
has put together (with lots of advice from others :-), at
http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png.
Tim Parkin's new logo sure started something.
Bill
___
Python-Dev
On 4/27/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages.
It *is* a solution for my problem. I don't need the __init__.py file for anything, since I don't need a
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 4/27/06, Gustavo Carneiro <
[EMAIL PROTECTED]> wrote:
On 4/27/06, Phillip J. Eby <
[EMAIL PROTECTED]> wrote:
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:>"Gustavo Carneiro" <[EMAIL PROTECTED]
> writes:>> > Now the problem. Suppose
On 4/27/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
On 4/27/06, Phillip J. Eby <
[EMAIL PROTECTED]> wrote:
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:>"Gustavo Carneiro" <[EMAIL PROTECTED]
> writes:>> > Now the problem. Suppose you have the source package python-foo-bar,
> > which in
On 4/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:>"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:>> > Now the problem. Suppose you have the source package python-foo-bar,
> > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.p
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:
>"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
>
> > Now the problem. Suppose you have the source package python-foo-bar,
> > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This
> > would make a module called "foo.bar" a
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
Alrighty then. The list has about 12 hours to convince me (and you) that it's a bad idea to generate that warning. I'll be asleep by the time the trunk un-freezes, and I have a string of early meetings tomorrow. I'll get to it somewhere in the a
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
> Now the problem. Suppose you have the source package python-foo-bar,
> which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This
> would make a module called "foo.bar" available. Likewise, you can have the
> source package pytho
Dear Python Community,
I have been trying to research how to type-def python. I want to type-def
python so that I can use it as a static analyzer to check for bugs. I
have been going over research on this field and I came upon
Brett Cannon's thesis in which he tweaks the compiler and shows tha
Yes, this was previously "inheriting basic types more efficiently" but
now I want something different ;)
I looked at the array type and found it quite C-ish. It is also not
suited for arithmetics because it's a sequence type like a constrained
list and not efficiently (and comfortably) usable like
On 4/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:[...]
So I have a very simple proposal: keep the __init__.py requirement fortop-level pacakages, but drop it for subpackages. This should be asmall change. I'm hesitant to propose *anything* new for Python 2.5,so I'm proposing it for
2.6; if N
The release is done. The trunk is now unfrozen.
Thanks,
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
>> Not that it would count in any way, but I'd prefer to keep it. How
>> would I mark a subdirectory as "not-a-package" otherwise?
Guido> What's the use case for that? Have you run into this requirement?
Yes, we run into it. We typically install a package with any resources in a
res
Guido> One particular egregious problem is that *subpackage* are subject
Guido> to the same rule. It so happens that there is essentially only
Guido> one top-level package in the Google code base, and it already has
Guido> an __init__.py file. But developers create new subpackages
Brett Cannon wrote:
> I am starting to hash out what the Call for Trackers is going to say
> on the Infrastructure mailing list. Laura Creighton suggested we have
> a list of features that we would like to see and what we all hate
> about SF so as to provide some guidelines in terms of how to set
On behalf of the Python development team and the Python
community, I'm happy to announce the second alpha release
of Python 2.5.
This is an *alpha* release of Python 2.5. As such, it is not
suitable for a production environment. It is being released to
solicit feedback and hopefully discover bugs,
Guido van Rossum wrote:
> So I have a very simple proposal: keep the __init__.py requirement for
> top-level pacakages, but drop it for subpackages. This should be a
> small change. I'm hesitant to propose *anything* new for Python 2.5,
> so I'm proposing it for 2.6; if Neal and Anthony think this
The real misunderstanding lies somewhere else. I thought that the
bitarray's instance would have more control over the long type's
instance, like with the mutable types. I thought that the long type's
superclass would provide methods similar to __setitem__ that would
allow the bitarray instance to
Guido van Rossum wrote:
> So I have a very simple proposal: keep the __init__.py requirement for
> top-level pacakages, but drop it for subpackages. This should be a
> small change. I'm hesitant to propose *anything* new for Python 2.5,
> so I'm proposing it for 2.6; if Neal and Anthony think this
On 4/27/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
Martin v. Löwis wrote:> Fredrik Lundh wrote:>> you do wonderful stuff, and then you post the announcement as a>> followup to a really old message, to make sure that people using a>> threaded reader only stumbles upon this by accident... this shou
Martin v. Löwis wrote:
> Fredrik Lundh wrote:
>> you do wonderful stuff, and then you post the announcement as a
>> followup to a really old message, to make sure that people using a
>> threaded reader only stumbles upon this by accident... this should
>> be on the python.org frontpage!
>
> I als
Josiah Carlson wrote:
> "Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote:
>
>> Josiah Carlson wrote:
>>
>>> There exists various C and Python implementations of both AVL and
>>> Red-Black trees. For users of Python who want to use AVL and/or
>>> Red-Black trees, I would urge them to use
Guido van Rossum python.org> writes:
> The requirement that a directlry must contain an __init__.py file
> before it is considered a valid package has always been controversial.
> It's designed to prevent the existence of a directory with a common
> name like "time" or "string" from preventing fu
On Thursday 27 April 2006 17:47, Paul Moore wrote:
> FWIW, I still have every confidence in your judgement about
> features. However, I'd have to say that your timing sucks :-) Your
> initial message read to me as "Quick! I'm about to get lynched here
> - can I have the OK to shove this change in b
On 4/27/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> However, I'd have to say that your timing sucks :-) Your initial
> message read to me as "Quick! I'm about to get lynched here - can I
> have the OK to shove this change in before a2 goes out?"
And this just proves that my response wasn't anywher
On 4/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/26/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> > Of course, I only consider *my* reasons to be valid, and mine weren't
> > knee-jerk or tool-related. I don't think Python should be going "Oh, what
> > you wanted wasn't possible, but
51 matches
Mail list logo
