Re: [Python-Dev] PEP 3101 Update
Guido van Rossum wrote:
> On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
>
>> I've updated PEP 3101 based on the feedback collected so far.
>
> [http://www.python.org/dev/peps/pep-3101/]
>
> I think this is a step in the right direction.
Cool, and thanks for the very detailed feedback.
> I wonder if we shouldn't borrow more from .NET. I read this URL that
> you referenced:
>
> http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcompositeformatting.asp
>
>
>
> They have special syntax to support field width, e.g. {0,10} formats
> item 0 in a field of (at least) 10 positions wide, right-justified;
> {0,-10} does the same left-aligned. This is done independently from
We already have that now, don't we? If you look at the docs for "String
Formatting Operations" in the library reference, it shows that a
negative sign on a field width indicates left justification.
> the type-specific formatting. (I'm not proposing that we use .NET's
> format specifiers after the colon, but I'm also no big fan for keeping
> the C specific stuff we have now; we should put some work in designing
> something with the same power as the current %-based system for floats
> and ints, that would cover it.)
Agreed. As you say, the main work is in handling floats and ints, and
everything else can either be formatted as plain str(), or use a custom
format specifier syntax (as in my strftime example.)
> .NET's solution for quoting { and } as {{ and }} respectively also
> sidesteps the issue of how to quote \ itself -- since '\\{' is a
> 2-char string containing one \ and one {, you'd have to write either
> '{0}' or r'\\{0}' to produce a single literal \ followed by
> formatted item 0. Any time there's the need to quadruple a backslash I
> think we've lost the battle. (Or you might search the web for Tcl
> quoting hell. :-)
>
> I'm fine with not having a solution for doing variable substitution
> within the format parameters. That could be done instead by building
> up the format string with an extra formatting step: instead of
> "{x:{y}}".format(x=whatever, y=3) you could write
> "{{x,{y}}}".format(y=3).format(x=whatever). (Note that this is subtle:
> the final }}} are parsed as } followed by }}. Once the parser has seen
> a single {, the first } it sees is the matching closing } and adding
> another } after it won't affect it. The specifier cannot contain { or
> } at all.
There is another solution to this which is equally subtle, although
fairly straightforward to parse. It involves defining the rules for
escapes as follows:
'{{' is an escaped '{'
'}}' is an escaped '}', unless we are within a field.
So you can write things like {0:10,{1}}, and the final '}}' will be
parsed as two separate closing brackets, since we're within a field
definition.
From a parsing standpoint, this is unambiguous, however I've held off
on suggesting it because it might appear to be ambiguous to a casual reader.
> I like having a way to reuse the format parsing code while
> substituting something else for the formatting itself.
>
> The PEP appears silent on what happens if there are too few or too
> many positional arguments, or if there are missing or unused keywords.
> Missing ones should be errors; I'm not sure about redundant (unused)
> ones. On the one hand complaining about those gives us more certainty
> that the format string is correct. On the other hand there are some
> use cases for passing lots of keyword parameters (e.g. simple web
> templating could pass a fixed set of variables using **dict). Even in
> i18n (translation) apps I could see the usefulness of allowing unused
> parameters
I am undecided on this issue as well, which is the reason that it's not
mentioned in the PEP (yet).
> On the issue of {a.b.c}: like several correspondents, I don't like the
> ambiguity of attribute vs. key refs much, even though it appears
> useful enough in practice in web frameworks I've used. It seems to
> violate the Zen of Python: "In the face of ambiguity, refuse the
> temptation to guess."
>
> Unfortunately I'm pretty lukewarm about the proposal to support
> {a[b].c} since b is not a variable reference but a literal string 'b'.
> It is also relatively cumbersome to parse. I wish I could propose
> {a+b.c} for this case but that's so arbitrary...
Actually, it's not all that hard to parse, especially given that there
is no need to deal with the 'nested' case.
I will be supplying a Python implementation of the parser along with the
PEP. What I would prefer not to supply (although I certainly can if you
feel it's necessary) is an optimized C implementation of the same
parser, as well as the implementations of the various type-specific
formatters.
> Even more unfortunately, I expect that dict key access is a pretty
> important use case so we'll have to address it somehow. I *don't*
> think there's an important use case for the ambiguity -- in any
> particular situation I expect that the programmer will know whe
Re: [Python-Dev] [Python-checkins] r46043 - peps/trunk/pep-0356.txt
neal.norwitz wrote: Please note that the "Need for Speed" sprint runs May 21 - 27. Bringing the schedule forward on Alpha 3 makes it less possible to incorporate sprint changes into the 2.5 trunk. Will it be acceptable to add new (performance) changes between Alpha 3 and beta 1, or would developers prefer to put a fourth alpha in to the schedule? The intention is there should be no major functionality added by the sprint, simply that performance should be improved, so the schedule may work. It's just a call for the release manager really, I guess. regards Steve > Author: neal.norwitz > Date: Fri May 19 06:34:02 2006 > New Revision: 46043 > > Modified: >peps/trunk/pep-0356.txt > Log: > Speed up schedule a bit, rc corresponds to OSCON. > Gerhard checked in docs for sqlite. > > > > Modified: peps/trunk/pep-0356.txt > == > --- peps/trunk/pep-0356.txt (original) > +++ peps/trunk/pep-0356.txt Fri May 19 06:34:02 2006 > @@ -38,11 +38,11 @@ > > alpha 1: April 5, 2006 [completed] > alpha 2: April 27, 2006 [completed] > -alpha 3: May 27, 2006 [planned] > -beta 1: June 24, 2006 [planned] > -beta 2: July 15, 2006 [planned] > -rc 1:August 5, 2006 [planned] > -final: August 19, 2006 [planned] > +alpha 3: May 25, 2006 [planned] > +beta 1: June 14, 2006 [planned] > +beta 2: July 6, 2006 [planned] > +rc 1:July 27, 2006 [planned] > +final: August 3, 2006 [planned] > > > Completed features for 2.5 > @@ -155,7 +155,6 @@ > - Missing documentation >* ctypes (Thomas Heller) >* ElementTree/cElementTree (Fredrik Lundh) > - * pysqlite (Gerhard Haering) >* setuptools (written, needs conversion to proper format) > > - AST compiler problems > ___ > Python-checkins mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-checkins > > > -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Love me, love my blog http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101 Update
On 5/19/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > [http://www.python.org/dev/peps/pep-3101/]
> > http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcompositeformatting.asp
[on width spec a la .NET]
> We already have that now, don't we? If you look at the docs for "String
> Formatting Operations" in the library reference, it shows that a
> negative sign on a field width indicates left justification.
Yes, but I was proposing to adopt the .NET syntax for the feature.
Making it a responsibility of the generic formatting code rather than
of each individual type-specific formatter makes it more likely that
it will be implemented correctly everywhere.
[on escaping]
> There is another solution to this which is equally subtle, although
> fairly straightforward to parse. It involves defining the rules for
> escapes as follows:
>
> '{{' is an escaped '{'
> '}}' is an escaped '}', unless we are within a field.
>
> So you can write things like {0:10,{1}}, and the final '}}' will be
> parsed as two separate closing brackets, since we're within a field
> definition.
>
> From a parsing standpoint, this is unambiguous, however I've held off
> on suggesting it because it might appear to be ambiguous to a casual reader.
Sure. But I still think there isn't enough demand for variable
expansion *within* a field to bother. When's the lats time you used a
* in a % format string? And how essential was it?
[on error handling for unused variables]
> I am undecided on this issue as well, which is the reason that it's not
> mentioned in the PEP (yet).
There's another use case which suggests that perhaps all errors should
pass silent (or at least produce a string result instead of an
exception). It's a fairly common bug to have a broken format in an
except clause for a rare exception. This can cause major issues in
large programs because the one time you need the debug info badly you
don't get anything at all. (The logging module now has a special
work-around for this reason.) That's too bad, but it is a fact of
life.
If broken formats *never* caused exceptions (but instead some kind of
butchered conversion drawing attention to the problem) then at least
one source of frustration would be gone. If people like this I suggest
putting some kind of error message in the place of any format
conversion for which an error occurred. (If we left the {format}
itself in, then this would become a feature that people would rely on
in undesirable places.)
I wouldn't want to go so far as to catch exceptions from type-specific
formatters; but those formatters themselves should silently ignore bad
specifiers, or at least return an error string, rather than raise
exceptions.
Still, this may be more painful for beginners learning to write format strings?
Until we have decided, the PEP should list the two alternatives in a
fair amount of detail as "undecided".
> I will be supplying a Python implementation of the parser along with the
> PEP. What I would prefer not to supply (although I certainly can if you
> feel it's necessary) is an optimized C implementation of the same
> parser, as well as the implementations of the various type-specific
> formatters.
There's no need for any performance work at this point, and C code is
"right out" (as the Pythons say). The implementation should be usable
as a readable "spec" to resolve gray areas in the PEP.
> [] is the most intuitive syntax by far IMHO. Let's run it up the
> flagpole and see if anybody salutes :)
Fair enough.
> The way I have set up the API for writing custom formatters (not talking
> about the __format__ method here) allows the custom formatter object to
> examine the entire output string, not merely the part that it is
> responsible for; And moreover, the custom formatter is free to modify
> the entire string. So for example, a custom formatter could tabify or
> un-tabify all previous text within the string.
Ouch. I don't like that.
> The API could be made slightly simpler by eliminating this feature. The
> reason that I added it was specifically so that custom formatters could
> perform column-specific operations, like the old BASIC function that
> would print spaces up to a given column. Having generated my share of
> reports back in the old days (COBOL programming in the USAF), I thought
> it might be useful to have the ability to do operations based on the
> absolute column number.
Please drop it. Python has never had it and AFAICR it's never been requested.
> Currently the API specifies that a custom formatter is passed an array
> object, and the custom formatter should append its data to the end of
> the array, but it is also free to examine and modify the rest of the array.
>
> If I were to remove this feature, then instead of using an array, we'd
> simply have the custom formatter return a string like __format__ does.
Yes please.
> So the question is - is the use case useful enough to keep this feature?
> What do people think of
Re: [Python-Dev] 2.5 schedule
On Thu, May 18, 2006, Neal Norwitz wrote: > > I moved up the 2.5 release date by a bit. Ideally, I wanted to have > the final on July 27 which corresponds to OSCON. This seems too > aggressive since I haven't updated the schedule publicly. So the new > schedule has rc1 slated for July 27. > > http://www.python.org/dev/peps/pep-0356/ > > So far we've only had very few 2.5 bug reports for the first 2 alphas. > Hopefully people really are testing. :-) This isn't up on python.org, please post the current schedule here. Another point: with the Need For Speed sprint, should we perhaps allot some time for any new code to gel? Or is none of that code slated for 2.5? -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
Aahz wrote: >On Thu, May 18, 2006, Neal Norwitz wrote: > > >>I moved up the 2.5 release date by a bit. Ideally, I wanted to have >>the final on July 27 which corresponds to OSCON. This seems too >>aggressive since I haven't updated the schedule publicly. So the new >>schedule has rc1 slated for July 27. >> >>http://www.python.org/dev/peps/pep-0356/ >> >>So far we've only had very few 2.5 bug reports for the first 2 alphas. >> Hopefully people really are testing. :-) >> >> > >This isn't up on python.org, please post the current schedule here. > >Another point: with the Need For Speed sprint, should we perhaps allot >some time for any new code to gel? Or is none of that code slated for >2.5? > > Also, there is a sprint in Arlington VA. Both sprints will likely fix bugs, apply long standing patches, and improve performance for Py2.5. Also, we could use another bugday after the next alpha. Some "gelling" time would be helpful. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101 Update
Guido van Rossum wrote:
> [on escaping]
>
>> There is another solution to this which is equally subtle, although
>> fairly straightforward to parse. It involves defining the rules for
>> escapes as follows:
>>
>> '{{' is an escaped '{'
>> '}}' is an escaped '}', unless we are within a field.
>>
>> So you can write things like {0:10,{1}}, and the final '}}' will be
>> parsed as two separate closing brackets, since we're within a field
>> definition.
>>
>> From a parsing standpoint, this is unambiguous, however I've held off
>> on suggesting it because it might appear to be ambiguous to a casual
>> reader.
>
>
> Sure. But I still think there isn't enough demand for variable
> expansion *within* a field to bother. When's the lats time you used a
> * in a % format string? And how essential was it?
True. I'm mainly trying to avoid excess debate by not dropping existing
features unecessarily. (Otherwise, you spend way to much time arguing
with the handful of people out there that do rely on that use case.) But
if you want to use your special "BDFL superpower" to shortcut the
debate, I'm fine with that :)
> BTW I think we should move this back to the py3k list -- the PEP is
> 3101 after all. That should simplify the PEP a bit because it no
> longer has ti distinguish between str and unicode. If we later decide
> to backport it to 2.6 it should be easy enough to figure out what to
> do with str vs. unicode (probably the same as we do for %).
All right; Although my understanding is that the PEP should be escalated
to c.l.p at some point before acceptance, and I figured py-dev would be
a reasonable intermediate point before that. But it sounds like 3101 is
going to go back into the shop for the moment, so that's a non-issue.
Since you seem to be in a PEP-review mode, could you have a look at
3102? In particular, it seems that all of the controversies on that one
have quieted down; Virtually everyone seems in favor of the first part,
and you have already ruled in favor of the second part. So I am not sure
that there is anything more to discuss.
Perhaps I should go ahead and put 3102 on c.l.p at this point.
-- Talin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101 Update
On 5/19/06, Talin <[EMAIL PROTECTED]> wrote: > Since you seem to be in a PEP-review mode, could you have a look at > 3102? In particular, it seems that all of the controversies on that one > have quieted down; Virtually everyone seems in favor of the first part, > and you have already ruled in favor of the second part. So I am not sure > that there is anything more to discuss. > > Perhaps I should go ahead and put 3102 on c.l.p at this point. +1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] zlib module doesn't build - inflateCopy() not found
I'm having trouble getting the zlib module to build (SVN HEAD). The error is: building 'zlib' extension gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/guido/projects/python/trunk/./Include -I../Include -I. -I/usr/local/include -I/home/guido/projects/python/trunk/Include -I/home/guido/projects/python/trunk/linux -c /home/guido/projects/python/trunk/Modules/zlibmodule.c -o build/temp.linux-i686-2.5/zlibmodule.o /home/guido/projects/python/trunk/Modules/zlibmodule.c: In function `PyZlib_uncopy': /home/guido/projects/python/trunk/Modules/zlibmodule.c:723: warning: implicit declaration of function `inflateCopy' gcc -pthread -shared build/temp.linux-i686-2.5/zlibmodule.o -L/usr/local/lib -lz -o build/lib.linux-i686-2.5/zlib.so *** WARNING: renaming "zlib" since importing it failed: build/lib.linux-i686-2.5/zlib.so: undefined symbol: inflateCopy It seems I have libz 1.1.4. Is this no longer supported? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal and Exponentiation
[elventear]
> I am the in the need to do some numerical calculations that involve
> real numbers that are larger than what the native float can handle.
>
> I've tried to use Decimal, but I've found one main obstacle that I
> don't know how to sort. I need to do exponentiation with real
> exponents, but it seems that Decimal does not support non integer
> exponents.
>
> I would appreciate if anyone could recommend a solution for this
> problem.
Wait <0.3 wink>. Python's Decimal module intends to be a faithful
implementation of IBM's proposed standard for decimal arithmetic:
http://www2.hursley.ibm.com/decimal/
Last December, ln, log10, exp, and exponentiation to non-integral
powers were added to the proposed standard, but nobody yet has written
implementation code for Python's module. [Python-Dev: somebody
wants to volunteer for this :-)]
If you're not a numeric expert, I wouldn't recommend that you try this
yourself (in particular, trying to implement x**y as exp(ln(x)*y)
using the same precision is mathematically correct but is numerically
badly naive).
The GNU GMP library (for which Python bindings are available) also
supports "big floats", but their power operation is also restricted to
integer powers and/or exact roots. This can be painful even to try;
e.g.,
>>> from gmpy import mpf
>>> mpf("1e1") ** mpf("3.01")
consumed well over a minute of CPU time (on a 3.4 GHz box) before dying with
ValueError: mpq.pow fractional exponent, inexact-root
If you're working with floats outside the range of IEEE double, you
_probably_ want to be working with logarithms instead anyway; but that
depends on you app, and I don't want to know about it ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] zlib module doesn't build - inflateCopy() not found
[Guido] > I'm having trouble getting the zlib module to build (SVN HEAD). The error is: > > building 'zlib' extension > gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes -I. -I/home/guido/projects/python/trunk/./Include > -I../Include -I. -I/usr/local/include > -I/home/guido/projects/python/trunk/Include > -I/home/guido/projects/python/trunk/linux -c > /home/guido/projects/python/trunk/Modules/zlibmodule.c -o > build/temp.linux-i686-2.5/zlibmodule.o > /home/guido/projects/python/trunk/Modules/zlibmodule.c: In function > `PyZlib_uncopy': > /home/guido/projects/python/trunk/Modules/zlibmodule.c:723: warning: > implicit declaration of function `inflateCopy' > gcc -pthread -shared build/temp.linux-i686-2.5/zlibmodule.o > -L/usr/local/lib -lz -o build/lib.linux-i686-2.5/zlib.so > *** WARNING: renaming "zlib" since importing it failed: > build/lib.linux-i686-2.5/zlib.so: undefined symbol: inflateCopy > > It seems I have libz 1.1.4. Is this no longer supported? That's very peculiar. Python has its own copy of the zlib code now, under Modules/zlib/. That's version 1.2.3. http://mail.python.org/pipermail/python-dev/2005-December/058873.html inflateCopy() is exported by Modules/zlib/inflate.c. I wonder why the last gcc line above has "-lz" in it? Upgrade to Windows and everything will be fine :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
Neal Norwitz wrote: > I moved up the 2.5 release date by a bit. Ideally, I wanted to have > the final on July 27 which corresponds to OSCON. This seems too > aggressive since I haven't updated the schedule publicly. So the new > schedule has rc1 slated for July 27. > > http://www.python.org/dev/peps/pep-0356/ > > So far we've only had very few 2.5 bug reports for the first 2 alphas. > Hopefully people really are testing. :-) > > I'll continue to bug people that have action items. I'm sorry, but I find such advancing schedules with little warning quite objectionable. Particularly the cutoff for new functionality implicit in the last of the alphas. I have been working on patch 1454481 to try and make the original alpha 3 deadline in the context of my other commitments. I still hope to get it done early next week, but having that deadline advance without apparent warning just made things harder. Andrew. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 378 open ( +0) / 3238 closed (+22) / 3616 total (+22) Bugs: 907 open (+13) / 5831 closed (+20) / 6738 total (+33) RFE : 218 open ( +2) / 217 closed ( +2) / 435 total ( +4) New / Reopened Patches __ Patch fixing #1481770 (wrong shared lib ext on hpux ia64) (2006-05-07) CLOSED http://python.org/sf/1483325 opened by David Everly Add new top-level domains to cookielib (2006-05-07) CLOSED http://python.org/sf/1483395 reopened by jjlee Add new top-level domains to cookielib (2006-05-07) CLOSED http://python.org/sf/1483395 opened by John J Lee Wave.py support for ulaw and alaw audio (2006-05-07) http://python.org/sf/1483545 opened by Eric Woudenberg tarfile.py fix for #1471427 and updates (2006-05-09) CLOSED http://python.org/sf/1484695 opened by Lars Gustäbel cookielib: reduce (fatal) dependency on "beta" logging? (2006-05-09) CLOSED http://python.org/sf/1484758 opened by kxroberto urllib2: resolves extremly slow import (of "everything") (2006-05-09) CLOSED http://python.org/sf/1484793 opened by kxroberto HTMLParser : A auto-tolerant parsing mode (2006-05-11) http://python.org/sf/1486713 opened by kxroberto Patches and enhancements to turtle.py (2006-05-11) CLOSED http://python.org/sf/1486962 opened by Vern Ceder MacOSX: distutils support for -arch and -isysroot flags (2006-05-13) http://python.org/sf/1488098 opened by Ronald Oussoren Memory alignment fix on SPARC (2006-05-14) CLOSED http://python.org/sf/1488312 opened by Jan Palus tarfile.py: support for file-objects and bz2 (cp. #1488634) (2006-05-15) CLOSED http://python.org/sf/141 opened by Lars Gustäbel Updates to syntax rules in reference manual (2006-05-16) http://python.org/sf/1489771 opened by iga Seilnacht Patch for the urllib2 HOWTO (2006-05-16) CLOSED http://python.org/sf/1489784 opened by Mike Foord fix typo in os.utime() docstring (2006-05-17) CLOSED http://python.org/sf/1490189 opened by M. Levinson add os.chflags() and os.lchflags() where available (2006-05-17) http://python.org/sf/1490190 opened by M. Levinson time.altzone does not include DST offset on Cygwin (2006-05-17) CLOSED http://python.org/sf/1490224 opened by Christian Franke PC new-logo-based icon set (2006-05-17) http://python.org/sf/1490384 opened by Andrew Clover Describe Py_DEBUG and friends... (2006-05-18) http://python.org/sf/1490989 opened by Skip Montanaro IDLE L&F on MacOSX (2006-05-19) http://python.org/sf/1491759 opened by Ronald Oussoren Simple slice support for list.sort() and .reverse() (2006-05-19) http://python.org/sf/1491804 opened by Heiko Wundram Complex representation (2006-05-19) http://python.org/sf/1491866 opened by Heiko Wundram Fix for bug #1486663 mutable types check kwargs in tp_new (2006-05-20) http://python.org/sf/1491939 opened by iga Seilnacht Patches Closed __ applesingle endianness issue (2004-06-30) http://python.org/sf/982340 closed by gbrandl Patch fixing #1481770 (wrong shared lib ext on hpux ia64) (2006-05-07) http://python.org/sf/1483325 closed by loewis Add new top-level domains to cookielib (2006-05-07) http://python.org/sf/1483395 closed by gbrandl Add new top-level domains to cookielib (2006-05-07) http://python.org/sf/1483395 closed by gbrandl Heavy revisions to urllib2 howto (2006-05-01) http://python.org/sf/1479977 closed by akuchling Make urllib2 digest auth and basic auth play together (2006-04-30) http://python.org/sf/1479302 closed by gbrandl Take advantage of BaseException/Exception split in cookielib (2006-04-29) http://python.org/sf/1478993 closed by gbrandl tarfile.py fix for #1471427 and updates (2006-05-09) http://python.org/sf/1484695 closed by gbrandl cookielib: reduce (fatal) dependency on "beta" logging? (2006-05-09) http://python.org/sf/1484758 closed by gbrandl urllib2: resolves extremly slow import (of "everything") (2006-05-09) http://python.org/sf/1484793 closed by gbrandl Fix doctest nit. (2006-04-28) http://python.org/sf/1478292 closed by tim_one Remote debugging with pdb.py (2003-04-14) http://python.org/sf/721464 closed by gbrandl urllib2: better import ftplib and gopherlib etc late (2004-10-24) http://python.org/sf/1053150 closed by loewis detect %zd format for PY_FORMAT_SIZE_T (2006-04-22) http://python.org/sf/1474907 closed by bcannon Patches and enhancements to turtle.py (2006-05-11) http://python.org/sf/1486962 closed by gbrandl Improve docs for tp_clear and tp_traverse (2006-04-19) http://python.org/sf/1473132 closed by tim_one Memory alignment fix on SPARC (2006-05-14) http://python.org/sf/1488312 closed by nnorwitz tarfile.py: support for file-objects
Re: [Python-Dev] 2.5 schedule
Remember, the feature freeze isn't until beta1. New stuff can still go in after the next alpha, before beta1. And pure speedup related items aren't likely to cause feature changes (I hope) Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
On Saturday 20 May 2006 08:23, Andrew MacIntyre wrote: > I'm sorry, but I find such advancing schedules with little warning > quite objectionable. Particularly the cutoff for new functionality > implicit in the last of the alphas. Nonono. Feature freeze is beta1. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] zlib module doesn't build - inflateCopy() not found
Tim Peters wrote: > That's very peculiar. Python has its own copy of the zlib code now, > under Modules/zlib/. That's version 1.2.3. > > http://mail.python.org/pipermail/python-dev/2005-December/058873.html > > inflateCopy() is exported by Modules/zlib/inflate.c. I wonder why the > last gcc line above has "-lz" in it? By convention, the Unix build doesn't use the included zlib. Unix users typically insist on using the system libraries when they are available, so nobody has even contributed a build procedure to use the included zlib optionally. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] zlib module doesn't build - inflateCopy() not found
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 Mai 2006) | 3 lines Geänderte Pfade: M /python/trunk/Doc/lib/libzlib.tex M /python/trunk/Lib/test/test_zlib.py M /python/trunk/Misc/NEWS M /python/trunk/Modules/zlibmodule.c Patch #1435422: zlib's compress and decompress objects now have a copy() method. zlib itself contains inflateCopy since Changes in 1.2.0 (9 March 2003) - Added inflateCopy() function to record state for random access on externally generated deflate streams (e.g. in gzip files) The options for Python now are these: 1. require users to install zlib 1.2.x if they want the zlib module drawback: more work for the system administrator 2. conditionalize copy/uncopy on the system zlib being 1.2.x drawback: Python applications relying on these functions would break if the system zlib is too old 3. make setup.py fall back to the bundled zlib if the system zlib is too old drawback: you get all the problems of static linking, e.g. the size increase, and the problems with two zlib versions living in the same address space for some embedded Python applications I'm not volunteering to implement any of the options. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
