>> You have a lot more faith in the errno module than I do. Are you sure
>> the same error codes work on all platforms where Python works?
>
>No, but I'm pretty confident the symbolic names for the errors are
>consistent for any platform I've cared about .
>
>> It's also not exactly readable (exce
A month late. Glad I don't get paid for this or I probably would have been
fired by now. =)
For this summary draft I am bringing back the header this one time in hopes of
getting some proof-reading of it. I did a major restructuring with some
accompanying rewrites to make it easier to naviga
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 hooks, I'd be +1 on that.
If we only t
Josiah Carlson wrote:
Guido van Rossum <[EMAIL PROTECTED]> wrote:
[Josiah Carlson]
if we could change import in such a
way that made standard library imports different from standard library
imports, we could
[Greg Ewing]
...go on to prove that black is white and get
ourselves killed by a python on
[After a long delay, the thread continues]
Hi All,
I'm pushing ahead on the tasks necessary to add the 'fcponst' module
described in PEP 754: IEEE 754 Floating Point Special Values.
Per http://www.python.org/psf/contrib, I've
- Changed the license to the Apache License, Version 2.0
- Just
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> [Josiah Carlson]
> > > if we could change import in such a
> > > way that made standard library imports different from standard library
> > > imports, we could
>
> [Greg Ewing]
> > ...go on to prove that black is white and get
> > ourselves killed
[Josiah Carlson]
> > if we could change import in such a
> > way that made standard library imports different from standard library
> > imports, we could
[Greg Ewing]
> ...go on to prove that black is white and get
> ourselves killed by a python on the next
> zebra crossing.
I was hoping that Jos
Josiah Carlson wrote:
if we could change import in such a
way that made standard library imports different from standard library
imports, we could
...go on to prove that black is white and get
ourselves killed by a python on the next
zebra crossing.
--
Greg Ewing, Computer Science Dept, +--
Terry Reedy wrote:
>
> "J. David Ibanez" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> Given that the behavior of hasattr is clearly defined in Lib Manual
> 2.1 as equivalent to
>
> def hasattr(obj, name):
> try:
> getattr(obj, name)
> return True
> except:
>
"J. David Ibanez" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Given that the behavior of hasattr is clearly defined in Lib Manual 2.1 as
equivalent to
def hasattr(obj, name):
try:
getattr(obj, name)
return True
except:
return False
I am not sure what could be co
> On 2005-02-24 05:04 PST, Greg Ward writes:
Greg> Post a patch to SF and assign it to me. Make sure the
Greg> unit tests still pass, and add a new one that doesn't
Greg> pass without your fix. Pester me mercilessly until I
Greg> act on it. (I think your change is probably f
Irmen de Jong wrote:
I've looked at one bug and a bunch of patches and
added a comment to them:
Thanks! I have now processed the ones for which I found guidance.
As for the remaining ones:
[ 756021 ] Allow socket.inet_aton('255.255.255.255') on Windows
Looks good but added suggestion about when to
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 hooks, I'd be +1 on that.
If we only touch the __unico
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Sure. There are lots of FAQs whose answer is not "Python will have to change".
And I'm not saying Python has to change either, hence the initial query
and planned PEP. Boiling it down; if we could change import in such a
way that made standard librar
Python 2.4 (#1, Feb 22 2005, 20:15:07)
[GCC 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
... def get_x(self):
... there_is_a_bug_here
... x = property(get_x, Non
On 21 February 2005, Karl Chen said:
> Except when the string to wrap contains dates -- which I would
> like not to be filled. In general I think wordsep_re can be
> smarter about what it decides are hyphenated words.
>
> For example, this code:
> print textwrap.fill('aa 2005-02-21',
> While I personally don't tend to use names previously existing in
> the standard library, seemingly a large number of people do, hence the
> not-so-rare threads on comp.lang.python which ask about such things.
Sure. There are lots of FAQs whose answer is not "Python will have to change".
> > An
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 hooks, I'd be +1 on that.
If we only touch the __unicode__ case, we'd only b
On Tue, 2005-02-22 at 19:14, Andrew McNamara wrote:
> >> if e.errno <> errno.EEXIST:
> >> raise
> >
> >You have a lot more faith in the errno module than I do. Are you sure
> >the same error codes work on all platforms where Python works? It's
> >also not exactly readable (except for ol
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 modul
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > In a recent discussion in a SF patch, I noticed that PEP 328* only seems
> > to support relative imports within packages, while bare import
> > statements use the entirety of sys.path, not solving the shadowing of
> > standard library module names.
>
21 matches
Mail list logo
