Re: [Python-Dev] features i'd like [Python 3000] ... #3: fix super()

[Robey Pointer]

On 4 Dec 2006, at 3:13, Nick Coghlan wrote:

> Ben Wing wrote:
>> i don't like the current super() at all.  having to type super(Foo,
>> self).__init__(...) is messy, hard to remember, and error-prone.
>
> Yup.
>
>>  it
>> also introduces an unfortunate dependency in that the name of the  
>> class
>> (Foo) has to be hard-coded in the call, and if you change the  
>> class name
>> you also have to go and change all super() calls -- more chances for
>> errors.  as a result, i imagine there's a strong urge to just  
>> hardcode
>> the name of the parent -- a bad idea, and the reason why super() was
>> introduced in the first place.
>
> Also yup.
>
> The fact that these drawbacks are fairly obvious, yet nothing has  
> been done
> about them should suggest something to you about the difficulty of  
> actually
> solving this problem in a reliable fashion ;)
>
> The Python Cookbook has a few interesting approaches to making  
> cooperative
> super calls easier to write, but they all tend to have some kind of  
> drawback
> that makes them inappropriate for making part of the language core.
>
>> instead, `super' should work like in other languages.  a couple of  
>> ideas:
>>
>> -- super.meth(args) calls the superclass method `meth', in the  
>> same way 
>> that super(Foo, self).meth(args) currently works. (this is the same
>> syntax as in java.  this probably requires making `super' be a  
>> keyword,
>> although it might be possible to hack this by examining the  
>> current call
>> stack.)
>
> It's the implementation that's the real sticking point here, so  
> without code
> this idea isn't likely to go anywhere.

I was bitten by the urge to play with this today, and modified my  
previous "self" hack to handle "super" also, so that the following  
code works:

 class D (C):
 @method
 def sum(n):
 return super.sum(n * 2) - self.base

Posted as "evil2.py" here:

 http://www.lag.net/robey/code/surf/

Because hacking "super" requires having the class object handy, this  
one needs a metaclass to do its magic, which is a shame.  I guess if  
it was implemented inside the cpython compiler, it would be less of a  
problem.

robey

___
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] Exceptions *must*? be old-style classes?

[Robey Pointer]

Guido van Rossum wrote:
The base of the Exception hierarchy happens to be a classic class.
But why are they "required" to be classic?
More to the point, is this a bug, a missing feature, or just a bug in
the documentation for not mentioning the restriction?
   

It's an unfortunate feature; it should be mentioned in the docs; it
should also be fixed, but fixing it isn't easy (believe me, or it
would have been fixed in Python 2.2).
To be honest, I don't recall the exact reasons why this wasn't fixed
in 2.2; I believe it has something to do with the problem of
distinguishing between string and class exception, and between the
various forms of raise statements.
I think the main ambiguity is raise "abc", which could be considered
short for raise str, "abc", but that would be incompatible with except
"abc". I also think that the right way out of there is to simply
hardcode a check that says that raise "abc" raises a string exception
and raising any other instance raises a class exception. But there's a
lot of code that has to be changed.
It's been suggested that all exceptions should inherit from Exception,
but this would break tons of existing code, so we shouldn't enforce
that until 3.0. (Is there a PEP for this? I think there should be.)
 

There's actually a bug open on the fact that exceptions can't be 
new-style classes:

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470
I added some comments to try to stir it up but there ended up being a 
lot of confusion and I don't think I helped much.  The problem is that 
people want to solve the larger issues (raising strings, wanting to 
force all exceptions to be new-style, etc) but those all have long-term 
solutions, while the current bug just languishes.

robey
___
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] Open issues for 2.4.1

[Robey Pointer]

Anthony Baxter wrote:
So here's a list of open items I'm thinking about for the 2.4.1
release.
 - os.access handling unicode filenames
   I'm still thinking over whether this is going to cause more problems
   for people who find it works for some Python 2.4 and not others. I'm
   leaning towards saying that this is a bug fix, but I'd appreciate any 
   comments (pro or con). If no-one comments, I'll go with whatever my
   gut feeling says is the right answer.
 

(I've been lurking for a while but this is my first post.  I maintain 
paramiko and enjoy harrassing people on sourceforge to fix the new-style 
Exception bug that vexes me.  Nice to meet you all.) :)

I agree 100% with the arguments made over the past couple of weeks about 
strictly refusing to add new features to micro releases (like 2.4.1).  
But I don't think fixing the os.access bug is anything but a bug fix, 
and here's my rationale:

It's entirely possible that some python users have worked around this 
bug by special-casing their use of os.access to manually encode the 
filename, but that doesn't mean that bringing os.access behavior in line 
with the other filename methods should be considered a "feature add".  
Pretend there was a bug with "int" such that you could add any number to 
it except 1.  You can work around this bug by replacing "+1" with "+2-1" 
but it doesn't make it any less of a bug or any less important to fix.

In other words, I don't think that the argument "users may have written 
code to work around the bug" is a valid reason to not fix a bug.

robey
___
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] C API doc fix

[Robey Pointer]

Yesterday I ran into a bug in the C API docs.  The top of this page:

 http://docs.python.org/api/unicodeObjects.html

says:

Py_UNICODE
 This type represents a 16-bit unsigned storage type which is  
used by Python internally as basis for holding Unicode ordinals. On  
platforms where wchar_t is available and also has 16-bits, Py_UNICODE  
is a typedef alias for wchar_t to enhance native platform  
compatibility. On all other platforms, Py_UNICODE is a typedef alias  
for unsigned short.


This is incorrect on some platforms: on Debian, Py_UNICODE turns out  
to be 32 bits.

I'm not sure what the correct quote should be: Does python use  
wchar_t whenever it's available (16 bits or not)?

I solved my problem by realizing that I was going about things  
entirely wrong, and that I should use the python codecs from C and  
not worry about what Py_UNICODE contains.  However, I think we should  
fix the docs to avoid confusing others... or maybe it would be better  
to document what's in Py_UNICODE and suggest always using the codec  
methods?  I don't have a strong opinion either way.

robey

___
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] C API doc fix

[Robey Pointer]

On 29 Sep 2005, at 12:06, Steven Bethard wrote:

> On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
>
>> Yesterday I ran into a bug in the C API docs.  The top of this page:
>>
>>  http://docs.python.org/api/unicodeObjects.html
>>
>> says:
>>
>> Py_UNICODE
>>  This type represents a 16-bit unsigned storage type which is
>> used by Python internally as basis for holding Unicode ordinals. On
>> platforms where wchar_t is available and also has 16-bits, Py_UNICODE
>> is a typedef alias for wchar_t to enhance native platform
>> compatibility. On all other platforms, Py_UNICODE is a typedef alias
>> for unsigned short.
>>
>
> I believe this is the same issue that was brought up in May[1].  My
> impression was that people could not agree on a documentation patch.

Would it help if I tried my hand at it?  My impression so far is that  
extension coders should probably try not to worry about the size or  
content of Py_UNICODE.  (The thread seems to have wandered off into  
nowhere again...)


Py_UNICODE
This type represents an unsigned storage type at least 16-bits long  
(but sometimes more) which is used by Python internally as basis for  
holding Unicode ordinals. On platforms where wchar_t is available and  
also has 16-bits, Py_UNICODE is a typedef alias for wchar_t to  
enhance native platform compatibility.  In general, you should use  
PyUnicode_FromEncodedObject and PyUnicode_AsEncodedString to convert  
strings to/from unicode objects, and consider Py_UNICODE to be an  
implementation detail.


robey

___
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] status of development documentation

[Robey Pointer]

On 22 Dec 2005, at 3:51, Michael Hudson wrote:

> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>
>> Checked the python-list archives lately?  If you google c.l.python  
>> for the
>> word "documentation", you'll find recent megathreads with subjects  
>> like
>> "bitching about the documentation", "opensource documentation  
>> problems"
>> and "python documentation should be better" among the top hits.   
>> But if
>> you check the bug and patch trackers, you don't find many  
>> contributions.
>> Something's definitely broken.
>
> Hmm, it's this discussion again!  Let me make my point again!
>
> Writing good documentation is hard.

I can only speak for my own experience, but maybe it will help.  I  
once tried to help fix a piece of the python docs.  The description  
of Py_UNICODE on  was  
-- and still is -- incorrect.

Looking through my mail archives, I sent a patch on 10 October, which  
was apparently taken, but never showed up on the web site.  I emailed  
a few reminders, but was eventually told that I should email a third  
person -- who didn't have an email address.  At that point I passed  
the level of effort I was willing to put in. :)  I think I probably  
put more effort into it than an average person would, so I think the  
barriers of entry are much higher than they should be.

Perhaps something with fast feedback would work a lot better.  It  
seems to work well for Wikipedia.

robey

___
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] status of development documentation

[Robey Pointer]

On 23 Dec 2005, at 0:53, Reinhold Birkenfeld wrote:

> Robey Pointer wrote:
>> On 22 Dec 2005, at 3:51, Michael Hudson wrote:
>>
>>> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>>>
>>>> Checked the python-list archives lately?  If you google c.l.python
>>>> for the
>>>> word "documentation", you'll find recent megathreads with subjects
>>>> like
>>>> "bitching about the documentation", "opensource documentation
>>>> problems"
>>>> and "python documentation should be better" among the top hits.
>>>> But if
>>>> you check the bug and patch trackers, you don't find many
>>>> contributions.
>>>> Something's definitely broken.
>>>
>>> Hmm, it's this discussion again!  Let me make my point again!
>>>
>>> Writing good documentation is hard.
>>
>> I can only speak for my own experience, but maybe it will help.  I
>> once tried to help fix a piece of the python docs.  The description
>> of Py_UNICODE on <http://docs.python.org/api/unicodeObjects.html> was
>> -- and still is -- incorrect.
>
> The current docs were released on September 28. They are not  
> updated until
> the next Python release, so that's probably why your patch doesn't  
> show up there.
>
> That may not be a good thing. Documentation fixes should go online  
> much
> quicker than with every Python release, or am I mistaken?

Yes, I think that's obviously ridiculous on the face of it, since  
fixes to the python 2.4 docs may be useless by the time 2.5 comes  
out, and may be too late to help anyone anyway. :)

I'm glad I'm not the only one who found the process completely  
broken, at least.

robey

___
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] [Doc-SIG] that library reference, again

[Robey Pointer]

On 29 Dec 2005, at 18:58, David Goodger wrote:

> [Fredrik Lundh]
 I'm beginning to fear that I've wasted my time on a project
 that nobody's interested in.
>
> [David Goodger]
>>> Could be. I don't see HTML+PythonDoc as a significant improvement
>>> over LaTeX.
>
> [Fredrik Lundh]
>> Really?
>
> Yes, really.

Just out of curiosity (really -- not trying to jump into the flames)  
why not just use epydoc?  If it's good enough for 3rd-party python  
libraries, isn't that just a small step from being good enough for  
the builtin libraries?

robey

___
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] [Doc-SIG] that library reference, again

[Robey Pointer]

On 29 Dec 2005, at 23:13, Fredrik Lundh wrote:

> Robey Pointer wrote:
>>> [Fredrik Lundh]
>>>> Really?
>>>
>>> Yes, really.
>>
>> Just out of curiosity (really -- not trying to jump into the flames)
>> why not just use epydoc?  If it's good enough for 3rd-party python
>> libraries, isn't that just a small step from being good enough for
>> the builtin libraries?
>
> but epydoc is a docstring-based format, right?
>
> I'm trying to put together a light-weight alternative to the markup
> used for, primarily, the current library reference.
>
> moving all of (or parts of) the reference documentation in to the
> library source code would be an alternative, of course [1], but that
> would basically mean starting over from scratch.

I think that would be a good thing to do no matter what markup is  
used.  It always irritates me when I do 'help(sys.something)' and get  
one line of ASCII art that's probably useful to the module author but  
nobody else.

robey

___
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] [Doc-SIG] that library reference, again

[Robey Pointer]

On 30 Dec 2005, at 18:29, Christopher Armstrong wrote:

> On 12/30/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
>>
>> Just out of curiosity (really -- not trying to jump into the flames)
>> why not just use epydoc?  If it's good enough for 3rd-party python
>> libraries, isn't that just a small step from being good enough for
>> the builtin libraries?
>
> It's not really even "good enough" for a lot of my usage without some
> seriously evil hacks. The fundamental design decision of epydoc to
> import code, plus some other design decisions on the way it figures
> types and identity seriously hinder its utility. Ever notice how
> trying to document your third-party-library-using application will
> *also* document that third party library, for example? Or how it'll
> blow up when you're trying to document your gtk-using application on a
> remote server without an X server running? Or how it just plain blows
> right up with most Interface systems? etc.

Err... no, I haven't.  But I may be using a more recent version than  
you were (I'm using 2.1).  It's not perfect, and occasionally  
annoying, but much better than anything else I've found.  Sounds like  
there's some political reason it's hated, but thought I would bring  
it up anyway.

robey

___
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