Re: [Python-Dev] Strategy for converting the decimal module to C

[Georg Brandl]

Raymond Hettinger wrote:
> Aahz wrote:
>> On Tue, Jul 18, 2006, Raymond Hettinger wrote:
>>   
>>> P.S.  The dictionary approach to context objects should likely be
>>> abandoned for the C version.  If the API has to change a bit, then so
>>> be it.
>>> 
>>
>> Why do you say that?  The rest I agree with; seems to me that making a
>> small wrapper for dict access works well, too.
>>   
> I think it was tripping-up the folks working on the C implementation. 
> Georg can speak to it more directly.  IIRC, the issue was that the
> context object exposed a dictionary which a user could update directly
> and there was no notification back to the surrounding object so it could
> update an underlying bitfield representation.

Yes, that's exactly what the problem was. Working with bitfields internally
is fine as long as Python code doesn't want to change the dicts exposed
as a wrapper.

>  If the current approach
> gets in their way, the C implementers should feel free to make an
> alternate design choice.

+1. (cDecimal is an ugly name, but a sound concept)

I don't know what progress Mateusz' work has made until now, but he wrote
at one time that he would "start optimizing as soon as he's certain that
it works".

Georg

___
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] Strategy for converting the decimal module to C

[Nick Coghlan]

Georg Brandl wrote:
> Raymond Hettinger wrote:
>>  If the current approach
>> gets in their way, the C implementers should feel free to make an
>> alternate design choice.
> 
> +1. (cDecimal is an ugly name, but a sound concept)
> 
> I don't know what progress Mateusz' work has made until now, but he wrote
> at one time that he would "start optimizing as soon as he's certain that
> it works".

dmath (decimal-math, modelled on cmath for complex-math) could work.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] [Python-checkins] r50708 - in python/trunk: Lib/test/test_sys.py Misc/NEWS Python/pystate.c

[Matt Fleming]

On 19/07/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Neal Norwitz schrieb:
> > On 7/18/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> >>
> >> were pre-2003 and talking about mod_python.  HURD and FreeBSD came up a
> >> couple times.  Do we need to add more *BSD buildbots?
> >
> > Yes.  We only have OpenBSD now.  It would be nice to have {Free,Net}BSD 
> > too..
>
> Maybe some of the buildbots should (in addition to the normal build?)
> configure Python with --without-threads?
>

I have an AMD64 NetBSD machine that isn't doing much at the moment, I
can regurlary run tests (I submitted a patch not long back to make
regrtest netbsd-3 aware). However, I can't turn it into a buildbot,
sorry.

Matt

--
http://mattssanctuary.blogspot.com
___
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] Strategy for converting the decimal module to C

[Raymond Hettinger]

  
I think it was tripping-up the folks working on the C implementation. 
Georg can speak to it more directly.  IIRC, the issue was that the
context object exposed a dictionary which a user could update directly
and there was no notification back to the surrounding object so it could
update an underlying bitfield representation.

  
  
Yes, that's exactly what the problem was. Working with bitfields internally
is fine as long as Python code doesn't want to change the dicts exposed
as a wrapper.
  


If you want to stick with dictionary-like access to traps and flags,
then use a dict subclass that overrides each of the mutating methods.

Even then, we need to drop the concept of having the flags as counters
rather than booleans.


Raymond




___
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] Strategy for converting the decimal module to C

[Georg Brandl]

Raymond Hettinger wrote:
> 
>>> I think it was tripping-up the folks working on the C implementation. 
>>> Georg can speak to it more directly.  IIRC, the issue was that the
>>> context object exposed a dictionary which a user could update directly
>>> and there was no notification back to the surrounding object so it could
>>> update an underlying bitfield representation.
>>> 
>>
>> Yes, that's exactly what the problem was. Working with bitfields internally
>> is fine as long as Python code doesn't want to change the dicts exposed
>> as a wrapper.
>>   
> 
> If you want to stick with dictionary-like access to traps and flags,
> then use a dict subclass that overrides each of the mutating methods.

That may be easiest to do in Python code. I'll leave it to Mateusz to decide.

> Even then, we need to drop the concept of having the flags as counters
> rather than booleans.

Yes. Given that even Tim couldn't imagine a use case for counting the
exceptions, I think it's sensible.

Georg

___
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] Strategy for converting the decimal module to C

[Nick Maclaren]

Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> > Even then, we need to drop the concept of having the flags as counters
> > rather than booleans.
>
> Yes. Given that even Tim couldn't imagine a use case for counting the
> exceptions, I think it's sensible.

Well, I can.  There is a traditional, important use - tuning.

When such arithmetic is implemented in hardware, it is normal for
exceptional cases to be handled by interrupt, and that is VERY
expensive - often 100-1,000 times the cost of a single operation,
occasionally 10,000 times.  It then becomes important to know how
many of the things you got, to know whether it is worth putting
code in to avoid them or even using a different algorithm.

Now, it is perfectly correct to say that this does not apply to
emulated arithmetic and that there is no justification for such
ghastly implementations.  But, regrettably, almost all exception
handling on modern systems IS ghastly - at least by the standards
of the 1960s.

Whether you regard the use of Python for tuning code that is to be
run using hardware, where the arithmetic will be performance-
critical as important, is a matter of taste.  I don't :-)


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
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] logging module broken because of locale

[Mihai Ibanescu]

On Tue, Jul 18, 2006 at 02:55:56PM -0400, Fred L. Drake, Jr. wrote:
> On Tuesday 18 July 2006 14:52, Mihai Ibanescu wrote:
>  > Unicode might be a perfectly acceptable suggestion for others too.
> 
> Are we still supporting builds that don't include Unicode?  If so, that needs 
> to be considered in a patch as well.

Good point. Does the attached patch look reasonable?

Thanks,
Misa
--- Python-2.4.3/Lib/logging/handlers.py.nolocale   2006-07-19 
12:15:46.0 -0400
+++ Python-2.4.3/Lib/logging/handlers.py2006-07-19 12:16:14.0 
-0400
@@ -44,6 +44,12 @@
 DEFAULT_SOAP_LOGGING_PORT   = 9023
 SYSLOG_UDP_PORT = 514
 
+# If python was not built with unicode support, use the str function instead
+# of the unicode type, and hope locale doesn't break things.
+
+if not hasattr(__builtins__, 'unicode'):
+unicode = str
+
 class BaseRotatingHandler(logging.FileHandler):
 """
 Base class for handlers that rotate log files at a certain point.
@@ -162,7 +168,7 @@
 """
 def __init__(self, filename, when='h', interval=1, backupCount=0, 
encoding=None):
 BaseRotatingHandler.__init__(self, filename, 'a', encoding)
-self.when = string.upper(when)
+self.when = unicode(when).upper()
 self.backupCount = backupCount
 # Calculate the real rollover interval, which is just the number of
 # seconds between rollovers.  Also set the filename suffix used when
@@ -642,10 +648,12 @@
 """
 We need to convert record level to lowercase, maybe this will
 change in the future.
+We convert it to unicode first, to avoid locale from changing the
+meaning of lower() and upper()
 """
 msg = self.log_format_string % (
 self.encodePriority(self.facility,
-string.lower(record.levelname)),
+unicode(record.levelname).lower()),
 msg)
 try:
 if self.unixsocket:
@@ -854,7 +862,7 @@
 ("GET" or "POST")
 """
 logging.Handler.__init__(self)
-method = string.upper(method)
+method = unicode(method).upper()
 if method not in ["GET", "POST"]:
 raise ValueError, "method must be GET or POST"
 self.host = host
___
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 sprint in NY and CA, Aug. 21-24

[Jeremy Hylton]

I'd like to repeat my invitation to spend a week at Google in
California or New York for a Python sprint.  We are hosting sprints at
our offices in Mountain View and New York City the week of Aug. 21,
Monday through Thursday.

We're planning to work broadly on Python 2.6 and Python 3000.  If
you're interested in the core implementation, the standard library,
the build process, or documentation, they're all in scope.  Working on
a test process using large community projects like Twisted and Zope
would be a great activity, too.

There's a wiki page with some more details:
 http://wiki.python.org/moin/GoogleSprint

Feel free to follow up with Neal or me if you have questions.

Jeremy
___
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] new security doc using object-capabilities

[Brett Cannon]

After various people suggesting object-capabilities, takling with Mark S. Miller of the E programming language, and the people Mark works with at HP Labs (who have been giving talks every week during this month here at Google on object-capabilities), I have decided to go with object-capabilities for securing interpreters.  I have rewritten my design doc from scratch and deleted the old one.  The new doc is named securing_python.txt and can be found through the svn web interface at 
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
 .  I have pretty much ignored any concrete API and such and gone more with a conceptual doc to make sure the API does not get in the way of the core security model.Using object-capabilities should make the implementation much cleaner.  There is much less work directly on the interpreter and more of it gets pushed up to extension modules.  I also have the okay of my supervisor to use this approach in my dissertation so this will get done.
Two things do fall out of all of this which will make development much more modular and easier.  First, the memory cap work just becomes a special build on its own; no need to tie into the security work.  So I will be cleaning up the bcannon-sandboxing branch code as it stands, and then either create a separate branch for the object-capabilities work, or create another branch for the memory cap stuff and shift the changes over there.  I will most likely do the former so as to not lose the history on the checkins.
I also plan to rewrite the import machinery in pure Python.  This will make the code much more maintainable and make creating proxies for the import machinery much easier.  I will be doing that in a directory in the sandbox initially since it needs to work from what Python has now (and possibly some new extension module code) before it can be integrated into the interpreter directly.  Anyone who wants to help with that can.  I already have some perliminary notes on the whole thing and I think it will be reasonably doable.
Anyway, there you go.  Here is to hoping I have thought this all through properly.  =)-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] new security doc using object-capabilities

[Ka-Ping Yee]

On Wed, 19 Jul 2006, Brett Cannon wrote:
> I have decided to go with object-capabilities for
> securing interpreters.  I have rewritten my design doc from scratch and
> deleted the old one.  The new doc is named securing_python.txt and can be
> found through the svn web interface at
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log.

This is amazing news!!  I'm going off to read your document right now.


-- ?!ng
___
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] new security doc using object-capabilities

[Michael Foord]

Brett Cannon wrote:
> After various people suggesting object-capabilities, takling with Mark 
> S. Miller of the E programming language, and the people Mark works 
> with at HP Labs (who have been giving talks every week during this 
> month here at Google on object-capabilities), I have decided to go 
> with object-capabilities for securing interpreters.  I have rewritten 
> my design doc from scratch and deleted the old one.  The new doc is 
> named securing_python.txt and can be found through the svn web 
> interface at 
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
>  
> 
>  
> .  I have pretty much ignored any concrete API and such and gone more 
> with a conceptual doc to make sure the API does not get in the way of 
> the core security model.
>

This may not be relevant or  possible, in which case I apologise, but 
the .NET model of creating application domains is extremely useful. It 
allows you to assign domains and run code within those domains. This 
means, for example, you can create a plugin system and run the plugins 
in a secure domain.

I realise that this was the intent of the original rexec module, and 
your proposed new design (which is very exciting) overcomes the 
difficulties in that approach. The only approach using the new system 
would be interprocess communication (?) with a trusted interpreter 
communicating with an un-trusted one. Would the communication layer need 
to be implemented as a C extension, or will a standard Python API be 
possible ? Hmmm maybe I should read your doc. :-)

Michael Foord
http://www.voidspace.org.uk/python/index.shtml

> Using object-capabilities should make the implementation much 
> cleaner.  There is much less work directly on the interpreter and more 
> of it gets pushed up to extension modules.  I also have the okay of my 
> supervisor to use this approach in my dissertation so this will get done.
>
> Two things do fall out of all of this which will make development much 
> more modular and easier.  First, the memory cap work just becomes a 
> special build on its own; no need to tie into the security work.  So I 
> will be cleaning up the bcannon-sandboxing branch code as it stands, 
> and then either create a separate branch for the object-capabilities 
> work, or create another branch for the memory cap stuff and shift the 
> changes over there.  I will most likely do the former so as to not 
> lose the history on the checkins.
>
> I also plan to rewrite the import machinery in pure Python.  This will 
> make the code much more maintainable and make creating proxies for the 
> import machinery much easier.  I will be doing that in a directory in 
> the sandbox initially since it needs to work from what Python has now 
> (and possibly some new extension module code) before it can be 
> integrated into the interpreter directly.  Anyone who wants to help 
> with that can.  I already have some perliminary notes on the whole 
> thing and I think it will be reasonably doable.
>
> Anyway, there you go.  Here is to hoping I have thought this all 
> through properly.  =)
>
> -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/fuzzyman%40voidspace.org.uk
>   

___
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] new security doc using object-capabilities

[Michael Foord]

Michael Foord wrote:
> Brett Cannon wrote:
>   
>> After various people suggesting object-capabilities, takling with Mark 
>> S. Miller of the E programming language, and the people Mark works 
>> with at HP Labs (who have been giving talks every week during this 
>> month here at Google on object-capabilities), I have decided to go 
>> with object-capabilities for securing interpreters.  I have rewritten 
>> my design doc from scratch and deleted the old one.  The new doc is 
>> named securing_python.txt and can be found through the svn web 
>> interface at 
>> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
>>  
>> 
>>  
>> .  I have pretty much ignored any concrete API and such and gone more 
>> with a conceptual doc to make sure the API does not get in the way of 
>> the core security model.
>>
>> 
>
> This may not be relevant or  possible, in which case I apologise, but 
> the .NET model of creating application domains is extremely useful. It 
> allows you to assign domains and run code within those domains. This 
> means, for example, you can create a plugin system and run the plugins 
> in a secure domain.
>
> I realise that this was the intent of the original rexec module, and 
> your proposed new design (which is very exciting) overcomes the 
> difficulties in that approach. The only approach using the new system 
> would be interprocess communication (?) with a trusted interpreter 
> communicating with an un-trusted one. Would the communication layer need 
> to be implemented as a C extension, or will a standard Python API be 
> possible ? Hmmm maybe I should read your doc. :-)
>
>   
Ok, started to read the doc - and realise it specifically addresses 
these issues. My apologies :-)

Michael
http://www.voidspace.org.uk/python/index.shtml

> Michael Foord
> http://www.voidspace.org.uk/python/index.shtml
>
>   
>> Using object-capabilities should make the implementation much 
>> cleaner.  There is much less work directly on the interpreter and more 
>> of it gets pushed up to extension modules.  I also have the okay of my 
>> supervisor to use this approach in my dissertation so this will get done.
>>
>> Two things do fall out of all of this which will make development much 
>> more modular and easier.  First, the memory cap work just becomes a 
>> special build on its own; no need to tie into the security work.  So I 
>> will be cleaning up the bcannon-sandboxing branch code as it stands, 
>> and then either create a separate branch for the object-capabilities 
>> work, or create another branch for the memory cap stuff and shift the 
>> changes over there.  I will most likely do the former so as to not 
>> lose the history on the checkins.
>>
>> I also plan to rewrite the import machinery in pure Python.  This will 
>> make the code much more maintainable and make creating proxies for the 
>> import machinery much easier.  I will be doing that in a directory in 
>> the sandbox initially since it needs to work from what Python has now 
>> (and possibly some new extension module code) before it can be 
>> integrated into the interpreter directly.  Anyone who wants to help 
>> with that can.  I already have some perliminary notes on the whole 
>> thing and I think it will be reasonably doable.
>>
>> Anyway, there you go.  Here is to hoping I have thought this all 
>> through properly.  =)
>>
>> -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/fuzzyman%40voidspace.org.uk
>>   
>> 
>
> ___
> 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/fuzzyman%40voidspace.org.uk
>
>   

___
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] Strategy for converting the decimal module to C

[Tim Peters]

...

[Raymond]
>> Even then, we need to drop the concept of having the flags as counters
>> rather than booleans.

[Georg Brandl]
> Yes. Given that even Tim couldn't imagine a use case for counting the
> exceptions, I think it's sensible.

That's not it -- someone will "find a use" for anything.  It's
unfortunate that we used a dict with counts because the /standard/
we're trying to meet requires no such thing, and clearly had a "pile
of on/off bits" model in mind.  Extending a standard without strong
need creates problems (for example, this one <0.5 wink>).
___
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] Strategy for converting the decimal module to C

[Greg Ewing]

Nick Maclaren wrote:

> When such arithmetic is implemented in hardware, it is normal for
> exceptional cases to be handled by interrupt, and that is VERY
> expensive ...  It then becomes important to know how
> many of the things you got, to know whether it is worth putting
> code in to avoid them or even using a different algorithm.

But couldn't you just put in an interrupt handler that
counts the interrupts, for the purpose of measurement?

--
Greg
___
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] Strategy for converting the decimal module to C

[Raymond Hettinger]

Tim Peters wrote:

  ...

[Raymond]
  
  

  Even then, we need to drop the concept of having the flags as counters
rather than booleans.
  

  
  
[Georg Brandl]
  
  
Yes. Given that even Tim couldn't imagine a use case for counting the
exceptions, I think it's sensible.

  
  
That's not it -- someone will "find a use" for anything.  It's
unfortunate that we used a dict with counts because the /standard/
we're trying to meet requires no such thing, and clearly had a "pile
of on/off bits" model in mind.  Extending a standard without strong
need creates problems (for example, this one <0.5 wink>).

  

What do you guys think about deprecating it for Py2.5?



Raymond



___
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] Pickling objects that return string from reduce

[Bruce Christensen]

Martin v. Löwis" wrote:

> If  obj has no __module__ attribute (or if it is None), pickle
> (didn't check cPickle) also does
> 
> for n, module in sys.module.items():
>   if "module-ignored": continue
>   if getattr(module, result, None) is obj:
>  break # use n as module name
> 
> If obj does have a __module__ attribute, it uses __import__
> to import the module, just to make sure it gets into sys.modules.

What is "module-ignored" above? It's obviously not a literal string...

--Bruce
___
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] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  398 open ( +5) /  3334 closed (+19) /  3732 total (+24)
Bugs:  904 open ( -4) /  6011 closed (+36) /  6915 total (+32)
RFE :  222 open ( -1) /   231 closed ( +2) /   453 total ( +1)

New / Reopened Patches
__

Fix for #1513611 and #1511497; xml.sax imports  (2006-07-10)
   http://python.org/sf/1519796  opened by  Žiga Seilnacht

telnetlib.py change to ease option handling.  (2006-07-10)
   http://python.org/sf/1520081  opened by  Ernest ter Kuile

Support for PyGetSetDefs in pydoc, inspect, and types  (2006-07-10)
   http://python.org/sf/1520294  opened by  Barry A. Warsaw

Distutils bugfix: Read $AR from the environment/Makefile.  (2006-07-11)
   http://python.org/sf/1520877  opened by  Douglas Greiman

make install change: Allow $DESTDIR to be relative  (2006-07-11)
   http://python.org/sf/1520879  opened by  Douglas Greiman

Fix tests that assume they can write to Lib/test  (2006-07-12)
   http://python.org/sf/1520904  opened by  Douglas Greiman

Don't produce core file in test_subprocess.py  (2006-07-12)
   http://python.org/sf/1520905  opened by  Douglas Greiman

Extra configurability for doctest TestCases  (2006-07-12)
   http://python.org/sf/1521051  opened by  Russell Keith-Magee

--help and --version long options  (2006-07-12)
CLOSED http://python.org/sf/1521179  opened by  Georg Brandl

smtplib login fails with aol smtp server  (2006-07-12)
   http://python.org/sf/1521196  opened by  Peter

Reintroduce index checking in 1-element ctypes arrays  (2006-07-13)
CLOSED http://python.org/sf/1521817  opened by  Thomas Heller

Fix grammatical errors in Doc/howto/doanddont.tex  (2006-07-13)
CLOSED http://python.org/sf/1521874  opened by  Collin Winter

Give Cookie.py its own _idmap  (2006-07-13)
   http://python.org/sf/1521882  opened by  Collin Winter

Add some explication to PEP 3100  (2006-07-13)
   http://python.org/sf/1522038  opened by  Collin Winter

Remove operator.truth() and operator.abs()  (2006-07-13)
   http://python.org/sf/1522059  opened by  Collin Winter

Improve docs for filter()  (2006-07-13)
CLOSED http://python.org/sf/1522211  opened by  Collin Winter

irda socket support  (2006-07-14)
   http://python.org/sf/1522400  opened by  ÇñÓ¢²¨

Tix.Grid patch  (2006-07-14)
   http://python.org/sf/1522587  opened by  klappnase

XML Test Runner for unittest module  (2006-07-14)
   http://python.org/sf/1522704  opened by  Sebastian Rittau

(partial?) fix for Misc/python-config.in  (2006-07-16)
   http://python.org/sf/1523356  opened by  M. Levinson

Var-default patch undid part of backtick to repr() patch  (2006-07-18)
CLOSED http://python.org/sf/1524429  opened by  Graham Horler

Fix Tkinter Tcl-commands memory-leaks  (2006-07-18)
   http://python.org/sf/1524639  opened by  Graham Horler

Fix --without-threads build error  (2006-07-18)
CLOSED http://python.org/sf/1524724  opened by  Matt Fleming

ConfigParser: accept leading whitespace on options+comments  (2006-07-18)
   http://python.org/sf/1524825  opened by  Ken Lalonde

Patches Closed
__

Patch for bug 1441486: bad unary minus folding in compiler  (2006-03-10)
   http://python.org/sf/1446922  closed by  nascheme

OpenVMS patches Modules directory  (2006-07-04)
   http://python.org/sf/1516912  closed by  nnorwitz

Rough documentation for xml.etree.ElementTree  (2006-06-10)
   http://python.org/sf/1504046  closed by  nnorwitz

turtle.py: correcting begin_fill  (2006-07-09)
   http://python.org/sf/1519566  closed by  loewis

pdb: fix for #1472251('run/runeval' commands bug)  (2006-04-18)
   http://python.org/sf/1472257  closed by  jakamkon

urllib2 redirection fix  (2006-07-01)
   http://python.org/sf/1515745  closed by  nnorwitz

Python long option support  (2006-05-03)
   http://python.org/sf/1481112  closed by  gbrandl

--help and --version long options  (2006-07-12)
   http://python.org/sf/1521179  closed by  gbrandl

Reintroduce index checking in 1-element ctypes arrays  (2006-07-13)
   http://python.org/sf/1521817  closed by  theller

Fix grammatical errors in Doc/howto/doanddont.tex  (2006-07-13)
   http://python.org/sf/1521874  closed by  gbrandl

Improve docs for filter()  (2006-07-13)
   http://python.org/sf/1522211  closed by  rhettinger

python / pythonw replacement in C  (2004-10-29)
   http://python.org/sf/1056561  closed by  etrepum

OS X: Can't use #!/usr/bin/pythonw  (2004-10-02)
   http://python.org/sf/1038911  closed by  etrepum

update the binhex module for Mach-O  (2005-06-14)
   http://python.org/sf/1220874  closed by  etrepum

Remove dependencies on the sets module  (2006-06-04)
   http://python.org/sf/1500609  closed by  gbrandl

ColorDelegator - Several bug fixes  (2006-04-30)
   http://python.org/sf/1479219  closed by  kbk

Var-default patch undid part of backtick to repr() patch  (2006-07-18)

Re: [Python-Dev] Pickling objects that return string from reduce

[Martin v. Löwis]

Bruce Christensen wrote:
>> If  obj has no __module__ attribute (or if it is None), pickle
>> (didn't check cPickle) also does
>>
>> for n, module in sys.module.items():
>>   if "module-ignored": continue
>>   if getattr(module, result, None) is obj:
>>  break # use n as module name
> 
> What is "module-ignored" above? It's obviously not a literal string...

It's skipped if module is None (skip dummy package entries)
or n=='__main__'.

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