On Mon, 2004-12-06 at 16:28, Martin v. Löwis wrote:
Martin, +1 on everything you wrote, with one minor quibble.
Removal
===
If the module has been deprecated for atleast a year and atleast
a version, it can be removed. Removal should move it to old-libs
for pure Python modules; a
On Sun, 2004-12-12 at 12:32, Carlos Ribeiro wrote:
For those who believe that a non-profit project should not do any
marketing, a reminder. If the perception about Python is one of a slow
language, it's much more difficult to find places where you can use
Python. In the long run, many of us
On Mon, 2004-12-20 at 12:48, Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order.
+1
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[EMAIL PROTECTED]
On Mon, 2005-01-03 at 23:17, Tony Meyer wrote:
Perhaps interested parties should take up the discussion on
the compiler-sig.
This isn't listed in the 'currently active' SIGs list on
http://python.org/sigs/ - is it still active, or will it now be? If so,
perhaps it should be added to the
On Mon, 2005-01-10 at 09:40, Michael Chermside wrote:
Barry writes:
As an experiment, I just added a PEP topic to the python-checkins
mailing list. You could subscribe to this list and just select the PEP
topic (which matches the regex PEP in the Subject header or first few
lines of the
On Tue, 2005-01-11 at 12:58, Batista, Facundo wrote:
[Stephan Stapel]
#- There's a license issue here?
#-
#- I was given the advise to use this license. If this license
#- prohibts inclusion into Python, how should I re-license the code?
I just was asking. Who gave you the advise?
On Fri, 2005-01-14 at 06:40, Alex Martelli wrote:
+1 -- I never liked the idea that 'time tuples' lost fractions of a
second. On platforms where that's sensible and not too hard,
time.time() could also -- unobtrusively and backwards compatibly -- set
that same attribute. I wonder if,
On Mon, 2005-01-17 at 17:58, M.-A. Lemburg wrote:
If you want to make methods look more like functions,
the method object should become a subclass of the function
object (function + added im_* attributes).
I have no personal use cases, but it does make me vaguely uncomfortable
to lose
On Tue, 2005-02-08 at 10:35, Guido van Rossum wrote:
This would have been caught if there was a unit test validating what
the documentation says. Why aren't there unit tests for this code? I
think we need to raise the bar for wholistic improvements to a
module: first write a unit test if
On Sat, 2005-02-12 at 08:37, A.M. Kuchling wrote:
The md5 module has been a standard module for a long time; making it
optional in the next version of Python isn't possible. We'd have to
require OpenSSL to compile Python.
I totally agree.
-Barry
signature.asc
Description: This is a
On Tue, 2005-02-22 at 11:16, Guido van Rossum wrote:
Really? I do this kind of thing all the time:
import os
import errno
try:
os.makedirs(dn)
except OSError, e:
if e.errno errno.EEXIST:
raise
You have a lot more faith in the errno module than I do. Are you
On Sun, 2005-03-06 at 14:16, Martin v. Löwis wrote:
I don't know whether anybody has done this before,
but I just tried to run cvs2svn on the Python repository.
The conversion took 7 hours, and the result is now
available at
http://www.dcl.hpi.uni-potsdam.de/python/branches/
Because of
On Wed, 2005-03-09 at 07:17, Anthony Baxter wrote:
So it's only fair that I write down my rationale for why I'm being anal
about the no-new-features approach. Comments are more than welcome -
ideally, after discussion, I'll put some more words in the bugfix PEP.
I applaud your strictness
On Wed, 2005-03-09 at 19:39, Tommy Burnette wrote:
I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict
implementation for the last 5-6 years in which insertion order is the
only order respected. I use it all over the place (in a code base of
~60k lines of python code).
so
On Thu, 2005-03-10 at 23:46, Glyph Lefkowitz wrote:
That way instead of multi-line except NameError tests all over the
place you can simply have one-liner boilerplate for every module in your
project:
'from py24compat import *'
Easy to grep/sed for when you're ready to stop
On Fri, 2005-03-11 at 14:29, Jim Jewett wrote:
Is that so bad?
If you plan to use them often, then
from itertools import any, every
+1
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
On Fri, 2005-03-18 at 01:19, Andrew McNamara wrote:
No, exceptions are fast at the C level - all they do is set a flag. The
expense of exceptions is saving a restoring python frames, I think,
which doesn't happen in this case. So the current implementation is
ideal for C code - clear and
On Sun, 2005-03-27 at 20:55, Adam MacBeth wrote:
Has anyone ever considered using SCons to build Python? SCons is a
great build tool written in Python that provides some Autoconf-like
functionality (http://www.scons.org). It seems like this type of
self-hosting would be a great testament to
On Thu, 2005-04-07 at 10:58, Raymond Hettinger wrote:
Ben Gertzfield
Ben did a lot of work on the i18n parts of the email package. I haven't
heard from him in quite a while.
Ken Manheimer
Ken's still around. I'll send you his current email address in a
separate (pvt) message.
-Barry
I've noticed an apparent inconsistency in the exception thrown for
read-only properties for C extension types vs. Python new-style
classes. I'm wondering if this is intentional, a bug, a bug worth
fixing, or whether I'm just missing something.
class other(object):
def __init__(self, value):
On Thu, 2005-04-14 at 23:46, Barry Warsaw wrote:
I've noticed an apparent inconsistency in the exception thrown for
read-only properties for C extension types vs. Python new-style
classes.
I haven't seen any follow ups on this, so I've gone ahead and posted a
patch, assigning it to Raymond
On Sun, 2005-04-17 at 11:53, Jack Diederich wrote:
In 2.4 2.3 does it make sense to raise an exception that multiply inherits
from both TypeError and AttributeError? If anyone currently does catch the
error raising only AttributeError will break their code. 2.5 should just
raise an
On Sun, 2005-04-17 at 12:25, Aahz wrote:
Why is changing an exception more acceptable than creating a new one?
(I don't have a strong opinion either way, but I'd like some reasoning;
Jack's approach at least doesn't break code.) Especially if the new
exception isn't public (in the builtins
On Sun, 2005-04-17 at 14:36, Guido van Rossum wrote:
Personally, I think it would be fine to just change the TypeError to
AttributeError. I expect that very few people would be hurt by that
change (they'd be building *way* too much specific arcane knowledge
into their program if they had code
On Sun, 2005-04-17 at 15:44, Guido van Rossum wrote:
You meant 2.5 only of course. It's still a new feature and as such
can't be changed in 2.4.
Fair enough.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev
On Tue, 2005-04-19 at 15:24, Guido van Rossum wrote:
*If* we're going to create syntax for anonymous blocks, I think the
primary use case ought to be cleanup operations to replace try/finally
blocks for locking and similar things. I'd love to have syntactical
support so I can write
On Wed, 2005-05-04 at 13:09, 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.
+1!
-Barry
signature.asc
Description: This is a digitally signed message part
On Wed, 2005-05-04 at 14:41, Tim Peters wrote:
IIRC (and I may well not), half of people guessed wrong about whether
an exception raised in an except: suite would or would not skip
execution of the same-level finally: suite.
It would not, obviously wink.
try:
1/0
except
In setobject.c rev 1.26 + 1.27 Raymond removed gc support from built-in
set objects, claiming in the log message that sets cannot have
cycles. Yet the attached program creates a cycle that I don't believe
ever gets reclaimed.
Patch 1200018 restores GC support to set objects for Python 2.4.
On Mon, 2005-06-06 at 14:38, Skip Montanaro wrote:
import urllib
from www.urllib import urlopen
the module-level code should only be executed once, and
urlopen == urllib.urlopen
should evaluate to True.
Not to mention urlopen is urllib.urlopen
-Barry
signature.asc
On Fri, 2005-06-10 at 16:23, Guido van Rossum wrote:
While there's still some activity in the Wiki, nothing (to me) sounds
like signs of serious disagreement or truly better alternatives. So I
think I'd like to move forward towards acceptance soon (before
EuroPython).
Well, I finally read PEP
On Fri, 2005-06-17 at 00:43, Raymond Hettinger wrote:
Let me go on record as a strong -1 for continue EXPR. The for-loop is
our most basic construct and is easily understood in its present form.
The same can be said for continue and break which have the added
advantage of a near zero
On Fri, 2005-06-17 at 05:57, Raymond Hettinger wrote:
This PEP has been open for two and half years without generating
discussion or support.
Interesting. Just yesterday I wrote a simple stopwatch-like timer
script and I found that I needed three divmod calls to convert from
seconds into a
I've been looking at the API for sets.Set and built-in set objects in
Python 2.4.1 and I think I have found some minor inconsistencies.
Background: we have an object that is very similar to sets and we
originally modeled the API after sets.Set since we started with Python
2.3. Now I'm trying to
On Thu, 2005-06-30 at 13:37, Raymond Hettinger wrote:
If there are no objections, I propose to do the following (only in
Python 2.4 and 2.5):
* Add set.union_update() as an alias for set.update().
No. It was intentional to drop the duplicate method with the
hard-to-use name.
+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__.
-0. My fingers are too hardwired to writing endswith, as in the
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.
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
On Fri, 2005-07-08 at 16:24, Reinhold Birkenfeld wrote:
I compiled a list of some possible new context managers that could be
added to the stdlib.
I agree with Brett and Phillip that a few well-chosen context managers
would make sense in the stdlib both for convenience and for example
On Mon, 2005-07-11 at 01:08, Bob Ippolito wrote:
A better proposal would probably be another string prefix that means
dedent, but I'm still not sold. doc processing software is clearly
going to have to know how to dedent anyway in order to support
existing code.
OTOH, adding another
On Mon, 2005-07-25 at 16:37, Edward C. Jones wrote:
Is there a C API for the built-in type set? if not, why not?
Sadly, no. Because no one's written it yet...?
-Barry
signature.asc
Description: This is a digitally signed message part
___
On Thu, 2005-07-28 at 16:00, Martin v. Löwis wrote:
I'd like to see the Python source be stored in Subversion instead
of CVS
+1
, and on python.org instead of sf.net.
+0
I know that SF has promised svn access to projects for a long time now,
but I haven't heard anything from them in a long
On Thu, 2005-07-28 at 16:20, Guido van Rossum wrote:
I hope we're correctly estimating the effort required to manage the
server and the users.
Yah, me too! ;)
We are building some experience with this though, having moved many of
the system files, and all of the web pages, to svn. So far,
On Thu, 2005-07-28 at 17:58, James Y Knight wrote:
If you use the fsfs storage mechanism for subversion, it is somewhat
simpler to verify that the repository is not compromised. Each commit
is represented as a separate file, and thus old commits are never
modified. Only new files are
On Thu, 2005-07-28 at 20:15, Leif Hedstrom wrote:
I'm definitely positive to a migration to Subversion, but I'd be really
concerned about using plain text authentication mechanisms.
We won't use plain text, but we may (or, we currently do) use basic auth
over ssl. The security then is in
On Thu, 2005-07-28 at 22:14, Tim Peters wrote:
Ah, before I forget, single repository has worked very well for Zope
(which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
projects):
http://svn.zope.org/
Long URLs don't really get in the way in practice (rarely a need to
On Thu, 2005-07-28 at 22:59, Tim Peters wrote:
Yup, me too -- between the two of us, we don't have enough fingers to
count how many trunks, branches, and tags of ZODB and Zope I have to
fiddle with.
I have a small inkling of your pain.
They're all still copy, paste, tail-edit for me, and--
On Fri, 2005-07-29 at 01:00, Martin v. Löwis wrote:
Barry Warsaw wrote:
We won't use plain text, but we may (or, we currently do) use basic auth
over ssl. The security then is in the passwords, so we have to make
sure they're generated securely.
That (sort of) *is* plain text passwords
On Fri, 2005-07-29 at 00:44, Martin v. Löwis wrote:
- assignment of passwords. This I don't like about the current
pydotorg setup - there should be a way to chose your own password;
perhaps without involving an administrator.
I could imagine a web form for password change, and
On Fri, 2005-07-29 at 17:19, Martin v. Löwis wrote:
I believe this alone either won't work or won't be good enough (not
sure which one): If you have /bin/false as login shell, and still
manage to invoke /usr/bin/svnserve remotely, you can likely also
invoke /usr/bin/cat /etc/passwd remotely
On Fri, 2005-07-29 at 17:32, Martin v. Löwis wrote:
Was this with the file-system back end? What is your current system?
Yes, and it is a 3 GHz dual processor (although I don't think it uses
two processors) with 1GB RAM (I believe RAM size matters a lot for
this process; the older machine
On Fri, 2005-07-29 at 00:50, Christopher Petrilli wrote:
Another thing to look at would be Trac, which we are in the process of
moving to from the horrendous nightmare of Bugzilla. It's integration
with SVN as well as Wiki is quite amazing.
Now's the time I pipe in to remind everyone that
On Fri, 2005-07-29 at 17:21, Martin v. Löwis wrote:
Doesn't this give issues as *every* file the starts out renamed? e.g.
what if you want revision 100 of project/trunk/foo, but, at revision
100, it really was trunk/project/foo?
I think it only matters if you use urls. I working directories,
On Fri, 2005-07-29 at 18:12, Leif Hedstrom wrote:
Barry Warsaw wrote:
Public/private keys would be better, and if anybody knows how to set up
a Subversion server to use these without having to create accounts for
everyone, I think we (the pythong.org admins) would love your help.
I'll
On Sun, 2005-08-07 at 21:52, Nicholas Bastin wrote:
I've had enough corrupted subversion repositories that I'm
not crazy about the thought of using it in a production system. I
know I'm not the only person with this experience. Sure, you can keep
backups, and not really lose any work, but
On Mon, 2005-08-08 at 19:29, Tim Peters wrote:
Currently with svn you have to manually specify those 9 to be sure to not
include the remaining one. With p4 you just say to check-in the whole tree
and then remove that one from the list give you in your editor with entering
the check-in
On Thu, 2005-08-11 at 20:51, Anthony Baxter wrote:
So I'm currently planning for a 2.4.2 sometime around mid September. I figure
we cut a release candidate either on the 7th or 14th, and a final a week
later.
Cool. I'd like to commit the patches in this bug report:
On Tue, 2005-08-16 at 07:42, Michael Hudson wrote:
The third set of people who count are pydotorg admins. I'm not really
one of those either at the moment. While SF's CVS setup has it's
problems (occasional outages; it's only CVS) it's hard to beat what it
costs us in sysadmin time: zero.
On Tue, 2005-08-16 at 15:18, Neil Schemenauer wrote:
Another option would be to pay someone to maintain the SVN setup on
python.org. Unfortunately, I guess that would require someone else
to first create a detailed description of the maintenance work
required and to process bids.
Again,
On Wed, 2005-08-17 at 18:57, Calvin Austin wrote:
When was the last time someone thanked you for writing a test? I tried
to think of the last time it happened to me and I can't remember. Well
at Spikesource we want to thank you not just for helping the Python
community but for your testing
On Sun, 2005-08-21 at 09:12, Martin v. Löwis wrote:
It turns out that svn+ssh with a single account has limitations:
you can only set the tunnel user when you are using a restricted
key. In PEP 347, the plan is that the current SF project admins
get shell access to the pythondev account, which
On Mon, 2005-08-22 at 11:18, [EMAIL PROTECTED] wrote:
I'm completely confused about what, if anything, I need to send to you. I
can already access the python.org website repository via svn. Will I
automatically get access to the new Python source repository or do I need to
send you pub
On Mon, 2005-08-22 at 12:16, Martin v. Löwis wrote:
Barry Warsaw wrote:
I think technically, the answer to that is yes, you will automatically
get access to the source repo.
At the moment, the answer actually is no. For the projects repository,
there is no group write permission - you
On Tue, 2005-08-23 at 11:51, Fredrik Lundh wrote:
Gareth McCaughan wrote:
It's valid C99, meaning this is an unsigned long long.
since when does Python require C99 compilers?
Why, since Python 3.0 of course! wink
-Barry
signature.asc
Description: This is a digitally signed message
On Wed, 2005-08-24 at 12:38, Martin v. Löwis wrote:
I personally dislike recording the execution path in
local variables. This is like setting a flag in a loop
before the break, and testing the flag afterwards.
You can do this, but the else: clause of the loop is
just more readable.
Agreed!
On Wed, 2005-08-24 at 15:15, Raymond Hettinger wrote:
Hmm, that may not be a killer. I wonder if it is possible to treat
BaseException as a constant (like we do with None) and teach the
compiler to interpret it as catching anything that gets raised so that
except BaseException will work like
On Tue, 2005-08-30 at 11:27, Phillip J. Eby wrote:
So if partition() [or whatever it'll be called] could have an optional
second argument that defines the width of the 'cut' made, I would be
helped enormously. The default for this second argument would be
len(sep), to preserve the current
On Tue, 2005-08-30 at 14:53, Fredrik Lundh wrote:
Some kind of symmetry with get, probably. if
d.get(x)
returns None if x doesn't exist, it makes some kind of sense that
d.setdefault(x)
I think that's right, and IIRC the specific detail about the optional
second argument was
On Thu, 2005-09-01 at 05:54, Nick Coghlan wrote:
Oren Tirosh wrote:
* Replacing print with write/writeln
I still hope to see this change to make print a builtin instead of a
statement. I'd hate to lose the one-line hello world example due to cruft
like from sys import stdout.
I agree.
On Thu, 2005-09-01 at 10:58, Guido van Rossum wrote:
[Reinhold Birkenfeld]
You'd have to enclose print arguments in parentheses. Of course, the
trailing
comma form would be lost.
And good riddance! The print statement harks back to ABC and even
(unvisual) Basic. Out with it!
I have
On Thu, 2005-09-01 at 17:49, Bob Ippolito wrote:
That is absolutely true, print is becoming less and less useful in
the context of GUI or web applications.
I know we're dinosaurs, but some of us still write console apps in
Python!
Even in Just Debugging
scenarios, you're probably
On Thu, 2005-09-01 at 16:07, Guido van Rossum wrote:
Another real problem with print is that, while the automatic insertion
of spaces is nice for beginners, it often gets in the way,
OTOH, print's automatic space insertion is often the reason why I'll
reach for it instead of stream.write().
On Fri, 2005-09-02 at 00:40, Martin Blais wrote:
Talking about cleanliness, I'm not sure which is cleaner::
print sys.stderr, This is a long sentence that I \
had to cut in two.
print(This is a long sentence that I
had to cut in two., stream=sys.stderr)
On Fri, 2005-09-02 at 03:18, Paul F. Dubois wrote:
Remove the print statementI laughed until my sides hurt. Hello? Try
dating girls and talking to normal people, geek boys.
We scientists still use these for debugging. We never 'move on' very far
from the tutorial. The salient feature
On Fri, 2005-09-02 at 21:42, Guido van Rossum wrote:
With so many people expressing a gut response and not saying what in
the proposal they don't like, it's hard to even start a response. Is
it...
- Going from statement to function?
So I ignored my visceral reaction against the proposal and
On Sat, 2005-09-03 at 11:17, Guido van Rossum wrote:
I see two different ways to support the two most-called-for additional
requirements: (a) an option to avoid the trailing newline, (b) an
option to avoid the space between items.
See a (very quick and very dirty ;) strawman that I just
On Sat, 2005-09-03 at 12:51, James Y Knight wrote:
On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
So I think it's best to have two builtins:
print(*args, **kws)
printf(fmt, *args, **kws)
It seems pretty bogus to me to add a second builtin just to apply the
% operator for you
On Sat, 2005-09-03 at 14:42, Paul Moore wrote:
I have to agree. While I accept that Barry has genuine use cases for
the printf form, I don't quite see why %-formatting isn't enough. Is
the print-plus-% form so much less readable and/or maintainable?
IMO, yes. I can't tell you how many times
On Sat, 2005-09-03 at 13:12, Martin Blais wrote:
(defun python-abbrev-print ()
Help me change old habits.
(insert print()) (backward-char 1) t)
(put 'python-abbrev-print 'no-self-insert t)
(define-abbrev python-mode-abbrev-table print 'python-abbrev-print)
LOL! That's a great solution
On Sat, 2005-09-03 at 22:08, Nick Coghlan wrote:
See a (very quick and very dirty ;) strawman that I just posted to the
wiki. I think this has some interesting semantics, including the
ability to control the separator inline in a C++-like fashion. The
writef() version also accepts
On Sun, 2005-09-04 at 11:59, Guido van Rossum wrote:
I agree that those are strong arguments, so please hear me out.
Thanks Guido, I think your arguments are powerful too.
-Barry
signature.asc
Description: This is a digitally signed message part
On Sun, 2005-09-04 at 22:06, James Y Knight wrote:
No, we certainly don't /need/ printf(), as is well proven by its
current absence. Having the operation of printing and the operation
of string formatting be separated is good, because it means you can
easily do either one without the
On Sun, 2005-09-04 at 22:32, Guido van Rossum wrote:
Right. I just have one additional suggestion for the logging package
(not sure if it should apply to printf as well): if there's a problem
with the format operator, fall back to printing the format string
followed by the argument values (if
On Mon, 2005-09-05 at 12:07, Antoine Pitrou wrote:
Uh, what about internationalization (i18n) ?
In i18n you can't avoid the need for parameterized strings.
For example I want to write :
_(The file '%s' is read only) % filename
not :
_(The file) + ' + filename + ' + _(is read
On Mon, 2005-09-05 at 14:10, François Pinard wrote:
The file %(filename)s in directory %(dir)s is read only % vars()
is already usable. The need being already filled without Template
strings, it could hardly be presented as a motivation for them. :-)
Except that IME, %(var)s is an
On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote:
We could decide not to provide (b) directly, since it is easily
reduced to (c) using an appropriate format string (%s times the
number of arguments). But I expect that use case (b) is pretty
important, and not everyone likes having to use
On Tue, 2005-09-06 at 00:56, Guido van Rossum wrote:
On 9/5/05, Barry Warsaw [EMAIL PROTECTED] wrote:
Eliminating the newline argument from print() would reduce the number of
reserved keyword arguments in my strawman by half. Maybe we could even
rename 'to' to '__to__' (!) to eliminate
On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote:
But print-ng looks
like becoming the OOWTDI for a lot of applications. IMO it's just too
early to give up on print-ng becoming the one obvious way to do it for
a lot of i18n apps, too.
+1. I have a gut feeling that we can make it easy
On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
The leading 'p' (for 'positional') is necessary to get around the fact that
$1
is currently an illegal identifier in a Template
That should be fixable. Ideally, $1 is better than $p1.
-Barry
signature.asc
Description: This is a digitally
On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote:
I was also able to easily automate the process of extracting strings
to create that spreadsheet. I wrote a simple script that parsed the
Python modules and looked for function calls of _ whose only
argument was a constant string. Worked
On Thu, 2005-09-08 at 07:48, Antoine Pitrou wrote:
As I said Python needs an operator or function that does string
formatting using a simple template, *without* doing output at the same
time. The current syntax is the '%' operator, it could change, but it
shouldn't be removed in favor of an
Raymond requested, and Guido concurred, that the python-checkins mailing
list Reply-To header munging be turned off. I've now done this.
Previously, follow-ups to checkins would be addressed to python-dev.
Now, follow-ups will stay on the python-checkins list and will not
appear here, unless
On Mon, 2005-09-19 at 17:52, Scott David Daniels wrote:
Michael Hudson wrote:
How does a copying gc differ much from a non-copying non-refcounted gc
here?
One important issue for C coded modules is that addresses may change
when a GC is invoked, so no remembering addresses in your
On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote:
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
Please no! 'and' and 'or' is so readably beautiful.
Also, this proposal needs to be considered
On Tue, 2005-09-20 at 17:40, Guido van Rossum wrote:
Ouch. You're bringing up another valid issue: whether to support
elif. I think if we go with (if ... then ... else ...) or (if ...:
... else: ...) we'll have to support elif as well:
I'm not so sure. Once you start writing such a
On Tue, 2005-09-20 at 18:21, Thomas Lotze wrote:
Nothing prevents you from spreading the code over multiple lines, like so:
x = (if a then b
elif c then d
else e)
or even
x = (if a then
b
elif c then
d
else
e
)
especially as
On Wed, 2005-09-28 at 10:16, Jim Fulton wrote:
When we ask for the eggs attribute the first time, we call the
descriptor, which calls the eggs function. The function sets the eggs
attribute, overriding the descriptor. The next time the eggs attribute
is accessed, the saved value will be used
On Wed, 2005-09-28 at 19:14, Phillip J. Eby wrote:
Because it only works in classic classes due to a bug in descriptor handling:
Blah. ;)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
On Thu, 2005-09-29 at 21:21, Guido van Rossum wrote:
Flames, pleas to reconsider, etc., to /dev/null.
Congratulations gracefully accepted.
It's still my language! :-)
Congratulations! May this be as successful a syntax addition as
decorators and print (of which I'm a fan too! :).
-Barry
On Fri, 2005-10-07 at 14:42, Shane Hathaway wrote:
What's insanely difficult is really locking, and locking is driven by
concurrency in general, not just threads. It's hard to reason about
locks.
I think that's a very interesting observation! I have not built a
tremendous number of
1 - 100 of 2552 matches
Mail list logo
