Re: [Python-Dev] Comment regarding PEP 328

[Josiah Carlson]

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.
> 
> Hm. I'm not convinced that there is a *problem* with shadowing of
> standard library module names. You shouldn't pick a module name that
> shadows a standard library module, or if you do you shouldn't want to
> be able to still use those modules that you're shadowing. Anything
> else is just asking for trouble.

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.


> > More specifically; after a 'from __future__ import absolute_import'
> > statement, any import in the module performing "import foo" will only
> > check for foo in the standard library, and the use of the leading period,
> > "from . import foo", the will signify relative to the current path. **
> 
> And how exactly do you define "the standard library"? Anything that's
> on sys.path? That would seem the only reasonable interpretation to me.
> So I take it that you want the "script directory" off that path.
> (Let's for the sake of argument call it ".".)

Sounds reasonable to me, with one caveat; if one were to consider
everything on sys.path to be in the standard library, then every script
ever written for Python, which doesn't remove the standard ''/'.' from
sys.path, would be part of the standard library.

I would suggest, as a replacement definition (probably with a caveat or
two), that any module with a reference in the documentation, that also
lies on the default sys.path, which is shipped with Python that is
distributed at python.org, is part of the standard library.


> > The lack of a 'from __future__ import absolute_import' statement in a
> > module will not change the import semantic of that module.
> 
> It's hard to imagine how this would work. sys.path is global, so
> either "." is on it, or it isn't. So things in "." are either
> considered part of the standard library, or they are not; this can't
> be made dependent on the module's importation of something from
> __future__.

Perhaps not, but in the process of importing a module into a namespace,
one can check for the existance of the object imported from __future__,
and ignore or not the "." entry in sys.path.


> > This allows current code to continue to work, and for those who want to
> > choose names which shadow the standard library modules, a way of dealing
> > with their choices.
> 
> My suggested way of dealing with their choices is summarized in the
> first paragraph of my reply above.

Perfectly reasonable.  I can think of examples where it would not be
reasonable, but they are quite cooked *wink*.


> > Alternatively, PEP 328 could be implemented as-is, and a second future
> > import could be defined which offers this functionality, being
> > permanently optional (or on a different timeline) via the future import.
> 
> I don't like permanently optional language features; that causes too
> much confusion. I'd much rather settle on clear semantics that
> everyone can understand (even if they may disagree).
> 
> But I certainly would prefer that the proposed feature becomes a
> separate PEP which can be discussed, accepted or rejected, and
> implemented separately from PEP 328, which is complete and accepted
> and just awaiting someone to implement it.

Sounds good.  I'll see what I can do this weekend about getting a
proto-pep started.


> > Essentially, it would ignore the empty path "" in sys.path when the
> > functionality has been enabled via the proper future import in the
> > current module.
> 
> But it's not always "" -- it's the directory where the "main" script was 
> found.
> 
> Let me explain the biggest problem I see for your proposal: what would
> be the canonical name for a module imported using your "new relative
> semantics"? Remember, the canonical name of a module is its __name__
> attribute, and the key that finds it in the sys.modules dict. Because
> there's only one sys.modules dict (barring restricted execution
> sandboxes), the canonical name must be unique. So if there's a
> standard library module string, its canonical name is "string". Now
> suppose you have your own non-standard-linrary module read from a file
> string.py. What should its canonical name be? It can't be "string"
> because that's already reserved for the standard library module name.
> 
> The best solution I can think of for this off the top of my head is to
> somehow allow for the arrangement of a pseudo-package named __main__
> and to make all these non-standard-library modules reside (logically)
> in that module. If you can write a PEP along those lines you may be on
> to something -- but I expect that the way to turn it on is n

Re: [Python-Dev] UserString

[Barry Warsaw]

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 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 (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/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] UserString

[Barry Warsaw]

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 old Unix hacks).
> 
> On the other hand, LBYL in this context can result in race conditions
> and security vulnerabilities. "os.makedirs" is already a composite of
> many system calls, so all bets are off anyway, but for simpler 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/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __str__ vs. __unicode__

[Walter Dörwald]

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 be created
yet another special case. I'd vote -0 on that.
[...]
Here's the patch that implements this for int/long/float/unicode:
http://www.python.org/sf/1109424
Any movement on this?  +1 for making things work like str; if a subclass 
overrides __str__ it should use that method.  If correctness of what is
returned is a worry then a check could be tossed in before the value is 
returned.
It already works that way:
Python 2.5a0 (#1, Feb 24 2005, 16:25:04)
[GCC 2.96 2731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class u(unicode):
...  def __unicode__(self): return 42
...
>>> unicode(u("foo"))
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: coercing to Unicode: need string or buffer, int found
>>> class i(int):
...  def __int__(self): return "foo"
...
>>> int(i(42))
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: __int__ returned non-int (type str)
>>> class l(long):
...  def __long__(self): return "foo"
...
>>> long(l(42))
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: __long__ returned non-long (type str)
>>> class f(float):
...  def __float__(self): return "foo"
...
>>> float(f(42))
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: __float__ returned non-float (type str)
Bye,
   Walter Dörwald
___
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

Re: [Python-Dev] Comment regarding PEP 328

[Guido van Rossum]

> 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".

> > And how exactly do you define "the standard library"? Anything that's
> > on sys.path? That would seem the only reasonable interpretation to me.
> > So I take it that you want the "script directory" off that path.
> > (Let's for the sake of argument call it ".".)
> 
> Sounds reasonable to me, with one caveat; if one were to consider
> everything on sys.path to be in the standard library, then every script
> ever written for Python, which doesn't remove the standard ''/'.' from
> sys.path, would be part of the standard library.
> 
> I would suggest, as a replacement definition (probably with a caveat or
> two), that any module with a reference in the documentation, that also
> lies on the default sys.path, which is shipped with Python that is
> distributed at python.org, is part of the standard library.

This is not an operational definition for the sake of what you're
trying to accomplish; the import statement cannot possibly know which
modules are considered standard according to this definition.

> > > The lack of a 'from __future__ import absolute_import' statement in a
> > > module will not change the import semantic of that module.
> >
> > It's hard to imagine how this would work. sys.path is global, so
> > either "." is on it, or it isn't. So things in "." are either
> > considered part of the standard library, or they are not; this can't
> > be made dependent on the module's importation of something from
> > __future__.
> 
> Perhaps not, but in the process of importing a module into a namespace,
> one can check for the existance of the object imported from __future__,
> and ignore or not the "." entry in sys.path.

How would you recognize the "." entry in sys.path? (Remember "." is
just the name we give it, not its actual value.) It is not a fixed
string; it is not in a fixed position; it may even have been added
explicitly to sys.path in which case it should act as if its contents
was part of the standard library.

> > > This allows current code to continue to work, and for those who want to
> > > choose names which shadow the standard library modules, a way of dealing
> > > with their choices.
> >
> > My suggested way of dealing with their choices is summarized in the
> > first paragraph of my reply above.
> 
> Perfectly reasonable.  I can think of examples where it would not be
> reasonable, but they are quite cooked *wink*.

OK, then let's drop the issue -- my initial point was "this is not
broken so there's no need to fix it."

> > > Alternatively, PEP 328 could be implemented as-is, and a second future
> > > import could be defined which offers this functionality, being
> > > permanently optional (or on a different timeline) via the future import.
> >
> > I don't like permanently optional language features; that causes too
> > much confusion. I'd much rather settle on clear semantics that
> > everyone can understand (even if they may disagree).
> >
> > But I certainly would prefer that the proposed feature becomes a
> > separate PEP which can be discussed, accepted or rejected, and
> > implemented separately from PEP 328, which is complete and accepted
> > and just awaiting someone to implement it.
> 
> Sounds good.  I'll see what I can do this weekend about getting a
> proto-pep started.
[...]
> You make very good points about naming in sys.modules.  I will think
> about this and place some options in the proto-pep.

I recommend that you try to produce a working implementation (using
import hooks so you can write the whole thing in Python). This is
likely to clarify many of the semantic problems that I have tried to
hint at.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] textwrap.py wordsep_re

[Greg Ward]

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', 18)
> produces:
> aa 2005-
> 02-21

Oops!

> A slightly tweaked wordsep_re:
> textwrap.TextWrapper.wordsep_re =\
> re.compile(r'(\s+|'  # any whitespace
>r'[^\s\w]*\w+[a-zA-Z]-(?=[a-zA-Z]\w+)|' # hyphenated words
>r'(?<=[\w\!\"\'\&\.\,\?])-{2,}(?=\w))')   # em-dash
> print textwrap.fill('aa 2005-02-21', 18)
> behaves better:
> aa
> 2005-02-21

Post a patch to SF and assign it to me.  Make sure the unit tests still
pass, and add a new one that doesn't pass without your fix.  Pester me
mercilessly until I act on it.  (I think your change is probably fine,
but I need more time to examine it than I have right now.)

Greg
-- 
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
Cheops' Law: Nothing *ever* gets built on schedule or within budget.
___
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

[Python-Dev] Confusing "hasattr" behaviour

[J. David Ibanez]

 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, None, None, '')
 ...
 >>> a = A()
 >>> getattr(a, 'x')
 Traceback (most recent call last):
   File "", line 1, in ?
   File "", line 3, in get_x
 NameError: global name 'there_is_a_bug_here' is not defined
 >>> hasattr(a, 'x')
 False
Today I have spent a while to hunt down a couple of bugs in my application,
because "hasattr" was catching the exceptions.
I see there was a patch (#504714, three years ago) that addressed this, but
it was rejected because much code would get broken.
But, is it going to be considered for sometime in the future? 3.0 maybe?
And, would it really break so much code? Wouldn't it instead bring to the
day light many bugs that are already there (but failing in a more silent
way)?
Thanks,
--
J. David Ibáñez
Itaapy  Tel +33 (0)1 42 23 67 45
9 rue Darwin, 75018 Paris  Fax +33 (0)1 53 28 27 88 

___
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

Re: [Python-Dev] Comment regarding PEP 328

[Josiah Carlson]

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 library imports different from standard library
imports, we could fix module shadowing and perhaps gain a "bonus feature"
or two.

[...]

> > Sounds good.  I'll see what I can do this weekend about getting a
> > proto-pep started.
> [...]
> > You make very good points about naming in sys.modules.  I will think
> > about this and place some options in the proto-pep.
> 
> I recommend that you try to produce a working implementation (using
> import hooks so you can write the whole thing in Python). This is
> likely to clarify many of the semantic problems that I have tried to
> hint at.

Will do.

Thank you,
 - Josiah

___
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

Re: [Python-Dev] __str__ vs. __unicode__

[Brett C.]

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 __unicode__ case, we'd only be created
yet another special case. I'd vote -0 on that.
[...]

Here's the patch that implements this for int/long/float/unicode:
http://www.python.org/sf/1109424

Any movement on this?  +1 for making things work like str; if a 
subclass overrides __str__ it should use that method.  If correctness 
of what is
returned is a worry then a check could be tossed in before the value 
is returned.

It already works that way:
Python 2.5a0 (#1, Feb 24 2005, 16:25:04)
[GCC 2.96 2731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> class u(unicode):
...  def __unicode__(self): return 42
Well then I am +1 on doing this.
Since this is a semantic change probably need Guido to OK this?
-Brett
___
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

Re: [Python-Dev] a bunch of Patch reviews

[Martin v. Löwis]

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 test for special case
So what to do about this? Wait whether he revises the patch?
Accept anyway? Update the patch myself?
[ 1103350 ] send/recv SEGMENT_SIZE should be used more in socketmodule
So what do you propose to do? AFAICT, there is no definition of
SEGMENT_SIZE in a TCP implementation, and I think we should not try
to make up a value.
IMO, Python should expose sockets more or less "as-is". If the system
has a flaw, Python should expose it instead of working around it.
[ 1062014 ] fix for 764437 AF_UNIX socket special linux socket names
Can you please elaborate the problem? What is a "special linux socket
name"?
Regardless, the comment of the other reviewer is also valid: any patch
needs documentation and test cases.
Regards,
Martin
___
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

Re: [Python-Dev] textwrap.py wordsep_re

[Karl Chen]

> 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 fine, but I
Greg> need more time to examine it than I have right now.)

I had already posted a patch on Aahz's advice.  I'll write a unit
test.

-- 
Karl 2005-02-24 13:18
___
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

[Python-Dev] Re: Confusing "hasattr" behaviour

[Terry Reedy]

"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 confusing about it.  It is a simple getattr 
wrapper converting 'got something' to True and 'did not get anything' 
(raised an exception instead) to False.  Users should know this so they 
don't wastefully write 'if hasattr(o,n): x = getattr(o,n)'

[snip]
>Today I have spent a while to hunt down a couple of bugs in my 
>application,
>because "hasattr" was catching the exceptions.
[snip

If you want a different behavior, you can write your own version now, 
without waiting for a future that may never come, that only converts 
AttributeError to False and that possibly collapses all others to one type 
of your choosing.  To make sure that even this does not mask a bug, one 
needs to make sure that .__getattr__ methods do not pass on unintended 
bug-indicating AttributeErrors.

Terry J. Reedy



___
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

Re: [Python-Dev] Re: Confusing "hasattr" behaviour

[Just van Rossum]

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:
>return False
> 
> I am not sure what could be confusing about it.  It is a simple
> getattr wrapper converting 'got something' to True and 'did not get
> anything' (raised an exception instead) to False.  Users should know
> this so they don't wastefully write 'if hasattr(o,n): x =
> getattr(o,n)'

See also http://python.org/sf/504714

Just
___
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

Re: [Python-Dev] Comment regarding PEP 328

[Greg Ewing]

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, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

Re: [Python-Dev] Comment regarding PEP 328

[Guido van Rossum]

[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 Josiah would find out for himself while doing the
assigned homework of writing an implementation, saving him the effort
of writing a PEP. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Comment regarding PEP 328

[Josiah Carlson]

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 the next
> > zebra crossing.
> 
> [Guido van Rossum]
> I was hoping that Josiah would find out for himself while doing the
> assigned homework of writing an implementation, saving him the effort
> of writing a PEP. :-)

Gah that should have been "... in such a way that made standard library
imports different from user module/package imports ...".

I started on the implementation, and now know why PEP 328 probably
wasn't implemented in time for 2.4; import hooks can be ugly.

 - Josiah

___
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

RE: [Python-Dev] Re: PEP 754

[Warnes, Gregory R]

[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 faxed the "Contributor Agreement" to the PSF

I've also 
- created a patch on sourceforge.net for fpconst code and documentation
(see
https://sourceforge.net/tracker/index.php?func=detail&aid=1151323&group_id=5
470&atid=305470)

I will need help connecting the included test functions into the python test
suite.

What else needs to be done to allow fpconst to go into the Python library?  

-Greg

> -Original Message-
> From: Tim Peters [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 10, 2004 1:43 PM
> To: Warnes, Gregory R; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Python-Dev] Re: PEP 754
> 
> 
> [Warnes, Gregory R]
> > Hi David & Tim,
> >
> > First, I really like to see this go forward.  The fpconst module is
> > getting alot of use across the net, and it would be very useful to
> > finally get it into the standard python library.  What 
> needs to be done
> > to move forward?
> 
> Looks to me like exactly the same stuff as was needed before. 
>  Guido needs
> to pronounce on it.  It needs a patch on SourceForge, adding 
> the new module,
> new docs, and a test suite run by Python's standard regrtest.py.  The
> non-PSF copyright and license remain problematic.  That last should be
> easier to deal with after the PSF approves a Contributor 
> Agreement (probably
> within a month), but will be a show-stopper if Pfizer won't 
> contribute the
> module under the terms of the Contributor Agreement (which 
> can't be answered
> now by anyone, since the Contributor Agreement doesn't exist yet).
> 
> 
> 


LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be 
privileged. It is intended for the addressee(s) only. Access to this E-mail by 
anyone else is unauthorized. If you are not an addressee, any disclosure or 
copying of the contents of this E-mail or any action taken (or not taken) in 
reliance on it is unauthorized and may be unlawful. If you are not an 
addressee, please inform the sender immediately.

___
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

[Python-Dev] Re: Comment regarding PEP 328

[Steve Holden]

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 the next
zebra crossing.
[Guido van Rossum]
I was hoping that Josiah would find out for himself while doing the
assigned homework of writing an implementation, saving him the effort
of writing a PEP. :-)

Gah that should have been "... in such a way that made standard library
imports different from user module/package imports ...".
I started on the implementation, and now know why PEP 328 probably
wasn't implemented in time for 2.4; import hooks can be ugly.
 - Josiah
Hear, hear. If you'd like a working database import module to play with 
I can oblige, thanks to the assistance of many willing hands.

The import arena is full of obsolete hooks and other cruft and, while I 
can't help feeling that it would benefit from a complete redefinition I 
suspect that breakage-avoidance might require that waits until 3.0.

regards
 Steve
___
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

Re: [Python-Dev] __str__ vs. __unicode__

[Brett C.]

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 touch the __unicode__ case, we'd only be created
yet another special case. I'd vote -0 on that.
[SNIP]
Since this is a semantic change probably need Guido to OK this?
... which we now have.  Assigned the patch to myself.  I will get to it 
eventually.
-Brett
___
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

[Python-Dev] python-dev Summary for 2005-01-16 through 2005-01-31 [draft]

[Brett C.]

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 navigate.  Details are in the 
Summary Announcements section.  And you can ignore XXX and any %s points since 
this is just a direct paste of the template I use for generating the Summaries.

I am hoping to get this summary out either Saturday or Sunday since I am 
anxious to try out AMK's new RSS feed for the Summaries (see the Intro section 
or Summary Announcements for the URI).


python-dev Summary for %(start_ISO_date)s through %(end_ISO_date)s

.. contents::
=
Intro
=
This is a summary of traffic on the `python-dev mailing list`_ from
%(start_traditional_date)s through %(end_traditional_date)s.
It is intended to inform the wider Python community of on-going
developments on the list on a semi-monthly basis.  An archive_ of
previous summaries is available online.
An `RSS feed`_ of the titles of the summaries is available.
You can also watch comp.lang.python or comp.lang.python.announce for
new summaries (or through their email gateways of python-list or
python-announce, respectively, as found at http://mail.python.org).
This is the XXX summary written by Brett Cannon (XXX).
To contact me, please send email to brett at python.org.  Do *not*
post to comp.lang.python if you wish to reach me.
The `Python Software Foundation`_ is the non-profit organization that
holds the intellectual property for Python.  It also tries to forward
the development and use of Python.  If you find the python-dev Summary
helpful please consider making a donation.  You can make a donation at
http://python.org/psf/donations.html .  Every penny helps so even a
small donation with a credit card, check, or by PayPal helps.
If you are looking for a way to expand your knowledge of Python's
development and inner-workings, consider writing the python-dev
Summaries yourself!  I am willing to hand over the reins to someone
who is willing to do a comparable or better job of writing the
Summaries.  If you are interested, please email me at
brett at python.org.

Commenting on Topics

To comment on anything mentioned here, just post to
`comp.lang.python`_ (or email python-list@python.org which is a
gateway to the newsgroup) with a subject line mentioning what you are
discussing.  All python-dev members are interested in seeing ideas
discussed by the community, so don't hesitate to take a stance on
something.  And if all of this really interests you then get involved
and join `python-dev`_!
-
How to Read the Summaries
-
The in-development version of the documentation for Python can be
found at http://www.python.org/dev/doc/devel/ and should be used when
looking up any documentation on new code; otherwise use the current
documentation as found at http://docs.python.org/ .  PEPs (Python
Enhancement Proposals) are located at http://www.python.org/peps/ .
To view files in the Python CVS online, go to
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  Reported
bugs and suggested patches can be found at the SourceForge_ project
page.
Please note that this summary is written using reStructuredText_.
Any unfamiliar punctuation is probably markup for reST_ (otherwise it
is probably regular expression syntax or a typo =); you can safely
ignore it.  I do suggest learning reST, though; it's simple and is
accepted for `PEP markup`_ and can be turned into many different
formats like HTML and LaTeX.  Unfortunately, even though reSt is
standardized, the wonders of programs that like to reformat text do
not allow me to guarantee you will be able to run the text version of
this summary through Docutils_ as-is unless it is from the
`original text file`_.
.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _PEP Markup: http://www.python.org/peps/pep-0012.html
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. _last summary: http://www.python.org/dev/summary/%(html_prev_summary)s
.. _original text file: http://www.python.org/dev/summary/%(ht_name)s
.. _archive: http://www.python.org/dev/summary/
.. _RSS feed: http://www.python.org/dev/summary/channews.rdf

=
Summary Announcements
=
-
School sure likes to destroy my free time
-
A month late, that much clo

Re: [Python-Dev] UserString

[Andrew McNamara]

>> 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 (except for old Unix hacks).
>
>Guilty as charged. ;)

The consistency of the semantics of core system calls is sort of trademark
of unix. Any system that claims to be Unix, but plays loose and fast
with semantics soon gets a very poor reputation (xenix, cough).

All well-coded unix apps are dependent on system calls returning
consistent errno's. Which is one thing that makes life so difficult for
"posix" environments layered on other operating systems.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
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