Re: [Python-Dev] __str__ vs. __unicode__

[Bob Ippolito]

On Jan 19, 2005, at 4:40, Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
[...]
If you drop the base class for unicode, this already works.
That's cheating! ;)
My use case is an XML DOM API: __unicode__() should extract the
character data from the DOM. For Text nodes this is the text,
for comments and processing instructions this is u"" etc. To
reduce memory footprint and to inherit all the unicode methods,
it would be good if Text, Comment and ProcessingInstruction could
be subclasses of unicode.
It sounds like a really bad idea to have a class that supports both of 
these properties:
- unicode as a base class
- non-trivial result from unicode(foo)

Do you REALLY think this should be True?!
isinstance(foo, unicode) and foo != unicode(foo)
Why don't you just call this "extract character data" method something 
other than __unicode__?  That way, you get the reduced memory footprint 
and convenience methods of unicode, with none of the craziness.

-bob
___
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]

M.-A. Lemburg wrote:
Walter Dörwald wrote:
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
[...]
If you drop the base class for unicode, this already works.
That's cheating! ;)
My use case is an XML DOM API: __unicode__() should extract the
character data from the DOM. For Text nodes this is the text,
for comments and processing instructions this is u"" etc. To
reduce memory footprint and to inherit all the unicode methods,
it would be good if Text, Comment and ProcessingInstruction could
be subclasses of unicode.
This code in object.c:PyObject_Unicode() is responsible for
the sub-class version not doing what you'd expect:
if (PyUnicode_Check(v)) {
/* For a Unicode subtype that's not a Unicode object,
   return a true Unicode object with the same data. */
return PyUnicode_FromUnicode(PyUnicode_AS_UNICODE(v),
 PyUnicode_GET_SIZE(v));
}
So the question is whether conversion of a Unicode sub-type
to a true Unicode object should honor __unicode__ or not.
The same question can be asked for many other types, e.g.
floats (and __float__), integers (and __int__), etc.
 >>> class float2(float):
... def __float__(self):
... return 3.141
...
 >>> float(float2(1.23))
1.23
 >>> class int2(int):
... def __int__(self):
... return 42
...
 >>> int(int2(123))
123
I think we need general consensus on what the strategy
should be: honor these special hooks in conversions
to base types or not ?
I'd say, these hooks should be honored, because it gives
us more possibilities: If you want the original value,
simply don't implement the hook.
Maybe the string case is the real problem ... :-)
At least it seems that the string case is the exception.
So if we fix __str__ this would be a bugfix for 2.4.1.
If we fix the rest, this would be a new feature for 2.5.
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] __str__ vs. __unicode__

[Walter Dörwald]

Bob Ippolito wrote:
On Jan 19, 2005, at 4:40, Walter Dörwald wrote:
[...]
That's cheating! ;)
My use case is an XML DOM API: __unicode__() should extract the
character data from the DOM. For Text nodes this is the text,
for comments and processing instructions this is u"" etc. To
reduce memory footprint and to inherit all the unicode methods,
it would be good if Text, Comment and ProcessingInstruction could
be subclasses of unicode.
It sounds like a really bad idea to have a class that supports both of 
these properties:
- unicode as a base class
- non-trivial result from unicode(foo)

Do you REALLY think this should be True?!
isinstance(foo, unicode) and foo != unicode(foo)
Why don't you just call this "extract character data" method something 
other than __unicode__?
IMHO __unicode__ is the most natural and logical choice.
isinstance(foo, unicode) is just an implementation detail.
But you're right: the consequences of this can be a bit scary.
That way, you get the reduced memory footprint 
and convenience methods of unicode, with none of the craziness.
Without this craziness we wouldn't have discovered the problem. ;)
Whether this craziness gets implemented, depends on the solution
to this problem.
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] __str__ vs. __unicode__

[Alex Martelli]

On 2005 Jan 19, at 11:10, Bob Ippolito wrote:
Do you REALLY think this should be True?!
isinstance(foo, unicode) and foo != unicode(foo)
H -- why not?  In the generic case, talking about some class B, it 
certainly violates no programming principle known to me that 
"isinstance(foo, B) and foo != B(foo)"; it seems a rather common case 
-- ``casting to the base class'' (in C++ terminology, I guess) ``slices 
off'' some parts of foo, and thus equality does not hold.  If this is 
specifically a bad idea for the specific case where B is unicode, OK, 
that's surely possible, but if so it seems it should be possible to 
explain this in terms of particular properties of type unicode.

Alex
___
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] Getting rid of unbound methods: patch available

[M.-A. Lemburg]

Guido van Rossum wrote:
[me]
I'm not sure I understand how basemethod is supposed to work; I can't
find docs for it using Google (only three hits for the query mxTools
basemethod). How does it depend on im_class?

[Marc-Andre]
It uses im_class to find the class defining the (unbound) method:
def basemethod(object,method=None):
""" Return the unbound method that is defined *after* method in the
inheritance order of object with the same name as method
(usually called base method or overridden method).
object can be an instance, class or bound method. method, if
given, may be a bound or unbound method. If it is not given,
object must be bound method.
Note: Unbound methods must be called with an instance as first
argument.
The function uses a cache to speed up processing. Changes done
to the class structure after the first hit will not be noticed
by the function.
"""
...
This is how it is used in mixin classes to call the base
method of the overridden method in the inheritance tree (of
old-style classes):
class RequestListboxMixin:
def __init__(self,name,viewname,viewdb,context=None,use_clipboard=0,
 size=None,width=None,monospaced=1,events=None):
# Call base method
mx.Tools.basemethod(self, RequestListboxMixin.__init__)\
   (self,name,size,width,monospaced,None,events)
...
Without .im_class for the unbound method, basemethod would
seize to work since it uses this attribute to figure out
the class object defining the overriding method.

Well, you could always do what Timothy Delaney's autosuper recipe
does: crawl the class structure starting from object.__class__ until
you find the requested method. Since you're using a cache the extra
cost should be minimal.
That won't work, since basemethod() is intended for standard
classes (not new-style ones).
I realize that this requires you to issue a new release of mxTools to
support this, but you probably want to do one anyway to support other
2.5 features.
A new release wouldn't be much trouble, but I don't see any
way to fix the basemethod() implementation without also requiring
a change to the function arguments.
Current usage is basemethod(instance, unbound_method). In order
for basemethod to still be able to find the right class and
method name, I'd have to change that to basemethod(instance,
unbound_method_or_function, class_defining_method).
This would require all users of mx.Tools.basemethod() to
update their code base. Users will probably not understand
why this change is necessary, since they'd have to write
the class twice:
mx.Tools.basemethod(self,
RequestListboxMixin.__init__,
RequestListboxMixin)\
(self,name,size,width,monospaced,None,events)
Dropping the unbound method basically loses expressiveness:
without extra help from function attributes or other descriptors,
it would no longer be possible to whether a function is to be
used as method or as function. The defining namespace of the method
would also not be available anymore.
Hmm, I have a hard time seeing how you can get rid
off unbound methods while keeping bound methods - since
both are the same type :-)
Easy. There is a lot of code in the instance method type specifically
to support the case where im_self is NULL. All that code can be
deleted (once built-in exceptions stop using it).
So this is not about removing a type, but about removing
extra code. You'd still keep bound methods as separate
type.
I'm using PyMethod_Check() in mxProxy to automatically
wrap methods of proxied object in order to prevent references
to the object class or the object itself to slip by the
proxy. Changing the type to function object and placing
the class information into a function attribute would break
this approach. Apart from that the type change (by itself)
would not affect the eGenix code base.

Isn't mxProxy a weak referencing scheme? Is it still useful given
Python's own support for weak references?
Sure. First of all, mxProxy is more than just a weak referencing
scheme (in fact, that was only an add-on feature).
mxProxy allows you to wrap any Python object in way that hides
the object from the rest of the Python interpreter, putting
access to the object under fine-grained and strict control.
This is the main application space for mxProxy.
The weak reference feature was added later on, to work around
problems with circular references. Unlike the Python weak
referencing scheme, mxProxy allows creating weak references
to all Python objects (not just the ones that support the
Python weak reference protocol).
I would expect code in the following areas to make use
of the type check:
* language interface code (e.g. Java, .NET bridges)
Java doesn't have the concept of unbound methods, so I doubt it's
useful there. Remember that as far as how you call it, the unbound
method has no advantages over the f

Re: [Python-Dev] __str__ vs. __unicode__

[M.-A. Lemburg]

Walter Dörwald wrote:
M.-A. Lemburg wrote:
So the question is whether conversion of a Unicode sub-type
to a true Unicode object should honor __unicode__ or not.
The same question can be asked for many other types, e.g.
floats (and __float__), integers (and __int__), etc.
 >>> class float2(float):
... def __float__(self):
... return 3.141
...
 >>> float(float2(1.23))
1.23
 >>> class int2(int):
... def __int__(self):
... return 42
...
 >>> int(int2(123))
123
I think we need general consensus on what the strategy
should be: honor these special hooks in conversions
to base types or not ?

I'd say, these hooks should be honored, because it gives
us more possibilities: If you want the original value,
simply don't implement the hook.
Maybe the string case is the real problem ... :-)

At least it seems that the string case is the exception.
Indeed.
So if we fix __str__ this would be a bugfix for 2.4.1.
If we fix the rest, this would be a new feature for 2.5.
I have a feeling that we're better off with the bug fix than
the new feature.
__str__ and __unicode__ as well as the other hooks were
specifically added for the type constructors to use.
However, these were added at a time where sub-classing
of types was not possible, so it's time now to reconsider
whether this functionality should be extended to sub-classes
as well.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Jan 10 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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__

[Nick Coghlan]

M.-A. Lemburg wrote:
So if we fix __str__ this would be a bugfix for 2.4.1.
If we fix the rest, this would be a new feature for 2.5.

I have a feeling that we're better off with the bug fix than
the new feature.
__str__ and __unicode__ as well as the other hooks were
specifically added for the type constructors to use.
However, these were added at a time where sub-classing
of types was not possible, so it's time now to reconsider
whether this functionality should be extended to sub-classes
as well.
It seems oddly inconsistent though:
"""Define __str__ to determine what your class returns for str(x).
NOTE: This won't work if your class directly or indirectly inherits from str. If 
that is the case, you cannot alter the results of str(x)."""

At present, most of the type constructors need the caveat, whereas __str__ 
actually agrees with the simple explanation in the first line.

Going back to PyUnicode, PyObject_Unicode's handling of subclasses of builtins 
is decidedly odd:

Py> class C(str):
...   def __str__(self): return "I am a string!"
...   def __unicode__(self): return "I am not unicode!"
...
Py> c = C()
Py> str(c)
'I am a string!'
Py> unicode(c)
u''
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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__

[M.-A. Lemburg]

Nick Coghlan wrote:
M.-A. Lemburg wrote:
So if we fix __str__ this would be a bugfix for 2.4.1.
If we fix the rest, this would be a new feature for 2.5.

I have a feeling that we're better off with the bug fix than
the new feature.
__str__ and __unicode__ as well as the other hooks were
specifically added for the type constructors to use.
However, these were added at a time where sub-classing
of types was not possible, so it's time now to reconsider
whether this functionality should be extended to sub-classes
as well.

It seems oddly inconsistent though:
"""Define __str__ to determine what your class returns for str(x).
NOTE: This won't work if your class directly or indirectly inherits from 
str. If that is the case, you cannot alter the results of str(x)."""

At present, most of the type constructors need the caveat, whereas 
__str__ actually agrees with the simple explanation in the first line.

Going back to PyUnicode, PyObject_Unicode's handling of subclasses of 
builtins is decidedly odd:
Those APIs were all written long before there were sub-classes
of types.
Py> class C(str):
...   def __str__(self): return "I am a string!"
...   def __unicode__(self): return "I am not unicode!"
...
Py> c = C()
Py> str(c)
'I am a string!'
Py> unicode(c)
u''
Ah, looks as if the function needs a general overhaul :-)
This section should be do a PyString_CheckExact():
if (PyString_Check(v)) {
Py_INCREF(v);
res = v;
}
But before we start hacking the function, we need a general
picture of what we think is right.
Note, BTW, that there is also a tp_str slot that serves
as hook. The overall solution to this apparent mess should
be consistent for all hooks (__str__, tp_str, __unicode__
and a future tp_unicode).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Jan 10 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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__

[Nick Coghlan]

M.-A. Lemburg wrote:
Those APIs were all written long before there were sub-classes
of types.
Understood. PyObject_Unicode certainly looked like an 'evolved' piece of 
code :)
But before we start hacking the function, we need a general
picture of what we think is right.
Aye.
Note, BTW, that there is also a tp_str slot that serves
as hook. The overall solution to this apparent mess should
be consistent for all hooks (__str__, tp_str, __unicode__
and a future tp_unicode).
I imagine many people are like me, with __str__ being the only one of these 
hooks they use frequently (Helping out with the Decimal implementation is the 
only time I can recall using the slots for the numeric types, and I rarely need 
to deal with Unicode).

Anyway, they're heavy use suggests to me that __str__ and str() are likely to 
provide a good model for the desired behaviour - they're the ones that are 
likely to have been nudged in the most useful direction by bug reports and the like.

Regards,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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] Strange segfault in Python threads and linux kernel 2.6

[Michael Hudson]

Donovan Baarda <[EMAIL PROTECTED]> writes:

> G'day,
>
> I've Cc'ed this to zope-coders as it might affect other Zope developers
> and it had me stumped for ages. I couldn't find anything on it anywhere,
> so I figured it would be good to get something into google :-).
>
> We are developing a Zope2.7 application on Debian GNU/Linux that is
> using fop to generate pdf's from xml-fo data. fop is a java thing, and
> we are using popen2.Popen3(), non-blocking mode, and select loop to
> write/read stdin/stdout/stderr. This was all working fine.
>
> Then over the Christmas chaos, various things on my development system
> were apt-get updated, and I noticed that java/fop had started
> segfaulting. I tried running fop with the exact same input data from the
> command line; it worked. I wrote a python script that invoked fop in
> exactly the same way as we were invoking it inside zope; it worked. It
> only segfaulted when invoked inside Zope.
>
> I googled and tried everything... switched from j2re1.4 to kaffe, rolled
> back to a previous version of python, re-built Zope, upgraded Zope from
> 2.7.2 to 2.7.4, nothing helped. Then I went back from a linux 2.6.8
> kernel to a 2.4.27 kernel; it worked!
>
> After googling around, I found references to recent attempts to resolve
> some signal handling problems in Python threads. There was one post that
> mentioned subtle differences between how Linux 2.4 and Linux 2.6 did
> signals to threads.

You've left out a very important piece of information: which version
of Python you are using.  I'm guessing 2.3.4.  Can you try 2.4?

> So it seems this is a problem with Python threads and Linux kernel 2.6.
> The attached program demonstrates that it has nothing to do with Zope.
> Using it to run "fop-test /usr/bin/fop  fop installed will show the segfault. Running the same thing on a
> machine with 2.4 kernel will instead get the fop "usage" message. It is
> not a generic fop/java problem with 2.6 because the commented
> un-threaded line works fine. It doesn't seem to segfault for any
> command... "cat -" works OK, so it must be something about java
> contributing.
>
> After searching the Python bugs, the closest I could find was
> #971213
> .
>  Is
> this the same bug? Should I submit a new bug report? Is there any
> other way I can help resolve this?

I'd be astonished if this is the same bug.

The main oddness about python threads (before 2.3) is that they run
with all signals masked.  You could play with a C wrapper (call
setprocmask, then exec fop) to see if this is what is causing the
problem.  But please try 2.4.

> BTW, built in file objects really could use better non-blocking
> support... I've got a half-drafted PEP for it... anyone interested in
> it?

Err, this probably should be in a different mail :)

Cheers,
mwh

-- 
  If trees could scream, would we be so cavalier about cutting them
  down? We might, if they screamed all the time, for no good reason.
-- Jack Handey
___
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__

[Aahz]

On Wed, Jan 19, 2005, Walter D?rwald wrote:
> M.-A. Lemburg wrote:
>> 
>>Maybe the string case is the real problem ... :-)
> 
> At least it seems that the string case is the exception.
> So if we fix __str__ this would be a bugfix for 2.4.1.

Nope.  Unless you're claiming the __str__ behavior is new in 2.4?
(Haven't been following the thread closely.)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
___
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]

Nick Coghlan wrote:
[...]
I imagine many people are like me, with __str__ being the only one of 
these hooks they use frequently (Helping out with the Decimal 
implementation is the only time I can recall using the slots for the 
numeric types, and I rarely need to deal with Unicode).

Anyway, they're heavy use suggests to me that __str__ and str() are 
likely to provide a good model for the desired behaviour - they're the 
ones that are likely to have been nudged in the most useful direction by 
bug reports and the like.
+1
__foo__ provides conversion to foo, no matter whether foo is among the
direct or indirect base classes.
Simply moving the PyUnicode_Check() call in PyObject_Unicode() after the
__unicode__ call (after the PyErr_Clear() call) will implement this (but 
does not fix Nick's bug). Running the test suite with this change
reveals no other problems.

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] a bunch of Patch reviews

[Brett C.]

Martin v. Löwis wrote:
I think Brett Cannon now also follows this rule; it
really falls short enough in practice because (almost)
nobody really wants to push his patch bad enough to
put some work into it to review other patches.
Yes, I am trying to support the rule, but my schedule is nutty right now so my 
turn-around time is rather long at the moment.

-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] Unix line endings required for PyRun* breaking embedded Python

[Stuart Bishop]

There is a discussion going on at the moment in postgresql-general about 
plpythonu (which allows you write stored procedures in Python) and line 
endings. The discussion starts here:

  http://archives.postgresql.org/pgsql-general/2005-01/msg00792.php
The problem appears to be that things are working as documented in PEP-278:
  There is no support for universal newlines in strings passed to
  eval() or exec.  It is envisioned that such strings always have the
  standard \n line feed, if the strings come from a file that file can
  be read with universal newlines.
So what happens is that if a Windows or Mac user tries to create a 
Python stored procedure, it will go through to the server with Windows 
line endings and the embedded Python interpreter will raise a syntax 
error for everything except single line functions.

I don't think it is possible for plpythonu to fix this by simply 
translating the line endings, as this would require significant 
knowledge of Python syntax to do correctly (triple quoted strings and 
character escaping I think).

The timing of this thread is very unfortunate, as PostgreSQL 8.0 is 
being released this weekend and the (hopefully) last release of the 2.3 
series next week :-(

--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
___
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: Unix line endings required for PyRun* breakingembedded Python

[Fredrik Lundh]

Stuart Bishop wrote:

> I don't think it is possible for plpythonu to fix this by simply translating 
> the line endings, as 
> this would require significant knowledge of Python syntax to do correctly 
> (triple quoted strings 
> and character escaping I think).

of course it's possible: that's what the interpreter does when it loads
a script or module, after all...  or in other words,

print repr("""
""")

always prints "\n" (at least on Unix (\n) and Windows (\r\n)).

 



___
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: Unix line endings required for PyRun* breakingembedded Python

[Alex Martelli]

On 2005 Jan 20, at 00:14, Fredrik Lundh wrote:
Stuart Bishop wrote:
I don't think it is possible for plpythonu to fix this by simply 
translating the line endings, as
this would require significant knowledge of Python syntax to do 
correctly (triple quoted strings
and character escaping I think).
of course it's possible: that's what the interpreter does when it loads
a script or module, after all...  or in other words,
print repr("""
""")
always prints "\n" (at least on Unix (\n) and Windows (\r\n)).
Mac, too (but then, that IS Unix to all intents and purposes, nowadays).
Alex
___
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: Zen of Python

[Timothy Fitz]

On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne
<[EMAIL PROTECTED]> wrote:
> "Flat is better than nested" has one foot in concise powerful
> programming, the other foot in optimisation.
> 
> foo.bar.baz.arr involves 4 hashtable lookups. arr is just one hashtable 
> lookup.

I find it amazingly hard to believe that this is implying optimization
over functionality or clarity. There has to be another reason, yet I
can't think of any.
___
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: Zen of Python

[Phillip J. Eby]

At 07:03 PM 1/19/05 -0500, Timothy Fitz wrote:
On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne
<[EMAIL PROTECTED]> wrote:
> "Flat is better than nested" has one foot in concise powerful
> programming, the other foot in optimisation.
>
> foo.bar.baz.arr involves 4 hashtable lookups. arr is just one hashtable 
lookup.

I find it amazingly hard to believe that this is implying optimization
over functionality or clarity. There has to be another reason, yet I
can't think of any.
Actually, this is one of those rare cases where optimization and clarity go 
hand in hand.  Human brains just don't handle nesting that well.  It's easy 
to visualize two levels of nested structure, but three is a stretch unless 
you can abstract at least one of the layers.

For example, I can remember 'peak.binding.attributes' because the 'peak' is 
the same for all the packages in PEAK.  I can also handle 
'peak.binding.tests.test_foo' because 'tests' is also always the same.  But 
that's pretty much the limit of my mental stack, which is why PEAK's 
namespaces are organized so that APIs are normally accessed as 
'binding.doSomething' or 'naming.fooBar', instead of requiring people to 
type 'peak.binding.attributes.doSomething'.

Clearly Java developers have this brain-stack issue as well, in that you 
usually see Java imports set up to have a flat namespace within the given 
module... er, class.  You don't often see people creating 
org.apache.jakarta.foo.bar.Baz instances in their method bodies.

___
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 2004-12-01 through 2004-12-15 [draft]

[Brett C.]

Uh, life has been busy.
Will probably send this one out this weekend some time so please get 
corrections in before then.


=
Summary Announcements
=
PyCon_ 2005 is well underway.  The schedule is in the process of being 
finalized (just figuring out the order of the talks).  And there is still time 
for the early-bird registration price of $175 ($125 students) before it expires 
on January 28th.

Some day I will be all caught up with the Summaries...
.. _PyCon: http://www.pycon.org
=
Summaries
=
--
PEPS: those existing and gestating
--
[for emails on PEP updates, subscribe to python-checkins_ and choose the 'PEP' 
topic]
A proto-PEP covering the __source__ proposal from the `last summary`_ has been 
posted to python-dev.

`PEP 338`_ proposes how to modify the '-m' modifier so as to be able to execute 
modules contained within packages.

.. _python-checkins: http://mail.python.org/mailman/listinfo/python-checkins
.. _PEP 338: http://www.python.org/peps/pep-0338.html
Contributing threads:
  - `PEP: __source__ proposal <>`__
  - `PEP 338: Executing modules inside packages with '-m' <>`__
---
Deprecating modules
---
The xmllib module was deprecated but not listed in `PEP 4`_.  What does one do? 
 Well, this led to a long discussion on how to handle module deprecation.

With the 'warning' module now in existence, PEP 4 seemed to be less important. 
 It was generally agreed that listing modules in PEP 4 was no longer needed. 
It was also agreed that deleting deprecated modules was not needed; it breaks 
code and disk space is cheap.

It seems that no longer listing documentation and adding a deprecation warning 
is what is needed to properly deprecate a module.  By no longer listing 
documentation new programmers will not use the code since they won't know about 
it.  And adding the warning will let old users know that they should be using 
something else.

.. _PEP 4: http://www.python.org/peps/pep-0004.html
Contributing threads:
  - `Deprecated xmllib module <>`__
  - `Rewriting PEP4 <>`__
--
PR to fight the idea that Python is "slow"
--
An article_ in ACM TechNews that covered 2.4 had several mentions that Python 
was "slow" while justifying the slowness (whether it be flexibility or being 
fast enough).  Guido (rightfully) didn't love all of the "slow" mentions which 
I am sure we have all heard at some point or another.

The suggestions started to pour in on how to combat this.  The initial one was 
to have a native compiler.  The thinking was that if we compiled to a native 
executable that people psychologically would stop the association of Python 
being interpreted which is supposed to be slow.  Some people didn't love this 
idea since a native compiler is not an easy thing.  Others suggested including 
Pyrex with CPython, but didn't catch on (maintenance issue plus one might say 
Pyrex is not the most Pythonic solution).  This didn't get anywhere in the end 
beyond the idea of a SIG about the various bundling tools (py2app, py2exe, etc.).

The other idea was to just stop worrying about speed and move on stomping out 
bugs and making Python functionally more useful.  With modules in the stdlib 
being rewritten in C for performance reasons it was suggested we are putting 
out the perception that performance is important to us.  Several other people 
also suggested that we just not mention speed as a big deal in release notes 
and such.

This also tied into the idea that managers don't worry too much about speed as 
much as being able to hire a bunch of Python programmers.  This led to the 
suggestion of also emphasizing that Python is very easy to learn and thus is a 
moot point.  There are a good number of Python programmers, though; Stephan 
Deibel had some rough calculations that put the number at about 750K Python 
developers worldwide (give or take; rough middle point of two different 
calculations).

.. _article: http://gcn.com/vol1_no1/daily-updates/28026-1.html
Contributing threads:
  - `2.4 news reaches interesting places <>`__
===
Skipped Threads
===
- MS VC compiler versions
- Any reason why CPPFLAGS not used in compiling?
  Extension modules now compile with directories specified in the LDFLAGS 
and CPPFLAGS env vars
- adding key argument to min and max
  min and max now have a 'key' argument like list.sort
- Unicode in doctests
- SRE bug and notifications
- PyInt_FromLong returning NULL
- PyOS_InputHook enhancement proposal
- The other Py2.4 issue
- MinGW And The other Py2.4 issue
- Supporting Third Party Modules
- Python in education
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://

Re: [Python-Dev] Strange segfault in Python threads and linux kernel 2.6

[Donovan Baarda]

On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote:
> Donovan Baarda <[EMAIL PROTECTED]> writes:
[...]
> You've left out a very important piece of information: which version
> of Python you are using.  I'm guessing 2.3.4.  Can you try 2.4?

Debian Python2.3 (2.3.4-18), Debian kernel-image-2.6.8-1-686 (2.6.8-10),
and Debian kernel-image-2.4.27-1-686 (2.4.27-6)

> I'd be astonished if this is the same bug.
> 
> The main oddness about python threads (before 2.3) is that they run
> with all signals masked.  You could play with a C wrapper (call
> setprocmask, then exec fop) to see if this is what is causing the
> problem.  But please try 2.4.

Python 2.4 does indeed fix the problem. Unfortunately we are using Zope
2.7.4, and I'm a bit wary of attempting to migrate it all from 2.3 to
2.4. Is there any way this "Fix" can be back-ported to 2.3?

Note that this problem is being triggered when using 
Popen3() in a thread. Popen3() simply uses os.fork() and os.execvp().
The segfault is occurring in the excecvp'ed process. I'm sure there must
be plenty of cases where this could happen. I think most people manage
to avoid it because the processes they are popen'ing or exec'ing happen
to not use signals.

After testing a bit, it seems the fork() in Popen3 is not a contributing
factor. The problem occurs whenever os.execvp() is executed in a thread.
It looks like the exec'ed command inherits the masked signals from the
thread.

I'm not sure what the correct behaviour should be. The fact that it
works in python2.4 feels more like a byproduct of the thread mask change
than correct behaviour. To me it seems like execvp() should be setting
the signal mask back to defaults or at least the mask of the main
process before doing the exec.

> > BTW, built in file objects really could use better non-blocking
> > support... I've got a half-drafted PEP for it... anyone interested in
> > it?
> 
> Err, this probably should be in a different mail :)

The verboseness of the attached test code because of this issue prompted
that comment... so vaguely related :-)

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
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] Unix line endings required for PyRun* breaking embedded Python

[Skip Montanaro]

Stuart> I don't think it is possible for plpythonu to fix this by simply
Stuart> translating the line endings, as this would require significant
Stuart> knowledge of Python syntax to do correctly (triple quoted
Stuart> strings and character escaping I think).

I don't see why not.  If you treat the string as a file in text mode, I
think you'd replace all [\r\n]+ with \n, even if it was embedded in a
string:

>>> s
'from math import pi\r\n"""triple-quoted string embedding CR:\rrest of 
string"""\r\nprint 2*pi*7\r'
>>> open("foo", "w").write(s)   
>>> open("foo", "rU").read()
'from math import pi\n"""triple-quoted string embedding CR:\nrest of 
string"""\nprint 2*pi*7\n'

Just re.sub("[\r\n]+", "\n", s) and I think you're good to go.

Skip
___
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: Zen of Python

[Skip Montanaro]

Phillip> Actually, this is one of those rare cases where optimization
Phillip> and clarity go hand in hand.  Human brains just don't handle
Phillip> nesting that well.  It's easy to visualize two levels of nested
Phillip> structure, but three is a stretch unless you can abstract at
Phillip> least one of the layers.

Also, if you think about nesting in a class/instance context, something like

self.attr.foo.xyz()

says you are noodling around in the implementation details of self.attr (you
know it has a data attribute called "foo").  This provides for some very
tight coupling between the implementation of whatever self.attr is and your
code.  If there is a reason for you to get at whatever xyz() returns, it's
probably best to publish a method as part of the api for self.attr.

Skip
___
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: Zen of Python

[Stephen Thorne]

On Wed, 19 Jan 2005 19:03:25 -0500, Timothy Fitz <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne
> <[EMAIL PROTECTED]> wrote:
> > "Flat is better than nested" has one foot in concise powerful
> > programming, the other foot in optimisation.
> >
> > foo.bar.baz.arr involves 4 hashtable lookups. arr is just one hashtable 
> > lookup.
> 
> I find it amazingly hard to believe that this is implying optimization
> over functionality or clarity. There has to be another reason, yet I
> can't think of any.

What I meant to say was, 'flat is better than nested' allows you to
write more concise code, while also writing faster code.

Stephen.
___
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