"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>>>configure thinks that using CXX for linking is necessary if compiling
>>>a program using CXX and linking it using CC fails.
>>
>>
>> That might be the right thing to do for some programs, but AFAICT
>> that's the wrong logi
Jeff Epler wrote:
> If we change the linker back to gcc, not g++, will it work if extension
> module 1 gets linked with libstdc++ A and ABI Q, and extension module 2
> gets linked with libstdc++ B and ABI Z?
The problem is that it won't link at all. Compiling Modules/ccpython.o
using g++ creates (
David Abrahams wrote:
>>configure thinks that using CXX for linking is necessary if compiling
>>a program using CXX and linking it using CC fails.
>
>
> That might be the right thing to do for some programs, but AFAICT
> that's the wrong logic to use for Python.
Why do you say that? Python compi
In order to lower the barrier for reporting bugs, writing patches, and
handling CVS commits, I am writing up checklists for each and I will
put them up on python.org.
The first checklist is for bug reports. All comments welcome. Keep
in mind the list is supposed to be short and straight-forward;
Jeff Epler <[EMAIL PROTECTED]> writes:
> If we change the linker back to gcc, not g++, will it work if extension
> module 1 gets linked with libstdc++ A and ABI Q, and extension module 2
> gets linked with libstdc++ B and ABI Z?
Yes, unless they are using sys.setdlopenflags to force symbols to be
If we change the linker back to gcc, not g++, will it work if extension
module 1 gets linked with libstdc++ A and ABI Q, and extension module 2
gets linked with libstdc++ B and ABI Z?
What if a built-in module is written in C++, as it might be for some
people embedding C++? (this will force use of
Guido van Rossum wrote:
> I even wonder if else-clauses on for/while were a good idea. (The one
> on try is definitely a good idea since the use case is quite frequent
> and only clumsily handled otherwise; the use cases for else on
> for/while are less convincing IMO.)
I'm +1 on removing the el
On 7/7/05, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote:
> > Simplifying the basic control flow mechanisms is always good.
> [...]
>
> Of course, it largely depends on what simplifying means to you.
If we lose the "else" in "for"s, we'd have to use a variable to mark
when we exit the normal way o
Jack Diederich <[EMAIL PROTECTED]> wrote:
> I can't say I use it for much else, if I really want a default I do
> found = None
> for (thing) in searchlist:
> if (matches(thing)):
> found = None
> break
>
> That could end with 'else: found = None' to assign a default but I
> like the def
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> Apparently Python on some linux distros is being linked by g++ rather
>> than gcc, resulting in the C++ runtime library being linked into
>> Python; this has bad consequences for compatibility between C++
>> extension modules
On Thu, 2005-07-07 at 16:30, Brett Cannon wrote:
> Floris is working on wrapping Hotshot to replace 'profile' and
> replacing pstats so that there will be no more need for 'profile' and
> thus take care of the licensing problem. He also hopes to make pstats
> faster to use. And if we are really l
On Thu, Jul 07, 2005 at 03:03:35PM -0400, Phillip J. Eby wrote:
> At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
> >[Guido, on {for,while}/else]
> >...
> > > The question remains whether Python would be easier to learn without
> > > them. And if so, the question would remain whether that's offset by
On 7/7/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 7/7/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Floris is working on wrapping Hotshot to replace 'profile' and
> > replacing pstats so that there will be no more need for 'profile' and
> > thus take care of the licensing problem. He also
Skip Montanaro <[EMAIL PROTECTED]> writes:
> >> I believe it's so that people can link in libraries written in C++
> >> and have them initialized properly.
>
> Dave> Can you give specifics? What do you mean by "link in?" Do you
> Dave> mean "statically link into the Python interp
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> I'm wondering if there has been a well-known recent change either in Python
>> or GCC that would account for these new reports. Any relevant
>> information would be appreciated.
>
> So what about the theory that it may be th
> > > How would a PEP to *remove* this feature fare today?
I hope not well, since I use them quite often.
> Barry also reiterated this idea and I support removing them in Python
> 3000. I do use them when I want to know when I break out of a loop
> prematurely, but I am definitely not a typical
David Abrahams wrote:
> Apparently Python on some linux distros is being linked by g++ rather
> than gcc, resulting in the C++ runtime library being linked into
> Python; this has bad consequences for compatibility between C++
> extension modules and Pythons that have been built with different
> ve
David Abrahams wrote:
> I'm wondering if there has been a well-known recent change either in Python
> or GCC that would account for these new reports. Any relevant
> information would be appreciated.
So what about the theory that it may be that different versions of
libstdc++ get linked? Python i
Am 07.07.2005 um 20:00 schrieb Guido van Rossum:
>>> +1 on @contextmanager
>
> +1.
>
> [__enter__, __exit__]
>
These names should be changed to __beginwith__ and __endwith__.
>
> -1. The PEP has had an extensive review period and several
> alternatives were discussed and rejected. Thes
At 01:30 PM 7/7/2005 -0700, Brett Cannon wrote:
>Floris is working on wrapping Hotshot to replace 'profile' and
>replacing pstats so that there will be no more need for 'profile' and
>thus take care of the licensing problem. He also hopes to make pstats
>faster to use. And if we are really lucky,
>> I believe it's so that people can link in libraries written in C++
>> and have them initialized properly.
Dave> Can you give specifics? What do you mean by "link in?" Do you
Dave> mean "statically link into the Python interpreter," or something
Dave> else?
Probably not.
On 7/7/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Floris is working on wrapping Hotshot to replace 'profile' and
> replacing pstats so that there will be no more need for 'profile' and
> thus take care of the licensing problem. He also hopes to make pstats
> faster to use. And if we are really
Floris is working on wrapping Hotshot to replace 'profile' and
replacing pstats so that there will be no more need for 'profile' and
thus take care of the licensing problem. He also hopes to make pstats
faster to use. And if we are really lucky, get threading working for
Hotshot.
It would be gre
On 7/7/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Guido]
> > OTOH I don't particularly like code that requires flag variables;
>
> Me neither; that's indeed why this one isn't a slam dunk.
>
> > they often make me squirm because the same condition (flag) is
> > tested multiple times where it co
[Jeremy Hylton]
> ...
> PS Every time I switch between Python and C, I get confused about
> "elif" and "else if".
Mostly goes to show that you don't use Perl much ;-) Of course, in C99,
#define elif else if
is part of . Or maybe it isn't, and it just should have
been? One of those -- or close
On 7/7/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The question remains whether Python would be easier to learn without
> them. And if so, the question would remain whether that's offset by
> their utility for experienced developers. All hard to assess
> impartially!
I think Python would cle
[Josiah Carlson]
> > > [Guido van Rossum]
> > > > I even wonder if else-clauses on for/while were a good idea.
> I had gotten along for 5 years without knowing/remembering there existed
> an else clause [...]
Just throwing a few more cents in. I have been programming (rather
successfully) for
On Thu, 2005-07-07 at 14:54, Guido van Rossum wrote:
> How would a PEP to *remove* this feature fare today?
Not well, I hope, although I suppose everything's up for debate in Py3K.
Yes, they're rarely used and there is an alternative, but I do find them
useful and succinct when they're needed.
[Guido]
> OTOH I don't particularly like code that requires flag variables;
Me neither; that's indeed why this one isn't a slam dunk.
> they often make me squirm because the same condition (flag) is
> tested multiple times where it could be tested just once if more
> sophisticated flow control (e
[Guido van Rossum]
> On 7/7/05, François Pinard <[EMAIL PROTECTED]> wrote:
> > [Guido van Rossum]
> > > I even wonder if else-clauses on for/while were a good idea.
> > I surely find them useful, and see them as a Python originality (a
> > welcome one).
> The question remains whether Python woul
On Thu, Jul 07, 2005, Guido van Rossum wrote:
>
> OTOH I don't particularly like code that requires flag variables; they
> often make me squirm because the same condition (flag) is tested
> multiple times where it could be tested just once if more
> sophisticated flow control (e.g. an else clause :
At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
>[Guido, on {for,while}/else]
>...
> > The question remains whether Python would be easier to learn without
> > them. And if so, the question would remain whether that's offset by
> > their utility for experienced developers. All hard to assess
> > impa
Skip Montanaro <[EMAIL PROTECTED]> writes:
> >> Configure with --without-cxx to not use g++. Since there is an
> >> option in configure, I assume it is intentional.
>
> Dave> O-kay... any idea what the rationale for this decision might be?
>
> I believe it's so that people can link in
Tim Peters <[EMAIL PROTECTED]> writes:
> I also suspect that if they weren't in the language already, a PEP to
> introduce them would fail, because
>
> still_looking = True
> some loop:
> if found it:
> still_looking = False
> break
> if still_looking:
>
> [Guido, on {for,while}/else]
> ...
> > The question remains whether Python would be easier to learn without
> > them. And if so, the question would remain whether that's offset by
> > their utility for experienced developers. All hard to assess
> > impartially!
[Tim saves the day]
> That's what
[Guido, on {for,while}/else]
...
> The question remains whether Python would be easier to learn without
> them. And if so, the question would remain whether that's offset by
> their utility for experienced developers. All hard to assess
> impartially!
That's what I'm here for. I like loop "else"
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 7/7/05, François Pinard <[EMAIL PROTECTED]> wrote:
> > [Guido van Rossum]
> >
> > > I even wonder if else-clauses on for/while were a good idea.
> >
> > I surely find them useful, and see them as a Python originality (a
> > welcome one).
>
> T
At 09:12 PM 7/6/2005 +1000, Nick Coghlan wrote:
>Another example is the use of contexts to handle insertion of the
>appropriate tags when generating HTML:
>
> with html:
>with body:
> with h1:
> print "Some heading"
> with p:
> print "This i
> > +1 on @contextmanager
+1.
[__enter__, __exit__]
> >> These names should be changed to __beginwith__ and __endwith__.
-1. The PEP has had an extensive review period and several
alternatives were discussed and rejected. These names are clear, they
*do* match, and as Fred says the __*__ namesp
On 7/7/05, François Pinard <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum]
>
> > I even wonder if else-clauses on for/while were a good idea.
>
> I surely find them useful, and see them as a Python originality (a
> welcome one).
They are indeed an original invention. (One day I looked at the
sim
[Guido van Rossum]
> I even wonder if else-clauses on for/while were a good idea.
I surely find them useful, and see them as a Python originality (a
welcome one).
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-
>> Configure with --without-cxx to not use g++. Since there is an
>> option in configure, I assume it is intentional.
Dave> O-kay... any idea what the rationale for this decision might be?
I believe it's so that people can link in libraries written in C++ and have
them initialized p
[Tim Peters]
>> Or my personal favorite,
>>
>>while mylist:
>>del mylist[::2]
>>
>> Then the original index positions with the most consecutive trailing 1
>> bits survive the longest, which is important to avoid ZODB cache bugs
>> .
[Christos Georgiou]
> This is a joke, hopefully, and
Sjoerd Mullender <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> Apparently Python on some linux distros is being linked by g++ rather
>> than gcc, resulting in the C++ runtime library being linked into
>> Python; this has bad consequences for compatibility between C++
>> extension modules
"Tim Peters" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Or my personal favorite,
>
>while mylist:
>del mylist[::2]
>
> Then the original index positions with the most consecutive trailing 1
> bits survive the longest, which is important to avoid ZODB cache bugs
> .
On 7/7/05, Thomas Lotze <[EMAIL PROTECTED]> wrote:
> Sure, that's true for the example given. Getting other stuff into a form
> which allows for looping may require additional code.
Well, hypothetical illustrations don't carry much value when arguing
for something as substantial as new syntax requ
David Abrahams wrote:
> Apparently Python on some linux distros is being linked by g++ rather
> than gcc, resulting in the C++ runtime library being linked into
> Python; this has bad consequences for compatibility between C++
> extension modules and Pythons that have been built with different
> ve
Apparently Python on some linux distros is being linked by g++ rather
than gcc, resulting in the C++ runtime library being linked into
Python; this has bad consequences for compatibility between C++
extension modules and Pythons that have been built with different
versions of GCC. Is this behavio
Florent Pillet <[EMAIL PROTECTED]> writes:
> I discovered an issue on Mac OS X that seems to relate to signal
> handling. I have a C binding in which I call the standard tmpfile()
> function. After calling it, I can't break Python anymore with CTRL-C.
> Investigating the Darwin source code for tm
Barry Warsaw <[EMAIL PROTECTED]> writes:
> +1 on @contextmanager
>
> On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote:
>
>> > __enter__(self):
>> > __exit__(self, exc_type, exc_value, exc_traceback):
>>
>> These names should be changed to __beginwith__ and __endwith__.
-1.
> -0.
I discovered an issue on Mac OS X that seems to relate to signal
handling. I have a C binding in which I call the standard tmpfile()
function. After calling it, I can't break Python anymore with CTRL-C.
Investigating the Darwin source code for tmpfile() (and FreeBSD, they
are the same) , I found t
Neil Hodgson <[EMAIL PROTECTED]> writes:
> Guido van Rossum:
>
>> Ah, sigh. I didn't know that os.listdir() behaves differently when the
>> argument is Unicode. Does os.listdir(".") really behave differently
>> than os.listdir(u".")?
>
>Yes:
os.listdir(".")
> ['abc', '']
I've put the draft documentation on the SF tracker, as Patch ID
#1234057 [1].
The version posted there has a few changes from the last draft I
mailed to the list, including:
- mention try/finally, then describe with statements as a way to
eliminate the associated boilerplate
- clean up some te
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I also notice that your only example is very repetitive, and would be
> better written as a loop, using Python's dynamic nature:
Sure, that's true for the example given. Getting other stuff into a form
which allows for looping may require additional c
54 matches
Mail list logo
