Hi,
a while ago, Raymond proposed str.partition, and I guess the reaction
was positive. So what about including it now?
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Nick Coghlan wrote:
Georg Brandl wrote:
Hi,
some time ago, someone posted in python-list about icons using the Python
logo from the new site design [1]. IMO they are looking great and would
be a good replacement for the old non-scaling snakes on Windows in 2.5.
Those are *really* pretty
Greg Ewing wrote:
Trent Mick wrote:
try:
import xml.etree.ElementTree as ET # in python =2.5
except ImportError:
... etc ad nauseam
For situations like this I've thought it might
be handy to be able to say
import xml.etree.ElementTree or cElementTree or \
Nick Coghlan wrote:
Georg Brandl wrote:
Greg Ewing wrote:
Trent Mick wrote:
try:
import xml.etree.ElementTree as ET # in python =2.5
except ImportError:
... etc ad nauseam
For situations like this I've thought it might
be handy to be able to say
import
Michael Hudson wrote:
Tim Peters [EMAIL PROTECTED] writes:
_Perhaps_ it's the case that doubles are aligned to an 8-byte boundary
when socketmodule.c is compiled, but (for some unknown reason) only to
a 4-byte boundary when _ssl.c is compiled. Although that seems to
match the details in
Seo Sanghyeon wrote:
Can someone have a look at #860326? I got bitten by it today, and I can
see no reason not to apply suggested patch.
I've reviewed it and checked it in.
Cheers,
Georg
___
Python-Dev mailing list
Python-Dev@python.org
Georg Brandl wrote:
Seo Sanghyeon wrote:
Can someone have a look at #860326? I got bitten by it today, and I can
see no reason not to apply suggested patch.
I've reviewed it and checked it in.
Hm. This broke a few doctests. I can fix them, but I wonder if
doctest should accept a bare
Tim Peters wrote:
[georg.brandl]
Author: georg.brandl
Date: Wed Apr 12 23:14:09 2006
New Revision: 45321
Modified:
python/trunk/Lib/test/test_traceback.py
python/trunk/Lib/traceback.py
python/trunk/Misc/NEWS
Log:
Patch #860326: traceback.format_exception_only() now prepends the
Mikhail Glushenkov wrote:
Hi,
sorry if this came up before, but I tried searching the archives and
found nothing. It would be really nice if new builtin truth functions
in 2.5 took a predicate argument(defaults to bool), so one could
write, for example:
seq = [1,2,3,4,5]
if any(seq,
Tim Peters wrote:
[Georg Brandl]
Well, it's tempting to let the buildbots run the tests for you wink
Honestly, I didn't realize that doctest relies on traceback. Running
the test suite takes over half an hour on this box, so I decided to
take a chance.
Nobody ever expects that a checkin
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
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
Martin v. Löwis wrote:
Neal Norwitz wrote:
Who is the owner for getting new icons installed with the new logo?
Nobody, so far (for Windows). Somebody should contact the owner and
find out what the license on this work is, and then tell me what
to do with them. I assume the py and pyc icons
Is there a reason why the alternate format isn't documented for float
conversions in http://docs.python.org/lib/typesseq-strings.html ?
'%#8.f' % 1.0 keeps the decimal point while '%8.f' % 1.0 drops it.
Also, for %g the alternate form keeps trailing zeroes.
While at it, I noticed a difference
Georg Brandl wrote:
Is there a reason why the alternate format isn't documented for float
conversions in http://docs.python.org/lib/typesseq-strings.html ?
'%#8.f' % 1.0 keeps the decimal point while '%8.f' % 1.0 drops it.
Also, for %g the alternate form keeps trailing zeroes.
While
Neal Norwitz wrote:
Here's what's left for 2.5 after the most recent go around.
There's no owner for these items. If no one takes them, they won't
get done and I will move them to deferred within a week:
* Add @decorator decorator to functional, rename to functools?
What's the
A.M. Kuchling wrote:
On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote:
- Warn-raise ImportWarning when importing would have picked up a directory
as package, if only it'd had an __init__.py. This swaps two tests (for
case-ness and __init__-ness), but case-test is not
Recently, the inspect module was updated to conform with PEP 302.
Now this is broken:
import inspect
inspect.stack()
The traceback shows clearly what's going on. However, I don't know how
to resolve the problem.
Georg
___
Python-Dev mailing list
Nick Coghlan wrote:
Collin Winters has done the work necessary to rename PEP 309's functional
module to functools and posted the details to SF [1].
I'd like to take that patch, tweak it so the C module is built as _functools
rather than functools, and then add a functools.py consisting of:
Guido van Rossum wrote:
On 4/30/06, Georg Brandl [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Collin Winters has done the work necessary to rename PEP 309's functional
module to functools and posted the details to SF [1].
I'd like to take that patch, tweak it so the C module is built
Zachary Pincus wrote:
Some thoughts from a lurker, largely concerning syntax; discount as
you wish.
First:
Keyword-only arguments are not required to have a default value.
Since Python requires that all arguments be bound to a value,
and since the only way to bind a value
Zachary Pincus wrote:
I'm not sure about introducing a special syntax for accessing
dictionary entries, array elements and/or object attributes *within a
string formatter*... much less an overloaded one that differs from
how these elements are accessed in regular python.
Yes, I also
Guido van Rossum wrote:
Backticks certainly are deprecated -- Py3k won't have them (nor will
they become available for other syntax; they are undesirable
characters due to font issues and the tendency of word processing
tools to generate backticks in certain cases where you type forward
Guido van Rossum wrote:
I see test failures in current HEAD on my Google Red Hat Linux desktop
that the buildbots don't seem to have:
./python -E -tt ../Lib/test/regrtest.py test_ctypes
test_ctypes
test test_ctypes failed -- errors occurred; run in verbose mode for details
More details
Heiko Wundram wrote:
Anyway, back on topic, I personally agree with the people who posted to
comp.lang.python that --version (and possibly --help, possibly other long
parameters too) would be useful additions to Pythons command-line parameters,
as it's increasingly getting more common
xahlee wrote:
I do not wish to be the subject of mobbing here.
If you have opinions on what i wrote, respond to the subject on topic
as with any discussion. Please do not start a gazillion war-cry on me.
If you cannot tolerate the way i express my opinions, at this moment
write a
Martin v. Löwis wrote:
Georg Brandl wrote:
Similary, there's no way for a structmember to be of type Py_ssize_t...
Right. At least, not with changing structmember.[ch].
Did you mean without? Can I submit a patch?
Georg
___
Python-Dev mailing list
Martin v. Löwis wrote:
Guido van Rossum wrote:
It seems I have libz 1.1.4. Is this no longer supported?
Apparently so. This function started to be used with
r46012 | georg.brandl | 2006-05-16 09:38:27 +0200 (Di, 16
While working on a patch involving sys.path_importer_cache, I discovered
that if a path_hooks import hook has been found for a given sys.path entry,
but isn't able to import a specific module, find_module() tries to import
the module from this sys.path entry as a regular file.
This results in
Martin v. Löwis wrote:
Fredrik Lundh wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
I can't find this inconsistency horrible.
py +Hello
Traceback (most
Georg Brandl wrote:
Martin v. Löwis wrote:
Fredrik Lundh wrote:
-1 * (1, 2, 3)
()
-(1, 2, 3)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: bad operand type for unary -
We Really Need To Fix This!
I can't find this inconsistency horrible.
py
I've worked on two patches for NeedForSpeed, and would like someone
familiar with the areas they touch to review them before I check them
in, breaking all the buildbots which aren't broken yet ;)
They are:
http://python.org/sf/1346214
Better dead code elimination for the AST compiler
Facundo Batista wrote:
2006/5/26, Sean Reifschneider [EMAIL PROTECTED]:
On Fri, May 26, 2006 at 12:37:02PM -0300, Facundo Batista wrote:
- Treat the negative as a reverser, so we get back (3, 2, 1).
Then we could get:
print -123
321
An integer is NOT a sequence.
OTOH, that
Fredrik Lundh wrote:
Sean Reifschneider wrote:
- Treat the negative as a reverser, so we get back (3, 2, 1).
Then we could get:
print -123
321
Yay!
and while we're at it, let's fix this:
0.66 * (1, 2, 3)
(1, 2)
and maybe even this
0.5 * (1, 2, 3)
In the process of reviewing and possibly extending getargs.c, I stumbled
over the compatibility flag supposedly used for METH_OLDARGS functions.
No code in the core uses this calling convention any more, and it has been
deprecated for quite a long time (since 2.2), so would it be appropriate to
Michael Hudson wrote:
So I think I'll be reading through exceptions.c pretty carefully. I
don't think Sean and Richard have acquired as much paranoid
anal-mindedness and I have when hacking on Python C internals yet :)
I intended to go through the code again today or tomorrow, looking for
Neal Norwitz wrote:
On 5/28/06, Georg Brandl [EMAIL PROTECTED] wrote:
In the process of reviewing and possibly extending getargs.c, I stumbled
over the compatibility flag supposedly used for METH_OLDARGS functions.
No code in the core uses this calling convention any more, and it has been
Michael Hudson wrote:
Georg Brandl [EMAIL PROTECTED] writes:
Michael Hudson wrote:
So I think I'll be reading through exceptions.c pretty carefully. I
don't think Sean and Richard have acquired as much paranoid
anal-mindedness and I have when hacking on Python C internals yet :)
I
Michael Hudson wrote:
Michael Hudson [EMAIL PROTECTED] writes:
I think I've fixed the refleaks too, but running regrtest -R :: takes
rther a while.
I hadn't: test_codecs and test_codeccallbacks both leak, the latter
quite spectacularly (9000+ refleaks a run). The test_codecs leaks
Fredrik Lundh wrote:
Terry Reedy wrote:
def isgenerator(func):
return func.func_code.co_flags == 99
but it is rather ugly (horrible indeed).
To me, part of the beauty of Python is that is so easy to write such things
so compactly, so that we do not need megaAPIs with hundreds of
Thomas Wouters wrote:
On 5/29/06, *Fredrik Lundh* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
this is a clear case of unnecessary meddling. removing it won't remove
much code (a whopping 11 lines is dedicated to this), nor give any speed
ups whatsoever; all you're
Martin v. Löwis wrote:
Georg Brandl wrote:
Isn't there at least a GCC __attribute__((deprecated))?
Yes, but it applies to functions only. I guess you could make
a __deprecated__ function, and then expand METH_OLDARGS to a
call of that function. That won't help in cases where
Martin v. Löwis wrote:
Guido van Rossum wrote:
I think that should be done for 2.5, but nothing else. Or, perhaps
a deprecation warning could be generated if it is still used.
I'll let Martin decide this one.
I just sent a message to some that producing a DeprecationWarning is
fine, but
Fredrik Lundh wrote:
Georg Brandl wrote:
I'd be satisfied with a deprecation warning for PyArg_Parse, though we
(*) should really figure out how to make it work on Windows. I
haven't seen anyone object to the C compiler deprecation warning.
There is something at
http://msdn2
Martin Blais wrote:
Hi all
I'd like to know what the policy is on the source code indentation for
C code in the interpreter. At the Need-for-Speed sprints, there was
consensus that there is a new indentation for style for the Python C
source files, with
* indentation (emacs:
Looking at #1153226, I found this:
We introduced emitting a DeprecationWarning for PyArg_ParseTuple
integer arguments if a float was given. This doesn't affect functions
like file.seek which use PyInt_AsLong to parse their argument.
PyInt_AsLong calls the nb_int slot which silently converts
Michele Simionato wrote:
Neal Norwitz nnorwitz at gmail.com writes:
I wonder whether a check shouldn't just return (co_flags 0x20), which
is CO_GENERATOR.
Makes more sense.
Okay, but my point is that the final user should not be expected to know
about those implementation details.
Michele Simionato wrote:
Georg Brandl g.brandl at gmx.net writes:
I'd say, go ahead and write a patch including docs, and I think there's no
problem with accepting it (as long as it comes before beta1).
I was having a look at http://docs.python.org/dev/lib/inspect-types.html
and it would
Michele Simionato wrote:
Georg Brandl g.brandl at gmx.net writes:
Also, should one add
a GeneratorType, perhaps as a subclass of FunctionType?
Add GeneratorType where? There is already one in the types module.
Yep, this is the crux. types.GeneratorType refers to generator objects
The S/390 buildbot should be renamed. While the URLs
buildbot generates in its email messages work, the
ones that are on the overview page don't.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Phillip J. Eby wrote:
At 09:53 PM 5/31/2006 +0200, Collin Winter wrote:
Hi Phillip,
Do you have any opinion on this patch (http://python.org/sf/1473257),
which is assigned to you?
I didn't know it was assigned to me. I guess SF doesn't send any
notifications, and neither did Georg, so your
Collin Winter wrote:
I recently submitted a patch that would optimise in (5, 6, 7) (ie,
in ops on constant tuples) to in frozenset([5, 6, 7]). Raymond
Hettinger rejected (rightly) the patch since it's not semantically
consistent. Quoth:
Sorry, this enticing idea has already been explored
Georg Brandl wrote:
I've worked on two patches for NeedForSpeed, and would like someone
familiar with the areas they touch to review them before I check them
in, breaking all the buildbots which aren't broken yet ;)
They are:
http://python.org/sf/1346214
Better dead code elimination
Collin Winter wrote:
On 6/4/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 6/3/06, Georg Brandl [EMAIL PROTECTED] wrote:
Collin Winter wrote:
Idea: what if Python's -O option caused PySequence_Contains() to
convert all errors into False return values?
It would certainly give me
Thomas Wouters wrote:
On 6/8/06, *M.-A. Lemburg* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
Perhaps it's a new feature in gcc 4.0 that makes the slow-down I see
turn into a speedup :-)
It seems so. I tested with gcc 2.95, 3.3 and 4.0 on FreeBSD 4.10 (only
machine I
Chris AtLee wrote:
On 5/21/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Then options 2 and 3 are both fine.
Not compiling at all is *not*, so if nobody has time to implement 2 or
3, we'll have to do 4.
--Guido
Is this thread still alive?
At least I still have this on my todo list.
Nick Coghlan wrote:
Kevin Jacobs [EMAIL PROTECTED] wrote:
Try this at home:
import collections
d=collections.defaultdict(int)
d.iterkeys().next() # Seg fault
d.iteritems().next() # Seg fault
d.itervalues().next() # Fine and dandy
This all worked fine for me in rev 46739 and 46849
Guido van Rossum wrote:
Yup, although it's a change in behavior that would need to be studied
carefully for backwards incompatibilities. Usually it's given as a
constant, so there won't be any problems; but there might be code that
receives a mode string and attempts to test its validity by
Guido van Rossum wrote:
On 6/12/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Yup, although it's a change in behavior that would need to be studied
carefully for backwards incompatibilities. Usually it's given as a
constant, so there won't be any problems
I've just closed a bug report wishing for long option support,
pointing to a patch sitting in the patch tracker implementing
this.
Should we accept at least the very common options --help and
--version in 2.5?
Georg
___
Python-Dev mailing list
Georg Brandl wrote:
In abstract.c, there are many error messages like
type_error(object does not support item assignment);
It helps debugging if the object's type was prepended.
Should I go through the code and try to enhance them
where possible?
So that's definite perhaps?
Anyway
Guido van Rossum wrote:
On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
I say, let someone give a complete implementation a try, and then try
to modify as much standard library code as possible to use it. Then
report back. That would be a very interesting experiment to do. (And
Ka-Ping Yee wrote:
On Wed, 21 Jun 2006, Phillip J. Eby wrote:
Well, EIBTI and all that:
switch x:
case == 1: foo(x)
case in S: bar(x)
It even lines up nicely. :)
Hmm, this is rather nice. I can imagine possible use cases for
switch x:
case 3:
Ralf W. Grosse-Kunstleve wrote:
http://docs.python.org/dev/whatsnew/ports.html says:
The PyRange_New() function was removed. It was never documented, never used
in the core code, and had dangerously lax error checking.
I use this function (don't remember how I found it; this was years
Guido van Rossum wrote:
I've also been wondering whether the 'case' keyword is really necessary?
Would any ambiguities or other parsing problems arise if you wrote:
switch x:
1: foo(x)
2: bar(x)
It is debatable whether this is more or less readable, but it seemed
Guido van Rossum wrote:
On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I've also been wondering whether the 'case' keyword is really necessary?
Would any ambiguities or other parsing problems arise if you wrote:
switch x:
1: foo(x
Ralf W. Grosse-Kunstleve wrote:
--- Georg Brandl [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve wrote:
http://docs.python.org/dev/whatsnew/ports.html says:
The PyRange_New() function was removed. It was never documented, never
used
in the core code, and had dangerously lax error
M.-A. Lemburg wrote:
A nice side-effect would be that could easily use the
same approach to replace the often used default-argument-hack,
e.g.
def fraction(x, int=int, float=float):
return float(x) - int(x)
This would then read:
def fraction(x):
const int, float
return
Raymond Hettinger wrote:
No thanks. That is its own can of worms. The obvious solutions (like const
declarations, macros, or a syntax to force compile-time expression
evaluation)
are unlikely to sit well because they run afoul Python's deeply ingrained
dynamism.
I think perhaps you
Guido van Rossum wrote:
On 6/27/06, Greg Ewing [EMAIL PROTECTED] wrote:
Giovanni Bajo wrote:
This is where I wonder why the def __main__() PEP was rejected in the
first place. It would have solved this problem as well.
Could this be reconsidered for Py3k?
You have a point.
Added to
In followup to a clpy discussion, should the docs contain
a note that property can be used as a decorator for creating
read-only properties?
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Hi,
the following patch tries to fix the LOAD_CONST POP_TOP optimization
lost in 2.5 (bug #1333982).
An example for this is:
def f():
'a' # docstring
'b'
Georg
PS: Hmm. While looking, I see that 2.4 doesn't optimize away other constants
like
def g():
1
Index: Python/compile.c
[EMAIL PROTECTED] wrote:
Noam Raphael posted an empty subscript PEP on the Python Wiki:
http://wiki.python.org/moin/EmptySubscriptListPEP
It's not linked to by any other pages on the wiki. Is there a reason it
wasn't added to the peps repository?
Perhaps the author forgot to submit
Georg Brandl wrote:
In string_replace, there is
if (PyString_Check(from)) {
/* Can this be made a '!check' after the Unicode check? */
}
#ifdef Py_USING_UNICODE
if (PyUnicode_Check(from))
return PyUnicode_Replace((PyObject *)self
Fredrik Lundh wrote:
Georg Brandl wrote:
Can this be correct if from or to isn't a string object, but a
char buffer compatible object?
May I note that this is still unresolved? I can submit a bug report
and add it to PEP 356, too...
it's already on my todo list, but that list is full
[EMAIL PROTECTED] wrote:
Facundo I need a timeout in urlopen, just to be able to make:
urllib2.urlopen(http://no.host.org;, timeout=2)
Facundo This is actually not possible, but I'll make it work.
Facundo I want to know, please, if this is useful in general, for me to
Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:18 AM 7/5/2006 +0200, Guido van Rossum wrote:
I don't see anything else that's attractive. The realistic options are:
1. do nothing
2. extend global's meaning
3. add outer keyword
Did you also consider and
Tim Peters wrote:
Back in:
http://mail.python.org/pipermail/python-dev/2005-March/051856.html
I made a pitch for adding:
sys._current_frames()
to 2.5, which would return a dict mapping each thread's id to that
thread's current (Python) frame. As noted there, an extension
Richard Jones wrote:
On 09/07/2006, at 9:05 AM, Anthony Baxter wrote:
I'm really not keen on this seeming tide of new features wink that
seem to be popping up. We're only a few days away from the second and
final planned beta - it's getting _awfully_ late to be slotting in
new features.
Anthony Baxter wrote:
There's an open PEP-356 issue for update the icons to the newer
shinier ones for Unix. As far as I can see, there's the 14x15 GIF
images used for Idle and the documentation. Note that for me at least,
idle comes up without an icon _anyway_.
Are there any others I
Russell E. Owen wrote:
I'd like to have the get method available for lists and tuples. (I
figured this must have been discussed before but can't recall it and
didn't turn anything up on google).
It's obviously not a use-all-the-time method (or it'd already be there),
but I find myself
_anyway_.
A pyfav.(gif|png) replacement would be quite welcome!
On Tuesday 11 July 2006 13:25, Georg Brandl wrote:
In case we add a Python .desktop file (as proposed in patch #1353344),
we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in
is attached.
I know the .desktop
Anthony Baxter wrote:
On Wednesday 12 July 2006 03:39, Georg Brandl wrote:
Anyway, I'm just testing the waters. If it's not heresy then I'd
like to do what I can to make it happen.
IMO there's almost no chance this can go into 2.5.
almost?
I'll go you one better. No way at all
Martin v. Löwis wrote:
Georg Brandl wrote:
In case we add a Python .desktop file (as proposed in patch #1353344),
we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in
is attached.
Independent of whether this should be done at all, I have a comment on
the patch. Instead
Fredrik Lundh wrote:
Georg Brandl wrote:
I've just closed a bug report wishing for long option support,
pointing to a patch sitting in the patch tracker implementing
this.
Should we accept at least the very common options --help and
--version in 2.5?
Guido pronounced on this in May
Barry Warsaw wrote:
Just as 2.5b2 was being release, I updated SF patch #1520294:
https://sourceforge.net/tracker/index.php?
func=detailaid=1520294group_id=5470atid=305470
This fixes the pydoc, inspect, and types modules for built-in types
like getset and member descriptors. I'm not sure
Raymond Hettinger wrote:
Aahz wrote:
On Tue, Jul 18, 2006, Raymond Hettinger wrote:
P.S. The dictionary approach to context objects should likely be
abandoned for the C version. If the API has to change a bit, then so
be it.
Why do you say that? The rest I agree with; seems to
Barry Warsaw wrote:
Why did I do this instead of trying to hunt down some existing getset
or member descriptor? For one thing, there really aren't very good
candidates for such objects in the built-in modules. You can't use
objects like datetime.timedelta.days in types.py because
Kevin Jacobs [EMAIL PROTECTED] wrote:
On 7/21/06, *Nick Coghlan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Delaney, Timothy (Tim) wrote:
Looks like there's a bug in Popen.__del__ in 2.5. I'm not in a
position
to have a look right now.
For those not
Martin v. Löwis wrote:
Neal Norwitz wrote:
# 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
Not quite sure what it is complaining about, but
else if (PyTuple_Check(closure)) {
Py_XINCREF(closure);
}
looks indeed suspicious: Why
Neal Norwitz wrote:
On 7/25/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
# 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
Not quite sure what it is complaining about, but
else if (PyTuple_Check(closure)) {
Neal Norwitz wrote:
What is the behaviour that was added which broke compliance? What is
the benefit of the behaviour?
sys.path_importer_cache is now used to cache if a real directory
exists on the filesystem. Previously, a value of None for a given
sys.path entry told find_module that no
Armin Rigo wrote:
Hi Phillip,
On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
If we don't revert it, there are two ways to fix it. One is to just change
PEP 302 so that the behavior is unbroken by definition. :) The other is
to actually go ahead and fix it by adding
The UUID test suite, which wasn't run by regrtest.py until now, is
now failing on some buildbots (and my machine). This should be fixed
before releasing something.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
Georg Brandl wrote:
The UUID test suite, which wasn't run by regrtest.py until now, is
now failing on some buildbots (and my machine). This should be fixed
before releasing something.
Okay, after fixing the test on my machine (locale issue) it looks like
some ifconfigs don't like to be called
Phillip J. Eby wrote:
sys.path_importer_cache is quite an internal thing
Whose behavior is documented in a PEP.
Correct.
and
most code, even import hooks, shouldn't have to deal with it.
That doesn't make it unimportant. It's a visible change in specified
behavior between Python
Regarding bug 469773, I think it would be great to have such a
document Using Python, containing the manual page and platform-
specific hints on how to invoke the interpreter and scripts
(e.g. explaining the shebang for Unices).
I'd be willing to help write up such a document.
Another thing
Barry Warsaw wrote:
if isinstance(obj, ClassType)
which fails in Python 2.5. I actually rewrote it like so:
if isinstance(obj, ClassType) or isinstance(obj, type(type))
The second type seems to be superfluous. ;)
Georg
___
Python-Dev mailing
Martin v. Löwis wrote:
Ralf Schmitt schrieb:
I've been trying to port our software to python 2.5.
unfortunately I'm getting constantly hit by segfaults.
I understand it's unfortunate for you, but it is fortunate
for us that you have been trying to port your application
before 2.5 was
Neal Norwitz wrote:
Things are getting better, but we still have some really important
outstanding issues. PLEASE CONTINUE TESTING AS MUCH AS POSSIBLE.
Also, it would be great to use as many tools as possible to find bugs
and improve quality. It would be especially nice to run Purify on
101 - 200 of 1517 matches
Mail list logo
