Dennis Heuer [EMAIL PROTECTED] wrote:
OK, let's get back to the bitarray type. To first be clear about the
*type* of bitarray: The type I talk about is really a *bit*-array and
not a *bytewise*-array, as most developers seem to think of it. The
array doesn't provide the boolean manipulation
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 I think I
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 anywhere near
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
Guido van Rossum guido at 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
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 the Python
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 also wonder
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 should
be on
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
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 up
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 at
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
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
resources
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
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
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
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
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
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
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 available.
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.py.This would
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 installs
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 you have the
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
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, 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 the
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
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 directory
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.
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 code and try
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
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 from
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 trunk.
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 unfortunately,
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
allow
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
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- and
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 machine
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.
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
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 extension
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
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 imports) on all
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
+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 manager (only
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
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 Thomas digging
[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
per day.
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
51 matches
Mail list logo
