I noticed that Makefile.pre.in uses the value from the environment variable
LDFLAGS but not CPPFLAGS. Any reason for this? ``./configure -h`` lists both
(and some other environment variables which are not really used either) so it
seems a little misleading to have those listed but to not
Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment
variable LDFLAGS but not CPPFLAGS. Any reason for this?
How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from
ZhangYue wrote:
Hi,
Here is a patch for httplib. I added a timeout value for
httplib.HTTPConnection, please check.
Thanks for the patch, but this is the wrong place for it. Please create a new
patch item on SourceForge at http://sourceforge.net/patch/?group_id=5470 .
-Brett
Terry Reedy wrote:
Randy Chung [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[SNIP]
I'm interested in using actual bugs in Python as exercises
Please consider including review of existing patches. Besides being
useful, it will also teach students how to submit good patches of
Martin v. Löwis wrote:
Jeremy Hylton wrote:
I got started on these this morning, will likely finish them tomorrow.
It would be perverse to apply your patch last, wouldn't it?
It turns out that Titus' patch might be more involved than he thought
it would be.
In any case, the review itself is a
Scott David Daniels wrote:
I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary
motivation is that Project Gutenberg seems to be starting to use BZIP2
compression for some of its zips. What other wish list things do
people around here have for zipfile? I thought I'd collect input
With school starting up again Monday and New Years being tomorrow I don't plan
to send this out until Tuesday.
Hope everyone has a good New Years.
-Brett
---
=
Summary Announcements
=
PyCon_ is coming up! Being held March
Guido van Rossum wrote:
The AST branch has been nearly complete for several Python versions
now. The last time a serious effort was made was in May I believe, but
it wasn't enough to merge the code back into 2.4, alas.
It would be a real shame if this code was abandoned.
[SNIP]
So, I'm pleading.
Nick Coghlan wrote:
Someone asked on python-list about getting notifications of changes to
PEP's.
As a low-effort solution, would it be possible to add a Sourceforge
mailing list hook just for checkins to the nondist/peps directory?
Call it python-pep-updates or some such beast. If I remember
Shane Holloway (IEEE) wrote:
For a little background, I'm working on making an edit and continue
support in python a little more robust. So, in replacing references to
unmodifiable types like tuples and bound-methods (instance or class), I
iterate over gc.get_referrers.
So, I'm working on
Skip Montanaro wrote:
A couple months ago I proposed (maybe in a SF bug report)
http://www.python.org/sf/1006786
that
time.strptime() grow some way to parse time strings containing fractional
seconds based on my experience with the logging module. I've hit that
stumbling block again, this time
Skip Montanaro wrote:
I realize the %4N notation is distasteful, but without it I think you
will have trouble parsing something like
13:02:00.704
What would be the format string? %H:%M:%S.%N would be incorrect.
Brett Why is that incorrect?
Because 704
Martin v. Löwis wrote:
I think Brett Cannon now also follows this rule; it
really falls short enough in practice because (almost)
nobody really wants to push his patch bad enough to
put some work into it to review other patches.
Yes, I am trying to support the rule, but my schedule is nutty right
Uh, life has been busy.
Will probably send this one out this weekend some time so please get
corrections in before then.
=
Summary Announcements
=
PyCon_ 2005 is well underway. The schedule is in the process of being
Nice and short summary this time. Plan to send this off Wednesday or Thursday
so get corrections in before then.
--
=
Summary Announcements
=
You can still `register http://www.python.org/pycon/2005/register.html`__ for
Paul Moore wrote:
On Mon, 31 Jan 2005 14:02:20 -0800, Brett C. [EMAIL PROTECTED] wrote:
2.5 was released just before the time this summary covers so most stuff was on
bug
fixes discovered after the release.
Give Guido the time machine keys back!
Fine, but I was going to go back in time, win
Everyone went silent on this topic. Does this mean people just stopped caring
(which I doubt since I know Skip wants this bad enough to bring it up every so
often)? Was it the issue of symmetry with strftime?
I am willing to add this (albeit the simple way I proposed in my last email on
this
BJörn Lindqvist wrote:
I'd like to help develop Python for fun and profit and I've heard that
posting patch reviews to python-dev is a good way to contribute. So
here goes:
Are we actually promoting this? I am fine with people doing this when they
have done five reviews and want their specific
Martin v. Löwis wrote:
Brett C. wrote:
But if people don't have that in mind, should we not be encouraging
this? I mean it seems to be defeating the purpose of SF and having
the various mailing lists that send out updates on SF posts.
[SNIP]
Björn did post his comment to SF, and a summary
[removed pydotorg from people receiving this email]
Aahz wrote:
On Thu, Feb 17, 2005, Skip Montanaro wrote:
I am frantically trying to get ready to be out of town for a
week of vacation. Someone sent me some patches for datetime
and asked me to look at them. I begged off but referred him to
Travis Oliphant wrote:
Hello again,
There is a great discussion going on the numpy list regarding a proposed
PEP for multidimensional arrays that is in the works.
During this discussion as resurfaced regarding slicing with objects that
are not IntegerType objects but that
have a
Michael Hudson wrote:
Phillip J. Eby [EMAIL PROTECTED] writes:
[SNIP]
And whatever happened to CALL_METHOD?
It didn't work as an optimization, as far as I remember. I think the
patch is on SF somewhere. Or is a branch in CVS? Oh, it's patch
#709744.
Do we need a tp_callmethod that takes an
Reinhold Birkenfeld wrote:
While rummaging in the old patches, I found this:
The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode
(LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation
and destruction for classic classes (but not newstyle classes, yet.)
The code
Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
__str__ and __unicode__ as well as the other hooks were
specifically added for the type constructors to use.
However, these were added at a time where sub-classing
of types was not possible, so it's time
Brett C. wrote:
Walter Dörwald wrote:
Brett C. wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
I don't have a clear picture of what the consensus currently
looks like :-)
If we're going for for a solution that implements the hook
awareness for all __typename__ hooks, I'd be +1
Steve Holden wrote:
Michele Simionato wrote [on c.l.py]:
Brett Cannon:
[... python-dev summary ... boilerplate change ...]
+1 for this idea. The summary looks much better now :)
Keep the good work going,
Sorry, but i have to disagree. I hope you won't take this reply
personally, Michele, since
Aahz wrote:
Both entries so far look very good. Perhaps writing python-dev summaries
could be a rotating position?
Good idea that several people have now suggested to me. I have emailed Tim,
Steve, and Tony to see what they think. It wouldn't surprise me if this
happens if for any other
Evan Jones wrote:
Sorry for taking so long to get back to this thread, it has been one of
those weeks for me.
On Feb 16, 2005, at 2:50, Martin v. Löwis wrote:
Evan then understood the feature, and made it possible.
This is very true: it was a very useful exercise.
I can personally accept
Guido van Rossum wrote:
This is something I've typed way too many times:
Py class C():
File stdin, line 1
class C():
^
SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a
function with no arguments still requires parentheses in the
Decided to just plow through the next Summary so that I was finally caught up.
I am not expecting the candidates for taking of the Summaries to write stuff
for this one (although I wouldn't mind it =). The idea of having them work
together to write the Summaries has been proposed, but this is
Greg Ward wrote:
[SNIP]
A-ha! I get it. There are two mistakes in test_descr.py:test_init():
lack of finally clause, and failure to make a copy of
warnings.filters. This patch fixes both:
--- Lib/test/test_descr.py 4 Mar 2005 04:47:04 - 1.202.2.2
+++ Lib/test/test_descr.py
Brett C. wrote:
Greg Ward wrote:
[SNIP]
A-ha! I get it. There are two mistakes in test_descr.py:test_init():
lack of finally clause, and failure to make a copy of
warnings.filters. This patch fixes both:
--- Lib/test/test_descr.py 4 Mar 2005 04:47:04 - 1.202.2.2
+++ Lib/test
Martin v. Löwis wrote:
Apparently, os.access was forgotten when the file system encoding
was introduced in Python 2.2, and then it was again forgotten in
PEP 277.
I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder
whether this is a backport candidate. People who try to invoke
Steven Bethard wrote:
Delaney, Timothy C (Timothy) [EMAIL PROTECTED] wrote:
The perennial how do I remove duplicates from a list topic came up on
c.l.py and in the discussion I mentioned the java 1.5 LinkedHashSet and
LinkedHashMap. I'd thought about proposing these before, but couldn't
think of
Jim Jewett wrote:
Guido van Rossum:
Whether to segregate these into a separate module: they are really a
very small amount of syntactic sugat, and I expect that in most cases,
instead of importing that module (which totally makes me lose my
context while editing) I would probably just write the
Phillip J. Eby wrote:
[SNIP]
One solution is to have a __signature__ attribute that's purely
documentary. That is, modifying it wouldn't change the function's
actual behavior, so it could be copied with update_meta() but then
modified by the decorator if need be. __signature__ would basically
Eric Nieuwland wrote:
Martin v. Löwis wrote:
That's not the full syntax. The full syntax is
[ test for exprlist in testlist list-iter-opt ]
where
test can be an arbitrary expression: and, or, lambda, +, -, ...
exprlist can be a list of expression, except for boolean and
relational expressions
Nick Coghlan wrote:
What's the current situation with providing fixes for AST branch problems?
Make sure AST is used in the subject line; e.g., [AST] at the beginning.
Unfortunately the AST group is only available for patches; not listed for bug
reports (don't know why; can this be fixed?).
Grant Olson wrote:
Make sure AST is used in the subject line; e.g., [AST] at
the beginning.
Unfortunately the AST group is only available for patches;
not listed for bug reports (don't know why; can this be fixed?).
Other than that, just assign it to me since I will most
likely be doing
Nicholas Jacobson wrote:
IIRC, Guido once mentioned that he regretted not
setting function docstrings to come before the
function declaration line, instead of after.
He did, but I don't know how strong that regret is.
i.e.
This describes class Bar.
class Bar:
...
Or with a decorator:
This
For those of you who don't know, I am sprinting on the AST branch here on
PyCon. Specifically, I am fleshing out Python/compile.txt so that it can act
as a good intro to new users and as a design doc.
But one of things I am not sure of is what the marshal_write_*() functions in
Grant Olson wrote:
Make sure AST is used in the subject line; e.g., [AST] at
the beginning.
Unfortunately the AST group is only available for patches;
not listed for bug reports (don't know why; can this be fixed?).
Other than that, just assign it to me since I will most
likely be doing
Nick Coghlan wrote:
Brett C. wrote:
OK, thanks to John Ehresman here at PyCon sprint I got logistix's
patch applied. Beyond a warning that a warning that decode_unicode()
is never called and the parser module failing to compile under Windows
everything should be fine for compiling the AST
OK, so here is my final Summary. Like to send it out some time this weekend so
please get corrections in ASAP.
=
Summary Announcements
=
---
My last summary
---
So, after nearly 2.5 years, this is
Terry Reedy wrote:
This led to a much more fleshed out design document
(found in Python/compile.txt in the AST branch),
The directory URL
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/?only_with_tag=ast-branch
or even the file URL
Alex A. Naanou wrote:
Hi!
here is a simple piece of code
pre
---cut---
class Dict(dict):
def __init__(self, dct={}):
self._dict = dct
def __getitem__(self, name):
return self._dct[name]
def __setitem__(self, name, value):
self._dct[name] = value
Irmen de Jong wrote:
Martin v. Löwis wrote:
Irmen de Jong wrote:
Please advise?
setup.py should refer to config_h_vars, which in turn should be set
earlier.
Regards,
Martin
Ah so the setup.py script is flawed.
However, the sysconfig object doesn't contain a config_h_vars...
So
Martin v. Lwis wrote:
Brett C. wrote:
I am currently adding some code for a Py_COMPILER_DEBUG build for use on the
AST branch. I thought that OPT was the proper variable to put stuff like this
into for building (``-DPy_COMPILER_DEBUG``), but that erases ``-g -Wall
-Wstrict-prototypes
Martin v. Lwis wrote:
Brett C. wrote:
The other option is to not make configure.in skip injecting arguments when a
pydebug build is done based on whether OPT is defined in the environment. So
configure.in:670 could change to ``OPT=$OPT -g -Wall -Wstrict-prototypes``.
That's a procedural
Matthew F. Barnes wrote:
Someone on python-help suggested that I forward this question to
python-dev.
I've been studying Python's core compiler and bytecode interpreter as a
model for my own interpreted language,
Might want to take a peek at the AST branch in CVS; that is what the compiler
Guido van Rossum wrote:
I've been thinking about this a lot, but haven't made much
progess. Here's a brain dump.
I've been thinking about integrating PEP 325 (Resource-Release Support
for Generators) into the for-loop code, so that you could replace
[SNIP - using 'for' syntax to delineate
Guido van Rossum wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put all of
this
effort into trying to come up with some way to handle cleanup in a generator.
I.e. PEP 325.
But (as I explained, and you agree) that still doesn't render PEP 310
Bob Ippolito wrote:
On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put
all of this
effort into trying to come up with some way to handle cleanup in a
generator.
Martin v. Lwis wrote:
Brett C. wrote:
Works for me. If no one objects I will check in the change for CFLAGS to make
it ``$(BASECFLAGS) $(OPT) $EXTRA_CFLAGS`` soon (is quoting it enough to make
sure that it isn't evaluated by configure but left as a string to be evaluated
by the shell when
Martin v. Lwis wrote:
Brett C. wrote:
Yep, you're right. I initially thought that the parentheses meant it was a
Makefile-only variable, but it actually goes to the environment for those
unknown values.
Before I check it in, though, should setup.py be tweaked to use it as well? I
say yes
OK, EXTRA_CFLAGS support has been checked into Makefile.pre.in and
distutils.sysconfig . Martin, please double-check I tweaked sysconfig the way
you wanted. I also wasn't sure of compatibility for Distutils (first time
touching it); checked PEP 291 but Distutils wasn't listed. I went ahead and
Guido van Rossum wrote:
[SNIP]
Now let me propose a strawman for the translation of the latter into
existing semantics. Let's take the generic case:
with VAR = EXPR:
BODY
This would translate to the following code:
[SNIP]
it = EXPR
err = None
while True:
Greg Ewing wrote:
Brett C. wrote:
And before anyone decries the fact that this might confuse a newbie
(which
seems to happen with every advanced feature ever dreamed up), remember
this
will not be meant for a newbie but for someone who has experience in
Python and
iterators
Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified to StopIteration or
Guido van Rossum wrote:
[Guido]
An alternative that solves this would be to give __next__() a second
argument, which is a bool that should be true when the first argument
is an exception that should be raised. What do people think?
I'll add this to the PEP as an alternative for now.
Guido van Rossum wrote:
Nice one. Should be a piece of cake to implement. Please talk to
[EMAIL PROTECTED] about getting it checked into the PEP database.
I'm +1 on accepting this now -- anybody against?
I'm +1. A couple of us discussed this at PyCon during the last day of the
sprints and
Guido van Rossum wrote:
[SNIP]
There's one alternative possible (still orthogonal to PEP 340):
instead of __next__(), we could add an optional argument to the next()
method, and forget about the next() built-in. This is more compatible
(if less future-proof). Old iterators would raise an
Guido van Rossum wrote:
[Ka-Ping Yee]
It occurred to me as i was messing around with handling and re-raising
exceptions that tossing around these (type, value, traceback) triples
is irritating and error-prone.
How about just passing around a single value? All we'd have to do is
put the
Guido van Rossum wrote:
[Ka-Ping Yee]
Suppose exceptions have an optional context attribute, which is
set when the exception is raised in the context of handling another
exception. Thus:
def a():
try:
raise AError
except:
raise BError
yields an
Guido van Rossum wrote:
[Brett C.]
Seems like, especially if we require inheritance from a base exception class
in
Python 3000, exceptions should have standard 'arg' and 'traceback' attributes
with a possible 'context' attribute (or always a 'context' attribute set to
None if not a chained
Guido van Rossum wrote:
[Guido]
What if that method catches that exception?
[Ka-Ping Yee]
Did you mean something like this?
def handle():
try:
open('spamspamspam')
except:
catchit()
# point A
...
def catchit():
Guido van Rossum wrote:
[Fredrik Lundh]
intuitively, I'm -1 on this proposal.
Just to toss in my opinion, I prefer PEP 340 over 343 as well, but not so much
to give 343 a -1 from me.
[SNIP - question of how to handle argument against 340 being a loop which I
never totally got since you know
Paul Moore wrote:
On 5/14/05, Brett C. [EMAIL PROTECTED] wrote:
Nick's was obviously directly against looping, but, with no offense to Nick,
how many other people were against it looping? It never felt like it was a
screaming mass with pitchforks but more of a I don't love it, but I can deal
Guido van Rossum wrote:
[SNIP - bunch of points from Guido]
Do we really need both __context__ and __cause__? Methinks that you
only ever need one: either you explicitly chain a new exception to a
cause, and then the context is probably the same or irrelevant, or you
don't explicitly chain,
happening is people finding mistakes in the code. =) But if
enough people request the source I will take the time to generate a tar.bz2
file of patches against the 2.3.4 source release and put them up somewhere.
Below is the abstract culled directly from the thesis itself.
-Brett C
Armin Rigo wrote:
Hi Brett,
On Tue, May 24, 2005 at 04:11:34PM -0700, Brett C. wrote:
My thesis, Localized Type Inference of Atomic Types in Python, was
successfully defended today for my MS in Computer Science at the California
Polytechnic State University, San Luis Obispo
Reinhold Birkenfeld wrote:
Hello,
would anybody mind if I was given permissions on the tracker and CVS, for
fixing small
things like bug #1202475. I feel that I can help you others out a bit with
this and
I promise I won't change the interpreter to accept braces...
Since no direct
Been rather quite around here lately so I just wanted to do a quick check to
see what the status is on PEPs 342 and 343. I noticed Nick's PEP is still not
up. Probably too busy with that fix for genexps in the AST branch, huh, Nick?
=)
Guido, you need something hashed out from us at this
Nick Coghlan wrote:
Nick Coghlan wrote:
Brett C. wrote:
I noticed Nick's PEP is still not
up. Probably too busy with that fix for genexps in the AST branch, huh,
Nick? =)
Something like that. . . still, I finally got around to fixing the formatting
in
the text file and sending it back
Facundo Batista wrote:
Going on with the old bugs checking, here are the results for 2.2.2 (and
one from 2.2.1). When I'll finish this will be put in an informational PEP.
Great work, Facundo! Now I feel lazy. =)
-Brett
___
Python-Dev mailing
Facundo Batista wrote:
On 5/30/05, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
While we can't (and shouldn't) delete categories, we can change the text used
to describe them. So Python 2.2.2 can become Python 2.2.2
(unmaintained). Whether this is desirable or not, I'm not sure.
+1 for
Gregory P. Smith wrote:
[SNIP]
major gripe to -dev: a 'make install' of the full cvs tree should not
be required to test that some changes to existing .py files that pass
their tests (in this case they -are- the tests) are ok to check in.
You actually don't have to. If you execute the
Guido van Rossum wrote:
[SNIP - Guido already said throw() is the name to be used]
- Whether and how to keep a door open for a future extension to the
syntax that allows multiple resources to be acquired in a single
with-statement. Possible syntax could be
(a)with EXPR1 [as VAR1], EXPR2
On 10-May-08, at 20:43, [EMAIL PROTECTED] wrote:
Brett There is going to be an issue with the current proposal for
Brett keeping around urllib. Since the package is to be named
the same
Brett thing as the module
Is this the only module morphing into a package of the same
-Brett [from his iPod touch]
On 10-May-08, at 23:46, Alexandre Vassalotti [EMAIL PROTECTED]
wrote:
On Sat, May 10, 2008 at 11:43 PM, [EMAIL PROTECTED] wrote:
Brett There is going to be an issue with the current proposal for
Brett keeping around urllib. Since the package is to be
-Brett [from his iPod touch]
On 10-May-08, at 23:58, Alexandre Vassalotti [EMAIL PROTECTED]
wrote:
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon [EMAIL PROTECTED]
wrote:
I see three solutions for dealing with this.
1. Have stubs for the entire urllib API in urllib.__init__ that raise
-Brett [from his iPod touch]
On 11-May-08, at 0:04, Fred Drake [EMAIL PROTECTED] wrote:
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon [EMAIL PROTECTED]
wrote:
I see three solutions for dealing with this.
1. Have stubs for the entire urllib API in urllib.__init__ that raise
a
82 matches
Mail list logo
