headers
Anthony Baxter | 1 Apr 2005 05:27
Picon

Re: [Python-Dev] RE: python/dist/src/Lib/logging handlers.py, 1.19, 1.19.2.1

On Friday 01 April 2005 07:00, Raymond Hettinger wrote:
> >       Tag: release24-maint
> > 	handlers.py
> > Log Message:
> > Added optional encoding argument to File based handlers and improved
> > error handling for SysLogHandler
>
> Are you sure you want to backport an API change and new feature?

What Raymond said. Please don't add new features to the maintenance branch.

Anthony

--

-- 
Anthony Baxter     <anthony <at> interlink.com.au>
It's never too late to have a happy childhood.
Permalink | Reply | 0 comments |
headers
Brett C. | 1 Apr 2005 11:39
Picon

python-dev Summary for 2005-03-16 through 2005-03-31 [draft]

OK, so here is my final Summary.  Like to send it out some time this weekend so
please get corrections in ASAP.

--------------------------------

=====================
Summary Announcements
=====================

---------------
My last summary
---------------
So, after nearly 2.5 years, this is my final python-dev Summary.  Steve
Bethard, Tim Lesher, and Tony Meyer will be taking over for me starting with
the April 1 - April 15 summary (and no, this is not an elaborate April Fool's).
 I have learned a ton during my time doing the Summaries and I appreciate
python-dev allowing me to do them all this time.  Hopefully I will be able to
contribute more now in a programming capacity thanks to having more free time.

--------------------
PyCon was fantastic!
--------------------
For those of you who missed PyCon, you missed a great one!  It is actually my
favorite PyCon to date.  Already looking forward to next year.

--------------------
Python fireside chat
--------------------
Scott David Daniels requested a short little blurb from me expounding on my
thoughts on Python.  Not one to pass on an opportunity to just open myself and
(Continue reading)

Permalink | Reply | 3 comments |
headers
Walter Dörwald | 1 Apr 2005 13:17
Picon

Re: Pickling instances of nested classes

Samuele Pedroni wrote:

>> [...]
>> And having the full name of the class available would certainly help 
>> in debugging.
> 
> that's probably the only plus point but the names would be confusing wrt
>  modules vs. classes.

You'd propably need a different separator in repr. XIST does this:

 >>> from ll.xist.ns import html
 >>> html.a.Attrs.href
<attribute class ll.xist.ns.html:a.Attrs.href at 0x8319284>

> My point was that enabling reduce hooks at the metaclass level has
> propably other interesting applications, is far less complicated than
> your proposal to implement, it does not further complicate the notion of
> what happens at class creation time, and indeed avoids the
> implementation costs (for all python impls) of your proposal and still
> allows fairly generic solutions to the problem at hand because the
> solution can be formulated at the metaclass level.

Pickling classes like objects (i.e. by using the pickling methods in 
their (meta-)classes) solves only the second part of the problem: 
Finding the nested classes in the module on unpickling. The other 
problem is to add additional info to the inner class, which gets pickled 
and makes it findable on unpickling.

> If pickle.py is patched along these lines [*] (strawman impl, not much
(Continue reading)

Permalink | Reply | 2 comments |
headers
Samuele Pedroni | 1 Apr 2005 15:57
Favicon

Re: Pickling instances of nested classes

Walter Dörwald wrote:

> Samuele Pedroni wrote:
>
>>> [...]
>>> And having the full name of the class available would certainly help 
>>> in debugging.
>>
>>
>> that's probably the only plus point but the names would be confusing wrt
>>  modules vs. classes.
>
>
> You'd propably need a different separator in repr. XIST does this:
>
> >>> from ll.xist.ns import html
> >>> html.a.Attrs.href
> <attribute class ll.xist.ns.html:a.Attrs.href at 0x8319284>
>
>> My point was that enabling reduce hooks at the metaclass level has
>> propably other interesting applications, is far less complicated than
>> your proposal to implement, it does not further complicate the notion of
>> what happens at class creation time, and indeed avoids the
>> implementation costs (for all python impls) of your proposal and still
>> allows fairly generic solutions to the problem at hand because the
>> solution can be formulated at the metaclass level.
>
>
> Pickling classes like objects (i.e. by using the pickling methods in 
> their (meta-)classes) solves only the second part of the problem:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Terry Reedy | 1 Apr 2005 18:21
Picon
Favicon

Re: python-dev Summary for 2005-03-16 through 2005-03-31[draft]

>This led to a much more fleshed out design document
> (found in Python/compile.txt in the AST branch),

The directory URL

http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/?only_with_tag=ast-branch

or even the file URL

http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/Attic/compile.txt?rev=1.1.2.10&only_with_tag=ast-branch&view=auto

would be helpful to people not fully familiar with the depository and the 
required prefix to 'Python' (versus 'python').  I initially found the 
two-year-old

ttp://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/ast/


>The idea of moving docstrings after a 'def' was proposed

/after/before/


_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Scott David Daniels | 1 Apr 2005 19:01
Picon
Favicon

Re: python-dev Summary for 2005-03-16 through 2005-03-31 [draft]

Brett C. wrote:
> ... I figured I would take up the idea.  So hear
                                          ^^   here  ^^
> we go.
> 

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Walter Dörwald | 1 Apr 2005 21:29
Picon

Re: Pickling instances of nested classes

Samuele Pedroni wrote:

> [...]
> 
> this should approximate that behavior better: [not tested]
> 
>   import sys
> 
>  ....
>  def __new__(cls, name, bases, dic):
>      sub = [x for x in dic.values() if isinstance(x,HierarchMeta)]
>      newtype = type.__new__(cls, name, bases, dic)
>      for x in sub:
>          if not hasattr(x, '_outer_') and 
> getattr(sys.modules.get(x.__module__), x.__name__, None) is not x:
>               x._outer_ = newtype
>      return newtype
> 
>  .....
> 
> we don't set _outer_ if a way to pickle the class is already there

This doesn't fix

class Foo:
    class Bar:
       pass

class Baz:
    Bar = Foo.Bar
(Continue reading)

Permalink | Reply | 0 comments |
headers
Evan Jones | 1 Apr 2005 21:36
Picon
Picon
Favicon

Unicode byte order mark decoding

I recently rediscovered this strange behaviour in Python's Unicode 
handling. I *think* it is a bug, but before I go and try to hack 
together a patch, I figure I should run it by the experts here on 
Python-Dev. If you understand Unicode, please let me know if there are 
problems with making these minor changes.

 >>> import codecs
 >>> codecs.BOM_UTF8.decode( "utf8" )
u'\ufeff'
 >>> codecs.BOM_UTF16.decode( "utf16" )
u''

Why does the UTF-16 decoder discard the BOM, while the UTF-8 decoder 
turns it into a character? The UTF-16 decoder contains logic to 
correctly handle the BOM. It even handles byte swapping, if necessary. 
I propose that  the UTF-8 decoder should have the same logic: it should 
remove the BOM if it is detected at the beginning of a string. This 
will remove a bit of manual work for Python programs that deal with 
UTF-8 files created on Windows, which frequently have the BOM at the 
beginning. The Unicode standard is unclear about how it should be 
handled (version 4, section 15.9):

> Although there are never any questions of byte order with UTF-8 text, 
> this sequence can serve as signature for UTF-8 encoded text where the 
> character set is unmarked. [...] Systems that use the byte order mark 
> must recognize when an initial U+FEFF signals the byte order. In those 
> cases, it is not part of the textual content and should be removed 
> before processing, because otherwise it may be mistaken for a 
> legitimate zero width no-break space.
(Continue reading)

Permalink | Reply | 34 comments |
headers
M.-A. Lemburg | 1 Apr 2005 22:19
Favicon

Re: Unicode byte order mark decoding

Evan Jones wrote:
> I recently rediscovered this strange behaviour in Python's Unicode
> handling. I *think* it is a bug, but before I go and try to hack
> together a patch, I figure I should run it by the experts here on
> Python-Dev. If you understand Unicode, please let me know if there are
> problems with making these minor changes.
> 
> 
>>>> import codecs
>>>> codecs.BOM_UTF8.decode( "utf8" )
> u'\ufeff'
>>>> codecs.BOM_UTF16.decode( "utf16" )
> u''
> 
> Why does the UTF-16 decoder discard the BOM, while the UTF-8 decoder
> turns it into a character? 

The BOM (byte order mark) was a non-standard Microsoft invention
to detect Unicode text data as such (MS always uses UTF-16-LE for
Unicode text files).

It is not needed for the UTF-8 because that format doesn't rely on
the byte order and the BOM character at the beginning of a stream is
a legitimate ZWNBSP (zero width non breakable space) code point.

The "utf-16" codec detects and removes the mark, while the
two others "utf-16-le" (little endian byte order) and "utf-16-be"
(big endian byte order) don't.

> The UTF-16 decoder contains logic to
(Continue reading)

Permalink | Reply | 33 comments |
headers
Brett C. | 1 Apr 2005 22:52
Picon

Re: Re: python-dev Summary for 2005-03-16 through 2005-03-31[draft]

Terry Reedy wrote:
>>This led to a much more fleshed out design document
>>(found in Python/compile.txt in the AST branch),
> 
> 
> The directory URL
> 
> http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/?only_with_tag=ast-branch
> 
> or even the file URL
> 
> http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/Attic/compile.txt?rev=1.1.2.10&only_with_tag=ast-branch&view=auto
> 
> would be helpful to people not fully familiar with the depository and the 
> required prefix to 'Python' (versus 'python').  I initially found the 
> two-year-old
> 
> ttp://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/ast/
> 

Yeah, that has become a popular suggestion.  It has been fixed.  Just didn't
think about it.  One of those instances where I have been neck-deep in
python-dev for so long I forgot that not everyone has a CVS checkout.  =)

> 
> 
>>The idea of moving docstrings after a 'def' was proposed
> 
> 
> /after/before/
(Continue reading)

Permalink | Reply | 0 comments |

Gmane