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.
>
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
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
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
> 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
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',
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
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
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
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
> 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
"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
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:
>
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, +--
[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
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
[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
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
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
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
>> 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
21 matches
Mail list logo
