this
an issue with python 2.4?
I'm also surprised that the python 2.4 source kit only mentions MSVC
6.0 and not the
compiler that you actually built python 2.4 with.
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On Dec 23, 2004, at 23:12, Martin v. Löwis wrote:
Barry Scott wrote:
It seems that I can build extensions with msvc 6.0 that work with the
python 2.4 windows
binary kit.
Is this safe?
No, it isn't. This emerges as a Python 2.4 FAQ.
I recall warning a while ago about mixing msvc 6.0 and msv
it now be? If so,
> perhaps it should be added to the list?
>
> By 'discussion on', do you mean via the wiki at
> <http://www.zope.org/Members/jeremy/CurrentAndFutureProjects/PythonAST>?
If compiler-sig is where ASTers want to hang out, I'd be happy to
resurrect i
On Tue, 2005-01-04 at 11:17, Jeremy Hylton wrote:
> That's fine with me. We had taken it to the compiler-sig when it
> wasn't clear there was interest in the ast branch :-).
Ok, then I'll leave compiler-sig where it is.
-Barry
signature.asc
Description: This is a digitall
too. OTOH, we have function attributes now, so
why couldn't we just stuff the class on the function's im_class
attribute? Who'd be the wiser? (Could the same be done for im_self and
im_func for backwards compatibility?)
quack-quack-ly y'rs,
-Barry
signature.asc
Descr
> inheritance hierarchies. Perhaps this should be a suggested "best
> practice" when using super() as well?
Yep, I've done the same thing. It's definitely a good practice.
-Barry
signature.asc
Description: This is a digitally signed message part
__
something funkier, then you can set that attribute
yourself.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
P" in the Subject header or first few
lines of the body).
Give it a shot and let's see if that does the trick.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Fri, 2005-01-07 at 10:05, Nick Coghlan wrote:
> Barry Warsaw wrote:
> > 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
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
ust was asking. Who gave you the advise?
Here's a link to the PSF contribution form:
http://www.python.org/psf/contrib.html
This contains links to the recommended licenses for software that might
be included in Python.
-Barry
signature.asc
Description: Th
to use microseconds=0 to decide whether to print the
fractional second part or not for isoformat(), e.g.:
>>> import datetime
>>> now = datetime.datetime.now()
>>> now.isoformat()
'2005-01-14T06:44:18.013832'
>>> now.replace(microsecond=0).isoformat()
e
to lose im_class. Isn't it possible to preserve this attribute?
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
On Mon, 2005-01-31 at 00:17, Guido van Rossum wrote:
> > I had hoped for the core of p3k to be built for scratch [...]
>
> Stop right there.
Phew!
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev
r).
I've heard rumors that SF was going to be making svn available. Anybody
know more about that? I'd be +1 on moving from cvs to svn.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
P
many place, you really have to take the
documented interface seriously (not that you shouldn't otherwise, of
course). I suspect even the undocumented current semantics are relied
on in many place.
-Barry
signature.asc
Description: This is a digitally signed message part
___
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
Des
of the os.error structure.
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
-Barry
signature.asc
Description: This is a digitally signed message part
__
; It's
> also not exactly readable (except for old Unix hacks).
Guilty as charged. ;)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
impler operations
> that result in an atomic system call, this is important.
Agreed.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
t curious - why did you choose fsfs instead of the BerkeleyDB
backend?
Thanks for doing this Martin. I've heard that SF may be offering svn as
early as May or June and I would love to see us convert when that's
available.
-Barry
signature.asc
Description: This is a digitally signed mes
ckage maintainer will just have to make
independent releases, sync'ing up with Python development in the
latter's trunk. I've had to do this occasionally with the email
package, for example.
-Barry
signature.asc
Description: This is a digitally signed message part
_
sidered at the time that the number of headers in an email message
wouldn't be so large that anything else would be worth the complexity.
I think that still holds, for the original uses cases at least.
-Barry
signature.asc
Description: This is a digitally signed message part
___
h, in practice I
suspect that exact semantics and other design factors will either tend
to push the stdlib implementation into ever more complexity, or won't
prevent people from continuing to roll their own because the stdlib
version "isn't quite right".
-Barry
signature.
ed to 2.4 internally and it went
embarrassingly smoothly. Had to find something else to do with the four
days (cough - warsaw's first law - cough) we'd scheduled for that.
-Barry
signature.asc
Description: This is a digitally signed message part
__
;t know if
> it's referring to the builtin or a variable.
> Personally, I think Python has too many builtins already.
I agree. Personally, I'd rather see 'all' called 'every' (I'm less sure
about 'any' being called 'some'), and I'
erred argument evaluation (a la PEP
> 312), the def syntax is a crummy substitute.
Yeah, I'm with you here. As warty as lambda is, it just is so damn
convenient some times. I've recently been using it as a companion to
property(), providing concise definitions of read-only attributes.
kage in moving from Python 2 to Python 3. So while I would
lament the loss of lambda too, I think its impact on my code will be in
the noise compared to dealing with "optional" static typing and the
truly saddening loss of <>.
there's-a-wink-in-there-somewhere-ly y'rs,
-
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
___
Pyt
code - clear and fast.
The other advantage for raising and catching exceptions entirely in C is
that the (class) exceptions are never instantiated. Once you cross the
C-Python barrier you have to pay for that instantiation.
-Barry
signature.asc
Description: This is a digitally si
d that we have now works well enough (for
*nix) so IMO, switching to SCons is effort that would be better spent
elsewhere. I don't see lots of upside to switching.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-
On Tue, 2005-04-05 at 19:06, Fred Drake wrote:
> Would anyone here object to renaming the file to developers.txt, though?
+1, please!
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-
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 (
t IIRC, a few years
ago the issue came up again; Guido had changed his mind so we changed
syncmail to produce unified diffs.
IMO unifieds are preferred when the diffs are for human consumption, but
when they're only for machine consumption, anything that the patch
program accepts is
as the thing to raise when trying
to set read-only properties.
Thoughts? Should this be fixed (in 2.4?).
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
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,
st
> raise an AttributeError, of course.
Without introducing a new exception class (which I think is out of the
question for anything but 2.5), the only common base is StandardError,
which seems too general for this exception.
-Barry
signature.asc
Description: This is a digitally sig
exception isn't "public" (in the builtins with other exceptions).
Adding an exception that we have to live with forever (even if it's
localized to this one module) seems like it would fall under the new
feature rubric, whereas I think the choice of exception was just a bug.
-Bar
ogram if they had code for which it mattered).
Unless there are any objections in the next few days, I will take this
as a pronouncement and make the change at least in 2.5 and 2.4.
-Barry
signature.asc
Description: This is a digitally signed message part
_
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
__
: so I wonder if the decorator
syntax couldn't be extended for this kind of thing.
@acquire(myLock):
code
code
code
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@pyt
20, in failUnlessRaises
> >callableObj(*args, **kwargs)
> > AttributeError: attribute 'quoting' of '_csv.Dialect' objects is not
> > writable
>
> looks like someone didn't run the test suite...
My bad, I didn't check everything in. Wi
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 messag
.
> There are obvious answers to both, of course. The question is whether
> they're the _same_ obvious answers across responders <0.7 wink>.
It only matters that it's the same obvious answers across all responders
who are right. :)
-Barry
signature.asc
Description: Thi
for Python 2.4. Thanks
to my colleague Matt Messier for finding this.
kick-me-if-i'm-smoking-something-ly y'rs,
-Barry
http://sourceforge.net/tracker/index.php?func=detail&aid=1200018&group_id=5470&atid=305470
cycle.py
Description: application/python
signature.asc
De
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 "urlop
tement. Possible syntax could be
>
> (a)with EXPR1 [as VAR1], EXPR2 [as VAR2], EXPR3 [as VAR3], ...:
>
> or
>
> (b)with EXPR1, EXPR2, EXPR3, ... as VAR1, VAR2, VAR3, ...:
I agree that (a) is better and feel +1 on keeping the door open to it.
-Barry
signature.as
sed the 'do' keyword - I find that past tense
> or noun forms tend to read better than present tense for custom built
> with templates named after the action that occurs on entry:
>
># Past tense
>with locked(my_lock):
>with opened(my_file, mode):
>with
I
don't buy the compatibility argument. I'm as anal as anyone about PEP 8
style, but that's still no reason to break code like
>>> MIX = True
I wouldn't be opposed to a library that provided a function to convert
to and from Romans but I don't think Python needs Roman n
. IMO, it fails most of those
> tests.
>
> I would not look forward to explaining "continue EXPR" in the tutorial
> and think it would stand out as an anti-feature.
I'm sympathetic to this argument. I also find yield expressions
jarring. I don't have any be
P fails the tests of obviousness and necessity.
I agree. The fact that None is not callable is a /feature/ IMO. +1 for
rejecting this PEP.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python
feet, inches = divmod(dist, 3, 12)
>
> The latter form makes it difficult to visually confirm the correct
> number of target variables. Likewise, it is not at all obvious that the
> order of the 3 and 12 are correct.
I agree. My three divmod solution is perfectly readable and simple to
wr
On Mon, 2006-02-13 at 15:44 -0800, Guido van Rossum wrote:
> The right way to look at this is, as Phillip says, to consider
> conversion between str and bytes as not an encoding but a data type
> change *only*.
That sounds right to me too.
-Barry
signature.asc
Description: This is a
to act like a sequence and
sometimes you want it to act like a scalar. I suspect bytes objects
will be the same way.
-Barry
___
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
On Feb 14, 2006, at 6:35 AM, Greg Ewing wrote:
> Barry Warsaw wrote:
>
>> This makes me think I want an unsigned byte type, which b[0] would
>> return.
>
> Come to think of it, this is something I don't
> remember seeing discussed. I've been thinking
> th
te off it. Maybe text and data
> could be two subclasses of file, with file remaining initially as it
> is (and perhaps becoming an abstract-only baseclass at the time 'open'
> is deprecated).
I was actually thinking about static methods file.text() and file.data()
which seem nicely
avior". I don't know what
that class would be called, but you'd then have a hierarchy like this:
photonic
basestring
str
unicode
bytes
OTOH, it seems like a lot to add for a specialized (and some would say
dubious) use case.
-Barry
signature.asc
Descriptio
. I'm tempting to hold out for open() since it's most
> compatible.
If we go with two functions, I'd much rather hang them off of the file
type object then add two new builtins. I really do think file.bytes()
and file.text() (a.k.a. open.bytes() and open.text()) is better
a, but I'd leave off one or the other of the
redudant "open" and "file" parts. E.g. bytes.open() and unicode.open()
seem fine to me (we all know what 'open' means, right? :).
-Barry
signature.asc
Description: This is a digitally signed message part
___
e is allowed something like PyChecker can get the access it
> needs.
I haven't been following the AST stuff closely enough, but I'm not crazy
about putting access to this in the sys module. It seems like it
clutters that up with a name that will be rarely used by the average
P
inch I'd be
happy to dust off my RM hat and help out too.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Wed, 2006-02-15 at 19:02 +0100, M.-A. Lemburg wrote:
> Anyway, as long as we don't start adding openthis() and openthat()
> I guess I'm happy ;-)
Me too! :)
-Barry
signature.asc
Description: This is a digitally signed message part
__
pected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83,
> 227, 131, 79, 229, 201, 46, 106])
Kind of like binascii.unhexlify() but returning a bytes object.
-Barry
signature.asc
Description: This is a digitally signed message part
___
gt; ''.encode('smtplib')
Traceback (most recent call last):
File "", line 1, in ?
LookupError: unknown encoding: smtplib
>>> sys.modules['smtplib']
I can't see any reason for allowing any randomly importable module to
act like an encoding.
-
On Thu, 2006-02-16 at 01:09 +0100, Fredrik Lundh wrote:
> (but will there be a 2.6? isn't it time to start hacking on 3.0?)
We know at least there will never be a 2.10, so I think we still have
time.
-Barry
signature.asc
Description: This is a digitally signed mess
s than two printed pages. I can post it somewhere if people
> are interested.
>
Please submit a SourceForge patch so others can play with it!
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
greed. I'm not sure whether .get(onearg) should return None
or .default. I /think/ I want the latter, but I'd have to play with
some real code to know for sure.
-Barry
signature.asc
Description: This is a digitally signed message part
__
ing code.
I don't think it's worth a DeprecationWarning either. Slating it for
removal in 3.0 seems fine.
Everything else about your proposal seems great.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-
On Fri, 2006-02-17 at 00:43 -0500, Steve Holden wrote:
> Fredrik Lundh wrote:
> > Barry Warsaw wrote:
> >
> >
> >>We know at least there will never be a 2.10, so I think we still have
> >>time.
> >
> >
> > because there's no way
simply put, my brain knows what's right, but my heart doesn't and that's
why converting from one to the other is always a hiccup in the smooth
flow of coding. And while I'm sympathetic to MAL's design decisions,
the overlaying of the generalizations doesn't help.
-
. There would be no
> warning.
IIRC, when I brought this up ages ago, there was some grumbling that
multifile is useful for other than email/MIME applications. Still, I'm
+1 on PEP 4'ing it.
-Barry
signature.asc
Description: This is a digitally signed message part
__
t; or "wait for others to be -1"?
s/or/and/ ? :)
I say go ahead and add it to PEP 4.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
ecessary for 2.3.
IIUC, there are still people who prefer Tamito's package over the
built-in Japanese codecs in 2.4, but I don't understand all the details.
My preference would be to backport the fix to 2.4 but not worry about
2.3 since there are no plans to ever release a 2.3.6 AFAIK.
Guido's subclass in a separate module. But I /wouldn't/ clutter the
built-in dict's API with on_missing().
-Barry
P.S.
_missing = object()
def getdefault(self, key, factory):
value = self.get(key, _missing)
if value is _missing:
On Feb 23, 2006, at 4:41 PM, Thomas Wouters wrote:
> On Wed, Feb 22, 2006 at 10:29:08PM -0500, Barry Warsaw wrote:
>> d.getdefault('foo', list).append('bar')
>
>> Anyway, I don't think it's an either/or choice with Guido's subclass.
>>
s lots of headaches on
certain, shall we say, non-Windows platforms.
-Barry
___
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%
y a newsreader and reading/replying via news.gmane.org
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
allables or sequences.
>
> OTOH, my personal style is to always use re.compile() because I can
> never remember the order of arguments for re.match()/re.search().
Agreed.
-Barry
signature.asc
Description: This is a digitally signed message part
_
f the user should type it, it should
not have underscores. If we grow a built-in next() -- which I'm -0 on,
then clearly it should get renamed to __next__() because then the user
would /not/ be expected to write it.
-Barry
signature.asc
De
On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote:
> OK, I tried to set eol-style on all of those. svn refused to change these:
>
> svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type property
Yeah, there's no reason for that, so I've fixed it.
-Barry
On Fri, 2006-03-03 at 23:43 -0500, Barry Warsaw wrote:
> On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote:
> > OK, I tried to set eol-style on all of those. svn refused to change these:
> >
> > svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type
semi-secret backing mailing
list, which I'd be happy for you to join!). I definitely think that
group of folks at the least should review the results.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev maili
id=5470&atid=305470
The patch also cleans up a couple of gcc warnings.
Thoughts?
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
On Mon, 2006-03-06 at 23:30 +, Neil Schemenauer wrote:
> Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > There are two patches on SF to add a couple of features to the gc
> > module. Skip wrote one (which I reviewed) and I wrote the other.
> > Neither is earth shatterin
is going to break a number of things; that's just inevitable.
What else do you expect to break? Should we at least try to describe
expected breakage in PEP 352?
-Barry
signature.asc
Description: This is a digitally signed message part
___
P
box for the standalone releases. email 4.0 is a little
different because I wanted to do the development outside Python to
reduce the chance of breakage, but I am planning on merging the code
back into the Python trunk, possibly this weekend.
-Barry
signature.asc
Desc
more than once in the list)?
Message.keys() returns them in order. Likewise .values() and .items().
> I really could go either way on all of these questions, though I think
> there's constraints -- answer one of the questions and another becomes
> obvious. But you can answer them i
bably more listish than I really would like.
Actually, my suspicion is that there won't be a general enough solution
to warrant inclusion in the stdlib. But hey, if you can create an 80%
solution, that would be nice.
-Barry
signature.asc
Description: This is a digitally signed message part
___
able to escape out of the critical section using a
> nested with: statement, as this would allow you to treat much of a program
> as single-threaded, and then selectively allow task switching. But I'm not
> sure what you'd call that API. :)
threading.unsynchronize()? Yikes.
-B
e usual headaches of managing three
versions of a package, it's working out quite well.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
gt; Someone please fix this.
>
> I'd much rather see us change imports to use absolute imports than to
> use relative imports in count-the-dots fashion. Could we add that to
> PEP 8?
+1
-Barry
signature.asc
Description: This is a digitally signed message part
_
n be set to None if a
> proper
> interpreter cannot be located.
As long as sys.executable behaving like a) doesn't change, that seems
fine with me. ;)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev
exposes a backward compatible API for email.parser.
The fix is simple, change 'P' to 'p' in the test, but I want to make
sure that nobody cares that __import__('email.Parser') now returns an
object that isn't a module, but acts enough like the original
On Fri, 2006-03-17 at 09:40 -0500, Barry Warsaw wrote:
> The fix is simple, change 'P' to 'p' in the test, but I want to make
> sure that nobody cares that __import__('email.Parser') now returns an
> object that isn't a module, but acts enough li
idiom for letting non-error exceptions pass
through.
I don't know whether this is possible for Python 2.5, but I think it
should be what we strive for for Py3K, and I do not think BaseException
is at all necessary.
-Barry
signature.asc
Descripti
re-position KeyboardInterrupt, and add Error as an alias for
StandardError. Then we can encourage people to start using Error as the
base classes for their own errors.
-Barry
signature.asc
Description: This is a digitally signed message part
___
27;s
general agreement on the hierarchy I proposed (so far so good :), then
I'd like to take a crack at implementing them.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
work
on putting together an SF patch for them over the weekend.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
I'm not sure I'd go as far as hiding Exception, since I don't think the
penalty is that great and it makes it easier to document.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-De
On Sat, 2006-03-18 at 19:22 -0500, Raymond Hettinger wrote:
> > [Barry Warsaw]
> >> Oh, also, we have a couple of additions to the PySet C API.
> >> I'll work on putting together an SF patch for them over the weekend.
>
> What are you proposing to add to the Py
2501 - 2600 of 2826 matches
Mail list logo
