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 implementations.
In the case of *needing* the speed of a C extension, there already
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 implementations.
In the case of *needing* the speed of a C extension, there already
Brett Cannon wrote:
here is the rough draft of the PEP for packages maintained externally
from Python itself. There is some missing, though, that I would like
help filling in.
I don't know who to list as the contact person (i.e., the Python
developer in charge of the code) for Expat, Optik
Brett Cannon wrote:
OK, I am going to write the PEP I proposed a week or so ago, listing
all modules and packages within the stdlib that are maintained
externally so we have a central place to go for contact info or where
to report bugs on issues. This should only apply to modules that want
On 4/25/06, Jim Jewett [EMAIL PROTECTED] wrote:
Perhaps; part of the problem is with the SF workflow.
Yes. Brett should probably add that to the list of what's wanted from
a new tracker (good alerting of new items, and maybe some specific
Request commit functionality, tied to a listing of
Phillip J. Eby wrote:
At 12:08 AM 4/26/2006 +1000, Nick Coghlan wrote:
Secondly, the documentation now shows an example
of a class with a close() method using contextlib.closing directly as
its own
__context__() method.
Sadly, that would only work if closing() were a function. Classes
Neal and I wrote a few tests that exercise the Py_ssize_t code on 64bit hardware:http://python.org/sf/1471578Now that it's configurable and integrated with test_support and all, we think it's time to include it in the normal testsuite. I'd really like it to be in one of the next alphas, so people
Guido van Rossum wrote:
I'm not convinced.
Phillip managed to capture most of my reasons for documenting it that way.
However, trying to find a better term than the with statement context phrase
used in the latest docs is causing me to have doubts.
The term I'm currently favouring is managed
Gerhard Häring [EMAIL PROTECTED] writes:
Currently I'm not subscribed to python-checkins and didn't see a need
to. Is there a need to for Python core developers?
I would say it's encouraged.
I think there's no better way except subscribing and defining a
filter for SQLite-related commits
Thomas Wouters [EMAIL PROTECTED] writes:
Neal and I wrote a few tests that exercise the Py_ssize_t code on 64bit
hardware:
http://python.org/sf/1471578
Now that it's configurable and integrated with test_support and all, we
think it's time to include it in the normal testsuite. I'd really
Michael Hudson wrote:
Gerhard Häring [EMAIL PROTECTED] writes:
Currently I'm not subscribed to python-checkins and didn't see a need
to. Is there a need to for Python core developers?
I would say it's encouraged.
I think there's no better way except subscribing and defining a
filter
I'm going to be cutting 2.5a2 tomorrow. The trunk should be considered
FROZEN from 00:00 UTC on the 27th of April (in about 12-13 hours
time). Unless you're one of the release team, please don't make
checkins to the trunk until the release is done. I'll send another
message when it's done.
A.M. Kuchling wrote:
On Tue, Apr 25, 2006 at 04:10:02PM -0400, Jim Jewett wrote:
I don't see a good way to say It looks good to me. I don't see any
way to say There were issues, but I think they're resolved now. So
either way, I and the author are both sort of waiting for a committer
to
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
tim.peters wrote:
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
Hye-Shik Chang wrote:
On 4/25/06, Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote:
Thanks for the answer, but after application of a patch on python-2.4.3
I could not compile it. A conclusion of a stage of compilation in the
attached file.
Aah. The patch is for Python in
On Tue, Apr 25, 2006 at 06:04:12PM -0400, Jim Jewett wrote:
So how are the committers supposed to even know that it is waiting for
assessment? The solutions that I've seen work are
Could we mark the bug/patch as status 'pending'? This status exists
in the SF bug tracker but no bugs or patches
a friend of mine suggested this, and i thought i should share it with the mailing list.many times when you would want to use list/generator comprehensions, you have tofall back to the old for/append way, because of exceptions. so it may be a good idea
to allow an exception handling mechanism in
[EMAIL PROTECTED] wrote on
25/04/2006 13:22:27:
Neil Hodgson [EMAIL PROTECTED] writes:
Martin v. Löwis:
Apparently, the status of this changed right now: it seems that
the 2003 compiler is not available anymore; the page now says
that it was replaced with the 2005 compiler.
Hi - I'm looking at implementing Python as a scripting language for an existing C++ code base. However, there are many interdependencies between the C++ modules that I already have, and I'm not sure how to deal with this in a Python context. I thought this would be the appropriate place to pose my
The following PEPs are open according to PEP 0 and haven't seen much
activity recently IIRC. I'd like everyone to take a cut and bring
these up to date. For all the PEPs that aren't going anywhere, can we
close them? Please update your PEP if appropriate.
PEP 237 mentions changing an
Neal S 266 Optimizing Global Variable/Attribute Access Montanaro
Should be closed/rejected. I assume this concept will not be address in 2.x
but resurface in a completely different form in 3.x.
Neal S 304 Controlling Generation of Bytecode Files Montanaro
Probably ditto.
A.M. Kuchling wrote:
On Tue, Apr 25, 2006 at 06:04:12PM -0400, Jim Jewett wrote:
So how are the committers supposed to even know that it is waiting for
assessment? The solutions that I've seen work are
Could we mark the bug/patch as status 'pending'? This status exists
in the SF
Brett Cannon wrote:
I created patch 1474907 with a fix for it. Checks if %zd works for
size_t and if so sets PY_FORMAT_SIZE_T to z, otherwise just doesn't
set the macro def.
Assigned to Martin to make sure I didn't foul it up, but pretty much
anyone could probably double-check it.
Have never seen such an answer before. Please excuse if I read it
wrong. The method would just return the new values, for shure. That is
what it shall do. The interpreter calls that method for receiving the
new (to be used) values to pass them on to the real target (the called
attribute). The
[EMAIL PROTECTED] wrote:
[...]
Should be closed/rejected. [...]
Neal S 304 Controlling Generation of Bytecode Files Montanaro
Probably ditto.
Rejected would be a wrong description, IMO; withdrawn describes it
better. It's not that the feature is undesirable or the specific
At 11:55 PM 4/25/2006 -0700, Neal Norwitz wrote:
S 243 Module Repository Upload Mechanism Reifschneider
This one needs to be withdrawn or updated - it totally doesn't match the
implementation in Python 2.5.
S 302 New Import Hooks JvR, Moore
Michael Hearne wrote:
If I want to keep these classes as distinct modules, but retain this
kind of module interdependency, how can I architect this with Python?
Please understand that python-dev is for discussions about the
development *of* Python, not for the development *with* Python.
Use
Neal Norwitz wrote:
The following PEPs are open according to PEP 0 and haven't seen much
activity recently IIRC. I'd like everyone to take a cut and bring
these up to date. For all the PEPs that aren't going anywhere, can we
close them? Please update your PEP if appropriate.
S 298
(Context: There's a large crowd with pitchforks and other sharp pointy
farm implements just outside the door of my office at Google. They are
making an unbelievable racket. It appears they are Google engineers
who have been bitten by a misfeature of Python, and they won't let me
go home before I
To bring the real problem more upfront. Up to now, inheriting classes
is all about processing (the output channel) but not about retrieving
(the input channel). However, though a new type can advance from an
existing type if it just needs to provide some few more methods, it can
not advance from
* 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
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.
So this would mean that current non-package subdirectories in a package
(that contain things like data files or configuration info) would become
On 4/26/06, André Malo [EMAIL PROTECTED] wrote:
* 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
On 4/26/06, Benji York [EMAIL PROTECTED] wrote:
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.
So this would mean that current non-package subdirectories in a package
(that contain things like
I doubt you'll get many answers. I have no idea what you're talking
about. How about an example or two?
On 4/26/06, Dennis Heuer [EMAIL PROTECTED] wrote:
To bring the real problem more upfront. Up to now, inheriting classes
is all about processing (the output channel) but not about retrieving
tomer filiba [EMAIL PROTECTED] wrote:
[ expr for expr in expr [if cond] [except
exception-class-or-tuple: action] ]
Note that of the continue cases you offer, all of them are merely simple
if condition (though the file example could use a better test than
os.path.isfile).
[x for x in a if
[Brett Cannon]
I created patch 1474907 with a fix for it. Checks if %zd works for
size_t and if so sets PY_FORMAT_SIZE_T to z, otherwise just doesn't
set the macro def.
Assigned to Martin to make sure I didn't foul it up, but pretty much
anyone could probably double-check it.
[Martin v.
On 4/26/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-04-26 at 10:16 -0700, 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
* Guido van Rossum wrote:
On 4/26/06, André Malo [EMAIL PROTECTED] wrote:
* 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
At 10:16 AM 4/26/2006 -0700, 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.
Note that many tools exist which have grown to rely on the presence of
__init__ modules. Also, although your proposal
At 02:07 PM 4/26/2006 -0400, Phillip J. Eby wrote:
def find_module(self, fullname, path=None):
# Note: we ignore 'path' argument since it is only used via
meta_path
subname = fullname.split(.)[-1]
if os.path.isdir(os.path.join(self.path,
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 implementations.
In the case of
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/26/06, Benji York [EMAIL PROTECTED] wrote: 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.
I don't particularly like it. You still need
Sounds a bit like the tail wagging the dog. I thought the Google geeks
were a smart bunch.
ISTM that something like Phillip Eby's code would be the most
expedient solution. I would add one extension: if a package directory
without an __init__.py file *is* encountered, an empty __init__.py
file
On 4/26/06, André Malo [EMAIL PROTECTED] wrote:
* Guido van Rossum wrote:
On 4/26/06, André Malo [EMAIL PROTECTED] wrote:
* 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
On 4/26/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:16 AM 4/26/2006 -0700, 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.
Note that many tools exist which have grown to rely on the presence
Guido van Rossum wrote:
On 4/26/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-04-26 at 10:16 -0700, 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
* Guido van Rossum wrote:
[me]
Actually I have no problems with the change from inside python, but
from the POV of tools, which walk through the directories,
collecting/separating python packages and/or supplemental data
directories. It's an explicit vs. implicit issue, where implicit
Guido van Rossum wrote:
On 4/26/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:16 AM 4/26/2006 -0700, 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.
Note that many tools exist which have grown
On Wednesday 26 April 2006 15:05, André Malo wrote:
Another point is that one can even hide supplementary packages within such
a subdirectory. It's only visible to scripts inside the dir (I admit, that
the latter is not a real usecase, just a thought that came up while
writing this up).
I
tomer filiba [EMAIL PROTECTED] wrote:
first, i posted it two days ago, so it's funny it got posted only now...
the moderators are sleeping on the job :)
I don't believe python-dev has moderators...or at least my posts have
never been delayed like that.
Note that of the continue cases you
Guido van Rossum wrote:
On 4/26/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-04-26 at 10:16 -0700, 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
At 11:50 AM 4/26/2006 -0700, Guido van Rossum wrote:
I'm not sure what you mean by one directory read. You'd have to list
the entire directory, which may require reading more than one block if
the directory is large.
You have to do this to find an __init__.py too, don't you? Technically,
Phillip J. Eby wrote:
My counter-proposal: to be considered a package, a directory must contain
at least one module (which of course can be __init__). This allows the is
it a package? question to be answered with only one directory read, as is
the case now. Think of it also as a nudge in
On Wed, Apr 26, 2006, Josiah Carlson wrote:
tomer filiba [EMAIL PROTECTED] wrote:
first, i posted it two days ago, so it's funny it got posted only now...
the moderators are sleeping on the job :)
I don't believe python-dev has moderators...or at least my posts have
never been delayed
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] 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
At 09:56 PM 4/26/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
My counter-proposal: to be considered a package, a directory must contain
at least one module (which of course can be __init__). This allows the
is
it a package? question to be answered with only one directory read,
Phillip J. Eby wrote:
At 11:50 AM 4/26/2006 -0700, Guido van Rossum wrote:
I'm not sure what you mean by one directory read. You'd have to list
the entire directory, which may require reading more than one block if
the directory is large.
You have to do this to find an __init__.py too,
Phillip J. Eby wrote:
I assume you want
import x.y
to fail if y is an empty directory (or non-empty, but without .py
files). I don't see a value in implementing such a restriction.
No, I'm saying that tools which are looking for packages and asking, Is
this directory a package? should
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
(Context: There's a large crowd with pitchforks and other sharp pointy
farm implements just outside the door of my office at Google. They are
making an unbelievable racket. It appears they are Google engineers
who
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
At 04:33 PM 4/26/2006 -0400, Joe Smith wrote:
It seems to me that the right way to fix this is to simply make a small
change to the error message.
On a failed import, have the code check if there is a directory that would
have been the requested package if
it had contained an __init__ module. If
At 01:49 PM 4/26/2006 -0700, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
I know exactly how you feel. :)
But there's always Python 3.0, and if
On 4/26/06, Terry Jones [EMAIL PROTECTED] wrote:
I would suggest adding a hook to their version control system to
automatically create (and preferably also check out) an __init__.py file
whenever a new (source code) directory was placed under version control
(supposing you can distinguish
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 of single bytes in the
array, it provides
On 4/26/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:49 PM 4/26/2006 -0700, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
I know exactly
On Apr 26, 2006, at 4:49 PM, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
No, you can not make a change which has a tiny (and arguably
Phillip J. Eby [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
It might also be good to check that the directory actually contained
python
modules.
This is a great idea, but might be hard to implement in practice with the
current C implementation of import, at least for the general
I still don't understand what you are asking for. However there's one
problem with your code:
On 4/26/06, Dennis Heuer [EMAIL PROTECTED] wrote:
class bitarray(long):
...
def __setitem__(self, key, value):
[...]
long.__add__(2**key * value) # Should actually overwrite the
Josiah Carlson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Then again, you already have your own implementation of a tree module,
and it seems as though you would like to be paid for this already-done
work. I don't know how google feels about such things,
They are explicitly
Joe Smith wrote:
It seems to me that the right way to fix this is to simply make a small
change to the error message.
On a failed import, have the code check if there is a directory that would
have been the requested package if
it had contained an __init__ module. If there is then append a
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OK, forget it. I'll face the pitchforks.Maybe this'll help:http://python.org/sf/1477281 (You can call it 'oldtimer-repellant' if you want to use it to convince people there isn't any *real* backward-compatibility issue.)
I'm disappointed though
On 4/26/06, Thomas Wouters [EMAIL PROTECTED] wrote:
On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OK, forget it. I'll face the pitchforks.
Maybe this'll help:
http://python.org/sf/1477281
(You can call it 'oldtimer-repellant' if you want to use it to convince
people there
On 4/27/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/26/06, Thomas Wouters [EMAIL PROTECTED] wrote: On 4/26/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OK, forget it. I'll face the pitchforks. Maybe this'll help: http://python.org/sf/1477281 (You can call it 'oldtimer-repellant' if you
Guido van Rossum wrote:
http://python.org/sf/1477281
(You can call it 'oldtimer-repellant' if you want to use it to
convince people there isn't any *real* backward-compatibility issue.)
I'd worry that it'll cause complaints when the warning is incorrect
and a certain directory is being
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 know what you wanted, let me do it
for you, first of all
On 4/26/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
I really think it would be more useful having an ImportError containing
a suggestion than having a warning. Anyone who knows it's bogus can just
ignore it.
That's effectively what Thomas's patch does though -- if at the end
the path
Guido van Rossum wrote:
The difference is that if you find a valid module package later on the
path, you'll still get warnings.
This is the bit I don't like about it. Currently the warnings are
displayed as the packages are found. I'd be quite happy with the
warnings if they were suppressed
At 01:10 AM 4/27/2006 +0200, Thomas Wouters wrote:
On 4/27/06, Guido van Rossum mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
I'd worry that it'll cause complaints when the warning is incorrect
and a certain directory is being skipped intentionally. E.g. the
string directory that someone had.
On 4/26/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Potential packages later in the path won't be
warned about. If you're trying to resolve import problems, it's just as
likely that the package you really want is later in sys.path than
earlier.
But module hiding is a feature, and
At 04:57 PM 4/26/2006 -0700, Guido van Rossum wrote:
On 4/26/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Possibly. Perhaps it would be useful to have `is_package(dirname)`,
`is_rootpackage(dirname)` and `is_subpackage(dirname)` functions
somewhere (pkgutils?).
YAGNI. Also note that
first, i posted it two days ago, so it's funny it got posted only now... the moderators are sleeping on the job :)anyway. Note that of the continue cases you offer, all of them are merely simple
if conditionyes, i said that explicitly, did you *read* my mail?but i also said it's not always
On Thursday 27 April 2006 05:50, Phillip J. Eby wrote:
Anyway, I'm not opposed to the idea of supporting this in future
Pythons, but I definitely think it falls under the but sometimes
never is better than RIGHT now rule where 2.5 is concerned. :)
I agree fully. I don't think we should try
On Thursday 27 April 2006 06:49, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change
anything about Python any more because it will upset the oldtimers.
I'm not averse to changing this - just not to changing it on
On 4/26/06, Anthony Baxter [EMAIL PROTECTED] wrote:
On Thursday 27 April 2006 06:49, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change
anything about Python any more because it will upset the oldtimers.
I'm not
Boy, threads here sure move fast when there's work to be done :).
Although largely moot now, I'll follow up for posterity's sake.
On Wed, 2006-04-26 at 10:59 -0700, Guido van Rossum wrote:
Oh, cool gray area. I propose that if there's no __init__.py it prints
'path/sub1/sun2/' i.e. with a
On Wednesday 26 April 2006 22:42, Barry Warsaw wrote:
So I suspect
you're right when you say that if the rule had already been relaxed and
you were now proposing to tighten the rules, we probably get just as
many complaints.
Indeed. I think the problem many of us have with the proposal
On 4/26/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
Indeed. I think the problem many of us have with the proposal isn't the new
behavior, but the change in the behavior. That's certainly it for me.
Which is why I said earlier that I felt disappointed that we can't
change anything any
On 4/25/06, Thomas Heller [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
here is the rough draft of the PEP for packages maintained externally
from Python itself. There is some missing, though, that I would like
help filling in.
I don't know who to list as the contact person (i.e., the
On 4/26/06, Gerhard Häring [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
here is the rough draft of the PEP for packages maintained externally
from Python itself. There is some missing, though, that I would like
help filling in.
I don't know who to list as the contact person (i.e., the
On Wed, Apr 26, 2006, Guido van Rossum wrote:
Which is why I said earlier that I felt disappointed that we can't
change anything any more.
I've been here since Python 1.5.1. I don't understand why this issue in
particular makes you feel disappointed. I also think your statement is
just plain
On 4/26/06, Gerhard Häring [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
OK, I am going to write the PEP I proposed a week or so ago, listing
all modules and packages within the stdlib that are maintained
externally so we have a central place to go for contact info or where
to report bugs
On 4/26/06, Tim Peters [EMAIL PROTECTED] wrote:
[Brett Cannon]
I created patch 1474907 with a fix for it. Checks if %zd works for
size_t and if so sets PY_FORMAT_SIZE_T to z, otherwise just doesn't
set the macro def.
Assigned to Martin to make sure I didn't foul it up, but pretty much
Dennis Heuer wrote:
The reason why I'd like to use the long type as the base of my bitarray
type is that the long type is already implemented as an array and
working efficiently with large amounts of bytes.
This is wrong; you are mixing up the is-a and has-a relationships.
While it might be
95 matches
Mail list logo
