valgrind reports a problem when running test_doctest. I haven't
spotted a problem with the code, but the report is consistent (hmm, I
thought there were 3 warnings, but now there's only 1):
==19291== Conditional jump or move depends on uninitialised value(s)
==19291==at 0x49D8B5:
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
The non-fast version couldn't actually work if it referenced any names,
given current Python semantics for arbitrary name binding replacements.
Actually, one could consider case expressions to be
This is, in fact, exactly what the python trunk does right now. This is done
in exceptions.c
Kristján
-Original Message-
From: Scott Dial [mailto:[EMAIL PROTECTED]
Sent: 17. júní 2006 12:54
To: Python Dev
Cc: Martin v. Löwis; Kristján V. Jónsson
Subject: Re: [Python-Dev] Python 2.4
The signal() doc is rather vague on the point, since it doesn´t define the
availible set
of signals. It doesn´t even say that a signal identifier is an integer. But
it says that it should return EINVAL if it cannot satisfy the request. It
doesn´t say if the request is invalid, but I don't
Ideally, I would like for python to simply work. It seems to me that it is
mostly a question of time when all modern platforms offer unicode filesystems
and hence unicode APIs. IMHO, stuff like the importer should really be written
in native unicode and revert to ASCII only as a fallback for
Okay, for specifics which demonstrate the problem.
I have a directory, C:\tmp\腌
In it, there is a file, doo.py
d = os.listdir(uc:/tmp)[-1]
d
u'\u814c'
d2 = os.listdir(uc:/tmp/+d)
d2
[u'doo.py']
p = uc:/tmp/+d
p
u'c:/tmp/\u814c'
sys.path.append(p)
import doo
Traceback (most recent call last):
Well, my particular test uses u'c:/tmp/\u814c'
If that cannot be encoded in mbcs, then mbcs isn't useful.
Note that this is both an issue of python being able to run from an arbitrary
install position, and also the ability of users to import and run scripts from
any other arbitrary directory.
I don't have specific information on the machines. We didn´t try very hard to
get things to work with 2.3 since we simply assumed it would work automatically
when we upgraded to a more mature 2.4.
I could try to get more info, but it would be 2.3 specific. Have there been
any changes since
It should be noted that I once started to convert the import machinery
to be fully unicode aware. As far as I can tell, a *lot* has to be changed
to make this work.
I started with refactoring Python/import.c, but nobody responded to the question
whether such a refactoring patch would be accepted
One thing I have
often lamented having in PyString_FromFormat (and cousins, like PyErr_Format) is
to be able to integrate PyObject pointers. Adding something like %S and %R
(for str() and repr() respectively) seems very useful to me. Is there any
reason why this isn´t there?
Cheers,
Nick Maclaren [EMAIL PROTECTED] writes:
As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'
of IEEE 754 and (worse) C99.
That's not really now I would describe the situation today.
Yes, it's better, but I
Anthony Baxter [EMAIL PROTECTED] writes:
A question has been asked about branching release25-maint at the time
of beta1. I was actually thinking about doing this for 2.5rc1 - once
we're in release candidate stage we want to really be careful about
checkins. I'm not sure it's worth
Thomas Heller wrote:
It should be noted that I once started to convert the import machinery
to be fully unicode aware. As far as I can tell, a *lot* has to be changed
to make this work.
I started with refactoring Python/import.c, but nobody responded to the
question
whether such a
Brett Cannon wrote:
But it does seem accurate; random checking of some modules that got high
but not perfect covereage all seem to be instances where dependency
injection would be required to get the tests to work since they were
based on platform-specific things.
I don't know if we need
At 12:28 AM 6/19/2006 -0700, Josiah Carlson wrote:
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
The non-fast version couldn't actually work if it referenced any names,
given current Python semantics for arbitrary name binding replacements.
Benji York wrote:
Brett Cannon wrote:
But it does seem accurate; random checking of some modules that got high
but not perfect covereage all seem to be instances where dependency
injection would be required to get the tests to work since they were
based on platform-specific things.
I
Kristján V. Jónsson wrote:
Funny that no other platforms could benefit from a unicode import path.
Does that mean that windows will reign supreme? Please explain.
As near as I can tell, other platforms use encoded strings with the normal
(byte-based) posix file API, so the Python interpreter
Phillip J. Eby wrote:
Either way would work, and both would allow multiple versions of the same
switch statement to be spun off as closures without losing their
constant
nature or expressiveness. It's just a question of which one is easier to
explain. Python already has both types of
At 12:10 AM 6/20/2006 +1000, Nick Coghlan wrote:
Caching on first use would be the easiest to explain I think. Something like:
if jump_dict is NULL:
jump_dict = {FIRST_CASE : JUMP_TARGET_1,
SECOND_CASE : JUMP_TARGET_2,
THIRD_CASE :
On 6/18/06, Josiah Carlson [EMAIL PROTECTED] wrote:
[...] Offering arbitrary expressions whose
meaning can vary at runtime would kill any potential speedup (the
ultimate purpose for having a switch statement), [...]
Um, is this dogma? Wouldn't a switch statement also be a welcome
addition to
Wouldn´t it be possible then to emulate the unix way? Simply encode any
unicode paths to utf-8, process them as normal, and then decode them just prior
to the actual windows io call? It would make sense to just use the utf-8
encoding all the way for all platforms (since it is easy to work
On 6/16/06, Kristján V. Jónsson [EMAIL PROTECTED] wrote:
Although python has had full unicode support for filenames for a long time
on selected platforms (e.g. Windows), there is one glaring deficiency: It
cannot import from paths containing unicode. I´ve tried creating folders
with chinese
On 6/19/06, Kristján V. Jónsson [EMAIL PROTECTED] wrote:
One thing I have often lamented having in PyString_FromFormat (and cousins,
like PyErr_Format) is to be able to integrate PyObject pointers. Adding
something like %S and %R (for str() and repr() respectively) seems very
useful to me.
On 6/14/06, Alexander Belopolsky [EMAIL PROTECTED] wrote:
When an extension type Foo defines tp_getattr, but leaves tp_setattr
NULL, an attempt to set an attribute bar results in an AttributeError
with the message 'Foo' object has no attribute 'bar'. This message
is misleading because the
Hm... Perhaps the xml-sig would be a better place to discuss this?
On 6/11/06, Thomas Broyer [EMAIL PROTECTED] wrote:
Hi,
First, sorry for posting this here, I closed my SourceForge account a
few months ago and I can't get it reopened...
I'm using python 2.2.1 but a diff on SVN showed that
Alexander Belopolsky wrote:
1. Is there a reason not to have PySet_CheckExact, given that
PyFrozenSet_CheckExact exists? Similarly, why PyAnySet_Check, but no
PySet_Check or PyFrozenSet_Check?
If you NEED PySet_CheckExact, then say so. Adding it is trivial.
Each of the six combinations
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,
Anthony Baxter wrote:
A question has been asked about branching release25-maint at the time
of beta1. I was actually thinking about doing this for 2.5rc1 - once
we're in release candidate stage we want to really be careful about
checkins. I'm not sure it's worth branching at beta1 - it's a bit
At 09:27 AM 6/19/2006 -0700, Raymond Hettinger wrote:
Guido van Rossum wrote:
Um, is this dogma? Wouldn't a switch statement also be a welcome
addition to the readability? I haven't had the time to follow this
thread (still catching up on my Google 50%) but I'm not sure I agree
with the idea that
On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 6/18/06, Josiah Carlson [EMAIL PROTECTED] wrote:
[...] Offering arbitrary expressions whose
meaning can vary at runtime would kill any potential speedup (the
ultimate purpose for having a switch statement),
On 6/19/06, Benji York [EMAIL PROTECTED] wrote:
Brett Cannon wrote: But it does seem accurate; random checking of some modules that got high but not perfect covereage all seem to be instances where dependency injection would be required to get the tests to work since they were
based on
A switch-statement offers only a modest readability improvement over
if-elif chains.
Probably, which is why it hasn't been added yet. :-)
But there is a definite readability improvement in that you *know*
that it's always the same variable that is being compared and that no
other
Brett Cannon wrote:
Ah, do the union of the coverage! Yeah, that would be nice and give the
most accurate coverage data in terms of what is actually being tested.
But as Titus says in another email, question is how to get that data
sent back to be correlated against.
It might be
On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
A switch-statement offers only a modest readability improvement over
if-elif chains.
Probably, which is why it hasn't been added yet. :-)
But there is a definite readability improvement in that you *know*
that it's always the
On Mon, 19 Jun 2006, Guido van Rossum wrote:
Um, is this dogma? Wouldn't a switch statement also be a welcome
addition to the readability? I haven't had the time to follow this
thread (still catching up on my Google 50%) but I'm not sure I agree
with the idea that a switch should only exist
But there is a definite readability improvement in that you *know*
that it's always the same variable that is being compared and that no
other conditions are snuck into some branches.
Hmm, when I saw that arbitrary expressions were being proposed, I took
that took mean that the variable
On 6/18/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
As for the comment: It apparently *is* misleading, George mistakenly
took it as a requirement for future changes, rather than a factual
statement about the present (even though it uses the tense of simple
present). Anybody breaking 2.3
On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[...] Can we conclude that arbitrary expressions are
fine for the switch value but that the case values must be constants?
That's too strong I believe. If some or all of the cases are arbitrary
expressions the compiler should try to deal.
On 6/19/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On 6/18/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
As for the comment: It apparently *is* misleading, George mistakenly
took it as a requirement for future changes, rather than a factual
statement about the present (even though it uses the
On 6/19/06, Michael Hudson [EMAIL PROTECTED] wrote:
Nick Maclaren [EMAIL PROTECTED] writes:
2) Because some people are dearly attached to the current behaviour,
warts and all, and there is a genuine quandary of whether the 'right'
behaviour is trap-and-diagnose, propagate-NaN or
Kristján V. Jónsson wrote:
The signal() doc is rather vague on the point, since it doesn´t
define the availible set of signals. It doesn´t even say that a
signal identifier is an integer. But it says that it should return
EINVAL if it cannot satisfy the request.
What signal() doc are you
My thought is that we *should* define switching in terms of hash
tables. It builds off of existing knowledge and therefore has a near
zero learning curve. The implementation is straight-forward and there
are none of the hidden surprises that we would have with
fastpath/slowpath approaches
On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Guido]
I'm not so sure about there being no hidden surprises. I betcha that
there are quire a few bits of code that curerntly use the if/elif
style and seem to beg for a switch statement that depend on the
ordering of the tests. A
Kristján V. Jónsson wrote:
I don't have specific information on the machines. We didn´t try
very hard to get things to work with 2.3 since we simply assumed it
would work automatically when we upgraded to a more mature 2.4. I
could try to get more info, but it would be 2.3 specific. Have
Kristján V. Jónsson wrote:
Wouldn´t it be possible then to emulate the unix way? Simply encode
any unicode paths to utf-8, process them as normal, and then decode
them just prior to the actual windows io call?
That won't work. People also put path names from the ANSI code page
onto sys.path
Ka-Ping Yee wrote:
This sentiment is puzzling to me. It seems you assume that we can trust
future developers to change the code but we can't trust them to update
the documentation.
That's precisely my expectation. Suppose Python 3.0 unifies int and
long, and deprecates the L suffix. Then,
Guido van Rossum wrote:
# At the time of writing this module was compatible with Python 2.3 and
later.
:-)
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
os.path.getmtime returns a float on linux (2.5a2/b1 HEAD); in 2.4 it
returned an int. this change makes sense, its what time.time returns.
should there be a note in Misc/NEWS or whatsnew mentioning this minor
change (or did i miss it)? It breaks code that unintentionally
depended on it
[Neal Norwitz wrote on June 8th]
It's June 9 in most parts of the world. The schedule calls for beta 1
on June 14. That means there's less than 4 days until the expected
code freeze. Please don't rush to get everything in at the last
minute. The buildbots should remain green to keep
Guido van Rossum wrote:
I wonder if there should be two default clauses, or some other
syntactic way to indicate whether we expect all x to be hashable?
switch expr:
case 1:
statements
case 2:
statements
else:
statements
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Heller wrote:
Martin v. Löwis wrote:
Guido van Rossum wrote:
4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want
to get rid of it, *now* would be the time.
I'm all for it.
While I am an enthusiastic supporter of
Delaney, Timothy (Tim) wrote:
Guido van Rossum wrote:
I wonder if there should be two default clauses, or some other
syntactic way to indicate whether we expect all x to be hashable?
switch expr:
case 1:
statements
case 2:
Cameron Laird wrote:
I'm channeling a correspondent, who tells me that Python documentation
(Python 2.5 announcement, and so on) mentions compatibility of sources
with the MS free compiler; that's the default toolchain for Windows.
Apparently we're in conflict with Microsoft on that: some
http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/676/step-compile/0Looks like Tim's XP box is crapping out on a header file included from Tcl/Tk. Did the Tcl/Tk folk just break something and we are doing an external svn pull and thus got bit by it?
-Brett
On 6/19/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Cameron Laird wrote:
I'm channeling a correspondent, who tells me that Python documentation
(Python 2.5 announcement, and so on) mentions compatibility of sources
with the MS free compiler; that's the default toolchain for Windows.
Thomas Heller wrote:
It should be noted that I once started to convert the import machinery
to be fully unicode aware. As far as I can tell, a *lot* has to be changed
to make this work.
Is that code available somewhere still? Does it still work?
I started with refactoring Python/import.c,
Gregory P. Smith wrote:
os.path.getmtime returns a float on linux (2.5a2/b1 HEAD); in 2.4 it
returned an int. this change makes sense, its what time.time returns.
should there be a note in Misc/NEWS or whatsnew mentioning this minor
change (or did i miss it)? It breaks code that
On Mon, 19 Jun 2006, Guido van Rossum wrote:
If you want to encourage people to use your module
with older versions, the right path is to have a distribution (can be
very light-weight) on your own website and add it to PyPI
Okay, i've removed the comment and submitted the package to PyPI.
--
Brett Cannon wrote:
http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/676/step-compile/0
Looks like Tim's XP box is crapping out on a header file included from
Tcl/Tk. Did the Tcl/Tk folk just break something and we are doing an
external svn pull and thus got bit by it?
No,
Kristján V. Jónsson wrote:
One thing I have often lamented having in PyString_FromFormat (and
cousins, like PyErr_Format) is to be able to integrate PyObject
pointers. Adding something like %S and %R (for str() and repr()
respectively) seems very useful to me. Is there any reason why this
[Brett]
Looks like Tim's XP box is crapping out on a header file included from
Tcl/Tk. Did the Tcl/Tk folk just break something and we are doing an
external svn pull and thus got bit by it?
[Martin]
No, that comes straight out of
FYI, the tests all pass on my box again. Going offline line to check the disk.
...
I probably left the 2.4 buildbot tree in a broken state,
BTW -- if I don't remember to fix that, somebody poke me :-)
I should clarify that that's _my_ 2.4 buildbot tree, only on my
machine. I didn't break
Trent Mick wrote:
* [ 1462338 ] upgrade pyexpat to expat 2.0.0
http://python.org/sf/1462338
* [ 1295808 ] expat symbols should be namespaced in pyexpat
http://python.org/sf/1295808
These are in now. I don't see any failures yet, either on the buildbots
or on the Windows/Linux/Mac OS
Did we make a final decision about whether the canonical location for
ElementTree should be xml or xmlcore? Also, there's no ElementTree or
xmlcore that I can find at http://docs.python.org/dev/ under global
module index or library reference.
--
Aahz ([EMAIL PROTECTED]) *
Trent Mick wrote:
Trent Mick wrote:
* [ 1462338 ] upgrade pyexpat to expat 2.0.0
http://python.org/sf/1462338
* [ 1295808 ] expat symbols should be namespaced in pyexpat
http://python.org/sf/1295808
These are in now. I don't see any failures yet, either on the buildbots
or on the
On 6/19/06, Trent Mick [EMAIL PROTECTED] wrote:
Trent Mick wrote:
Trent Mick wrote:
* [ 1462338 ] upgrade pyexpat to expat 2.0.0
http://python.org/sf/1462338
* [ 1295808 ] expat symbols should be namespaced in pyexpat
http://python.org/sf/1295808
These are in now. I don't
Guido van Rossum [EMAIL PROTECTED] wrote:
Perhaps I misunderstood Josiah's comment; I thought he was implying
that a switch should be significantly *faster* than if/elif, and was
arguing against features that would jeopardize that speedup. I would
think that it would be fine if some switches
Aahz wrote:
Did we make a final decision about whether the canonical location for
ElementTree should be xml or xmlcore?
the original idea was to use xml to get the latest and greatest from
either the core or PyXML, xmlcore to use the bundled version. I see
no reason to change this just
68 matches
Mail list logo
