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
"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 sw
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
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
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]) <*> http
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
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
[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
>
> http://svn.python.org/projects/external/tcl8.4.12/ge
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 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?
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.
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 uninte
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
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 Win
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
__
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:
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:
>
-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 enthusiast
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
[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 Ant
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 returning
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:
http://mail.python.o
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,
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
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
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 tes
>> 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 ap
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
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 w
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
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/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
>> > 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 th
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
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*
> >
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 inter
>> 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
> ot
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 platf
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 sta
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 id
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), [...]
Um, is this dogma? Wouldn't a
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
>>
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"?
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 combinatio
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 showe
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
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 m
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 chi
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 with
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
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
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
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
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
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 replace
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 n
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
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 bra
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, b
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,
Kr
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
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 the
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.
K
Okay, for specifics which demonstrate the problem.
I have a directory, C:\tmp\腌
In it, there is a file, doo.py
>d = os.listdir(u"c:/tmp")[-1]
>d
u'\u814c'
>>> d2 = os.listdir(u"c:/tmp/"+d)
>>> d2
[u'doo.py']
>>> p = u"c:/tmp/"+d
>>> p
u'c:/tmp/\u814c'
>>> sys.path.append(p)
>>> import doo
Traceback
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
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
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 e
The trunk will be FROZEN for 2.5b1 from 00:00UTC on Tuesday, 20th of
June. That's about 16 hours from now. Please don't checkin while the
trunk is frozen, unless you're one of the release team (me, Martin,
Fred, Ronald).
I'll send another note once we're done with the release. Please note
tha
"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" expression
69 matches
Mail list logo
