[issue6683] smtplib authentication - try all mechanisms

[Ben Standefer]

Ben Standefer  added the comment:

Here is one work-around.  The default smtplib.SMTP.login() doesn't work
for StrongMail out of the box.

http://www.harelmalka.com/?p=94&cpage=1

--
nosy: +aguynamedben

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7388] Documentation: capitalizations of the word 'python' needed when used as a name

[Retro]

New submission from Retro :

There are 'python' typos in the Python tutorial in these titles:

(1) Tools for Working with Lists:
The following example shows an array of numbers stored as two byte
unsigned binary numbers (typecode "H") rather than the usual 16 bytes
per entry for regular lists of !!!python!!! (should be: Python) int objects

(2) Batteries Included:
Together, these modules and packages greatly simplify data interchange
between !!!python!!! (should be: Python) applications and other tools.


There may be other typos, but I only manage to find those two. Please
capitalize those two words. Thank you.

--
assignee: georg.brandl
components: Documentation
messages: 95666
nosy: Retro, georg.brandl
severity: normal
status: open
title: Documentation: capitalizations of the word 'python' needed when used as 
a name
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7388] Documentation: capitalizations of the word 'python' needed when used as a name

[Georg Brandl]

Changes by Georg Brandl :


--
keywords: +easy
priority:  -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1519816] urllib2 proxy does not work in 2.4.3

[Senthil Kumaran]

Senthil Kumaran  added the comment:

HTTP Proxy Authentication works on Windows and has been verified. Under
the situation of failure, we do not enough details. Closing this bug as
out-of-date as the reporter informed it worked on py2.5 and problem was
with py2.4.

--
assignee:  -> orsenthil
resolution:  -> out of date
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7389] Make decimal floating point be default, remove binary floating point

[Retro]

New submission from Retro :

The Python interpreter should have the decimal type built into its core.
The mechanism for dealing with decimal numbers should be handled by the
decimal type and not by the processor which spits binary floats. The
time is now. But ask yourself these questions:

Is this doable? If yes:
Would it break anything? If yes, note that:
Python 3.1 opposed to Python 3.0 also had major changes that break the
two appart.

I say go for revolutional change in Python 3.2. But the call is yours.

--
components: Interpreter Core
messages: 95668
nosy: Retro, gvanrossum
severity: normal
status: open
title: Make decimal floating point be default, remove binary floating point
type: feature request
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7389] Make decimal floating point be default, remove binary floating point

[Mark Dickinson]

Mark Dickinson  added the comment:

I think the bug tracker is the wrong place to discuss such a wide-
ranging and (currently) ill-specified change.  The python-list or 
python-ideas mailing lists might be better places.

Decimal in the core is out of the question for Python 3.2, thanks to PEP 
3003.  What *is* feasible at this stage is to replace the current slow 
Python implementation of the decimal module with a C version;  there's 
some ongoing work on that.

Removing binary floats from the core entirely sounds like a bad idea to 
me, for performance reasons.  And it probably couldn't be done before 
Python 4.x without breaking backwards compatibility.

I'm closing this for now;  if you're interested in this, please take the 
discussion to python-list or python-ideas.

--
nosy: +mark.dickinson
resolution:  -> later
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7390] inconsistent type return

[Sérgio Surkamp]

New submission from Sérgio Surkamp :

The type function returns inconsistent value depending on class hierarchy.

>>> class X:
... pass
... 
>>> x = X()
>>> type(x)

>>> class Y(object):
... pass
... 
>>> x = Y()
>>> type(x)

>>> 
>>> class Z(X):
... pass
...  
>>> x = Z()
>>> type(x)

>>> class K(Y):
... pass
...   
>>> x = K()
>>> type(x)


All should reply 'instance'. As long as I have read on documentation the
only way to change the type function return is by writing a
__metaclass__ (PEP3115).

--
components: Interpreter Core
messages: 95670
nosy: surkamp
severity: normal
status: open
title: inconsistent type return
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7390] inconsistent type return

[flox]

flox  added the comment:

The relevant documentation for Python 2.6 is there.
http://docs.python.org/reference/datamodel.html#new-style-and-classic-classes

The PEP 3115 is implemented for Python >= 3.0.

There's nothing wrong.

--
nosy: +flox

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7390] inconsistent type return

[Antoine Pitrou]

Antoine Pitrou  added the comment:

`instance` means it is an instance of an old-style class. Old-style
classes are classes which don't have `object` in their inheritance
hierarchy.
On the other hand, for instance new-style classes type() returns the
actual class.
Bottom line: this is by design. Of course in an ideal world (or in
Python 3) there are only new-style classes, but we had to maintain
compatibility, and that's why there are two slightly different object
models cohabiting in Python 2.x.

--
nosy: +pitrou
resolution:  -> invalid

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7390] inconsistent type return

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +alexandre.vassalotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5294] pdb "break" command messes up "continue"

[Swapnil Talekar]

Swapnil Talekar  added the comment:

The problem it seems is actually in the bdb module and not in pdb. The 
set_next function sets the current frame as stopframe but it does not 
specify the stoplineno. Hence it's always -1. When you do c(ontinue), 
set_continue just sets botframe as stopframe, if there are no breakpoints.  
Hence, stop_here wrongly returns True on every line event. To rectify 
this, set_next should also specify stoplineno for the stopframe and this 
should be checked in stop_here before returning True. Here is the patch.

--
nosy: +swapnil
type:  -> behavior
Added file: http://bugs.python.org/file15393/bdbdiff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7383] test_multiprocessing leaks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> R. David Murray  added the comment:
> 
> This started just after r76438, which is an additional test for
> multiprocessing.  Given build delays this is only a correlation not a
> definite cause, but it is suspicious.

I just checked, it was indeed introduced by r76438.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7383] test_multiprocessing leaks

[Jesse Noller]

Jesse Noller  added the comment:

Well, that's alarming. I'll back that out for now - I'm fairly disturbed 
it introduced leaks that bad.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7391] Re-title the "Using Backslash to Continue Statements" anti-idiom

[Neil Cerutti]

New submission from Neil Cerutti :

This "anti-idiom" is in the Python HOWTOs->Idioms and Anti-Idioms

The current title is "Using Backslash to Continue Statements"

However, using the line continuation character won't cause mysterious
problems in statements, but only in certain expressions, as the article
goes on to explain.

Moreover, the proposed solution of wrapping expressions in parentheses
is a syntax error in a statement, e.g.:

with (open(roster_path, 'r') as roster_file,
  open(disb_path, 'w') as out_file,
  open(report_path, 'w') as report_file):
File "C:\project\codxml.py", line 184
   with (open(roster_path, 'r') as roster_file,
   ^
SyntaxError: invalid syntax

I suggest that the title be changed to "Using Backslash to Continue
Expressions."

I'm sorry I don't know for sure when this HOWTO was first included in
the normal Python distribution.

--
assignee: georg.brandl
components: Documentation
messages: 95676
nosy: Horpner, georg.brandl
severity: normal
status: open
title: Re-title the "Using Backslash to Continue Statements" anti-idiom
versions: Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Jesse Noller]

Jesse Noller  added the comment:

I've commented out the test (therefore, reopening this) the test 
introduces a pretty bad refleak problem. Need to debug.

--
resolution: fixed -> accepted
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7383] test_multiprocessing leaks

[Jesse Noller]

Jesse Noller  added the comment:

I've backed it out on trunk and py3k. I've reopened the original bug to 
debug the refleak caused by the test.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Are these leaks caused by the test, or revealed by it?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Antoine Pitrou]

Antoine Pitrou  added the comment:

>From a quick command-line attempt, it seems that logging is the culprit:

>>> handler = logging.Handler()
[64370 refs]
>>> handler = logging.Handler()
[64383 refs]
>>> handler = logging.Handler()
[64396 refs]

--
nosy: +pitrou, vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Yes, test_logging has a serious tearDown() method to wipe installed
handlers.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Yes, test_logging has a serious tearDown() method to wipe installed
> handlers.

In general it would be nice if logging were more conservative (or
cautious) when it comes to keeping objects persistent. It is too easy to
fall into a trap and experience memory leaks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7383] test_multiprocessing leaks

[R. David Murray]

R. David Murray  added the comment:

I haven't looked at the test, but is it possible that the logging module
is creating state that isn't being cleaned up after the test completes?
 Test refleaks don't always mean refleaks in the underlying C code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5166] ElementTree and minidom don't prevent creation of not well-formed XML

[Andy]

Andy  added the comment:

I'm also of the opinion that this would be a valuable feature to have. I
think it's a reasonable expectation that an XML library produces valid
XML. It's particularly strange that ET would output XML that it can't
itself read. Surely the job of making the input valid falls on the XML
creator - that's the point of using libraries in the first place, to
abstract away from details like not being able to use characters in the
0-32 range, in the same way that ampersands etc are auto-escaped.
Granted, it's not as clear-cut here since the low-range ASCII characters
are likely to be less frequent and the strategy to handle them is less
clear. I think the sanest behaviour would be to raise an exception by
default, although a user-configurable option to replace or omit the
characters would also make sense. If impacting performance is a concern,
maybe it would make sense to be off by default, but I would have thought
that the single regex that could perform the check would have relatively
minimal impact - and it seems to be an acceptable overhead on the
parsing side, so why not on generation?

--
nosy: +strangefeatures

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6393] OS X: python3 from python-3.1.dmg crashes at startup

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Jesse Noller]

Jesse Noller  added the comment:

Yeah, I should have checked the tearDown stuff in the logging test suite

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1653416] print >> f, "Hello" produces no error: normal?

[Ronald Oussoren]

Ronald Oussoren  added the comment:

 
claims fprintf should return a negative value when there is an output 
error (the same claims is in the manpage of fprintf on OSX 10.6).

Neither document refers to the error indicator. I'm afraid Martin is right 
that that the return value of all calls to fprintf (and fwrite) need to be  
explicitly checked, which is a very large patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue822005] Carbon.CarbonEvt.ReceiveNextEvent args wrong

[Ronald Oussoren]

Ronald Oussoren  added the comment:

According to 
 this issue is valid.

However, I won't work on fixing this because Carbon is deprecated, both 
the Python bindings and the framework itself.

Therefore lowering the priority.

--
nosy: +ronaldoussoren
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue822005] Carbon.CarbonEvt.ReceiveNextEvent args wrong

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
resolution:  -> wont fix
versions: +Python 2.6, Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1700507] Carbon.Scrap.PutScrapFlavor

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Lowering the priority to low because this is a bug in a deprecated binding 
for a deprecated Apple framework.  I won't work on a fix, although I am 
willing to review and apply a patch when someone provides one.

--
nosy: +ronaldoussoren
priority: normal -> low
resolution:  -> wont fix
versions: +Python 2.7 -Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

[Reid Kleckner]

Changes by Reid Kleckner :


--
nosy: +rnk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5166] ElementTree and minidom don't prevent creation of not well-formed XML

[Denis S. Otkidach]

Denis S. Otkidach  added the comment:

Here is a regexp I use to clean up text (note, that I don't touch 
"compatibility characters" that are also not recommended in XML; some 
other developers remove them too):

# http://www.w3.org/TR/REC-xml/#NT-Char
# Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | 
#  [#x1- #x10]
# (any Unicode character, excluding the surrogate blocks, FFFE, and 
)
_char_tail = ''
if sys.maxunicode > 0x1:
_char_tail = u'%s-%s' % (unichr(0x1),
 unichr(min(sys.maxunicode, 0x10)))
_nontext_sub = re.compile(
ur'[^\x09\x0A\x0D\x20-\uD7FF\uE000-\uFFFD%s]' % 
_char_tail,
re.U).sub
def replace_nontext(text, replacement=u'\uFFFD'):
return _nontext_sub(replacement, text)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

We just need make __getnewargs__ return bytes, instead of a unicode
string. So this is a single character fix.

I think we should reuse the ByteArraySubclass test case in test_bytes.py
to test for this bug. Incidentally, the reduce method of bytearray
should also be changed to emit bytes instead of a unicode string.

--
keywords: +patch
Added file: http://bugs.python.org/file15394/fix_bytes_reduce.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Vinay Sajip]

Vinay Sajip  added the comment:

> In general it would be nice if logging were more conservative (or

> cautious) when it comes to keeping objects persistent. It is too easy to
> fall into a trap and experience memory leaks.

I've checked in a change into trunk today which might improve matters. 
Handler.__init__ no longer adds the handler instance to the _handlers map 
unconditionally, but still adds it to the _handlerList array. The only place 
this array is actually used is in the shutdown() API, which is registered to be 
run via atexit. It flushes and closes  all the handlers in the list, so that 
any data in logging buffers gets flushed before the process exits.

The _handlers dict is now used to hold a mapping between handler names and 
handlers - the name property was added to Handler in the change I checked in 
today. This will be used by the dictConfig functionality which is proposed in 
PEP 391. If no name property is set on a Handler, then this will not add any 
additional references to handlers.

Python 2.7a0 (trunk:75403, Oct 14 2009, 20:14:09) [MSC v.1500 32 bit (Intel)] 
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
[49139 refs]
>>> logging._handlerList
[]
[49146 refs]
>>> logging.Handler()

[49179 refs]
>>> logging.Handler()

[49202 refs]
>>> logging.Handler()

[49225 refs]
>>> logging._handlerList
[, ,
 ]
[49225 refs]
>>> logging.shutdown()
[49156 refs]
>>> logging._handlerList
[]
[49156 refs]
>>>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7392] cPickle test failure on release26-maint branch

[Alexandre Vassalotti]

New submission from Alexandre Vassalotti :

I get the following test failure on the release26-maint branch:

./python Lib/test/test_cpickle.py
[...]
==
ERROR: test_issue2702 (__main__.cPickleDeepRecursive)
--
Traceback (most recent call last):
  File "Lib/test/test_cpickle.py", line 110, in test_issue2702
self.assertRaises(RuntimeError, cPickle.dumps, n)
  File "/home/alex/src/python.org/release26-maint/Lib/unittest.py", line
336, in failUnlessRaises
callableObj(*args, **kwargs)
  File "/home/alex/src/python.org/release26-maint/Lib/copy_reg.py", line
74, in _reduce_ex
getstate = self.__getstate__
AttributeError: 'Node' object has no attribute '__getstate__'

--
components: Library (Lib), Tests
messages: 95692
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: cPickle test failure on release26-maint branch
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3924] cookielib chokes on non-integer cookie version, should ignore it instead

[Andrew Shuiu]

Changes by Andrew Shuiu :


--
versions: +Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7128] cPickle looking for non-existent package copyreg

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

Thanks you!

Committed in r76499 and backported to 2.6 in r76500.

--
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Handler.__init__ no longer adds the handler instance to the _handlers
> map unconditionally, but still adds it to the _handlerList array. The
> only place this array is actually used is in the shutdown() API, which
> is registered to be run via atexit. It flushes and closes  all the
> handlers in the list, so that any data in logging buffers gets flushed
> before the process exits.

Why is this exactly? Why do you want to keep handlers until shutdown
rather than dispose of them when they aren't used anymore?

Moreover, closing in atexit is rather bad because the resources
necessary for proper closing (files, sockets...) may already have been
freed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Vinay Sajip]

Vinay Sajip  added the comment:

> Why is this exactly? Why do you want to keep handlers until shutdown

> rather than dispose of them when they aren't used anymore?

Typically handlers are only instantiated when being added to loggers, and 
loggers live for the lifetime of the process so those handler references will 
typically be persistent. However, if a handler is closed (typically after 
removing from a handler), it's removed from the list and would not cause a 
memory leak.

> Moreover, closing in atexit is rather bad because the resources
> necessary for proper closing (files, sockets...) may already have been
> freed.

That's potentially true, but it's behaviour which has been there from the 
beginning so ISTM it needs to be there for backward compatibility reasons :-( 
When logging.raiseExceptions is True (the default) any exceptions in shutdown() 
would be raised, but this doesn't appear to happen in practice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Vinay Sajip]

Vinay Sajip  added the comment:

> removing from a handler), it's removed from the list and would not cause a 

s/handler/logger/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[flox]

flox  added the comment:

I would think to use weak references in order to prevent such leaks.

With the patch attached, if the handler is not referenced anywhere, it
is closed.
However named handlers are not closed (because of hard reference in
_handlers dictionary).

--
nosy: +flox
Added file: http://bugs.python.org/file15395/issue6615_weakref.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Vinay Sajip]

Vinay Sajip  added the comment:

> With the patch attached, if the handler is not referenced anywhere, it

> is closed.
> However named handlers are not closed (because of hard reference in
> _handlers dictionary).

I haven't tried it yet, but does the patch actually work? You seem to have 
self_weakref in one place and self._weakref in another...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for testing!

Fixed (again) in r76502 (trunk), r76503 (py3k).  I don't think it's worth 
backporting the fix to the release branches, given that that would require 
also implementing %lld support in those branches.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7117] Backport py3k float repr to trunk

[Mark Dickinson]

Mark Dickinson  added the comment:

I think we're pretty much done here.

I'd still like to produce a more complete set of float formatting test 
cases at some point (for both trunk and py3k), but that's a separate 
activity.

Eric, Raymond:  can you spot anything we've missed?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file15395/issue6615_weakref.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[flox]

flox  added the comment:

yep... patch was not clean. Sorry :(

I changed it.
It passes the 21 tests of the test_logging suite.

And the count of references decreases with the test:

>>> import logging
>>> handler = logging.Handler()
>>> handler = logging.Handler()

--
Added file: http://bugs.python.org/file15396/issue6615_weakref.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5911] built-in compile() should take encoding option.

[Trundle]

Changes by Trundle :


--
nosy: +Trundle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7391] Re-title the "Using Backslash to Continue Statements" anti-idiom

[Georg Brandl]

Georg Brandl  added the comment:

As you write, the parentheses "trick" only works in expressions (what
you tried to wrap in your with statement is not an expression).

The backslash works for all kinds of statements however, so the
suggested change is wrong.

--
resolution:  -> wont fix
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7117] Backport py3k float repr to trunk

[Eric Smith]

Eric Smith  added the comment:

Thanks for tackling the last few bits, Mark. I think we're done,
although I admit I haven't verified what state the documentation is in.

I suggest we close this issue and if any problems occur open them as new
issues.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Some quick comments on your patch (not an in-depth review):
- you should add some tests for the problem you're trying to solve
- using __del__ when you have a weakref is counter-productive; use the
weakref's optional callback instead
- if you remove arbitrary elements from it, _handlerList should probably
be a set rather a list (but it's more of an optimization concern)
- `for h in [wr() for wr in handlerList if wr() is not None]` isn't a
pretty notation; just put the `if` inside the `for` instead

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[flox]

flox  added the comment:

Updated the patch with technical recommendations from Antoine.

I kept the _handlerList as a list because "It allows handlers to be
removed in reverse of order initialized."

And some tests are needed to outline the change.

--
Added file: http://bugs.python.org/file15397/issue6615_weakref.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file15396/issue6615_weakref.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[flox]

flox  added the comment:

Small change to acquire the module lock before working on _handlerList.

--
Added file: http://bugs.python.org/file15398/issue6615_weakref.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6615] multiprocessing logging support test

[flox]

Changes by flox :


Removed file: http://bugs.python.org/file15397/issue6615_weakref.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

[Reid Kleckner]

Reid Kleckner  added the comment:

One thing I was wondering about the current patch is what about objects
that have attributes that shadow methods?  For example:

class C(object):
def foo(self):
return 1
c = c()
print c.foo()
c.foo = lambda: 2
print c.foo()

Shouldn't the above print 1 and 2?  With the current patch, it seems
that you might still print 1.

There's also the possible performance drawback where you're loading
builtin C methods, so the optimization fails, but you end up calling
_PyType_Lookup twice.  :(

I'm doing the same optimization for unladen swallow, and these were some
of the things I ran into.  I think I'm going to write a
PyObject_GetMethod that tries to get a method without binding it, but if
it can't for any reason, it behaves just like PyObject_GetAttr and sets
a status code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1606092] csv module broken for unicode

[Craig McQueen]

Changes by Craig McQueen :


--
nosy: +cmcqueen1975

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1606092] csv module broken for unicode

[Craig McQueen]

Craig McQueen  added the comment:

Is this still an open bug? I have the following code:

lookup = {}
csv_reader = csv.reader(codecs.open(lookup_file_name, 'r', 'utf-8'))
for row in csv_reader:
lookup[row[1]] = row[0]

And it "appears to work" (it runs) using Python 2.6.2. So has this bug
been fixed?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1606092] csv module broken for unicode

[Craig McQueen]

Craig McQueen  added the comment:

I think I see now--it accepts Unicode input, but converts it back to
bytes internally using the ASCII codec. So it works as long as the
Unicode input contains on ASCII characters. That's a gotcha.

It appears that it's been fixed in Python 3.x, judging by the documentation.

--
versions: +Python 2.4, Python 2.5, Python 2.6, Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Yes, my patch introduces that regression you mention. PyPy solves this
by having the instances dictionary keep track of shadowing of the type
dictionary. Not easy for CPython... I wish you luck on your patch!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7393] Executing Python program of sum of 2 nos.

[Mayuresh]

New submission from Mayuresh :

I am getting error of sum of two nos. the output should give addition 
of two numbers,but instead it is displaying 2 nos. side-by-side.I have 
pasted the program and output for the same.

print "Please give a number: "
a = input()
print "And another: "
b = input()
print "The sum of these numbers is: "
print a + b

output should be a=21,b=21, a+b=42
whereas it is showing 2121.

--
components: IDLE
messages: 95711
nosy: mayur78
severity: normal
status: open
title: Executing Python program of sum of 2 nos.
type: behavior
versions: Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7393] Executing Python program of sum of 2 nos.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

In Python 3.1, the input() function always returns a string.  In your
case, the string is "21".  Adding two strings together gives you a
longer string:  "12" + "34" --> "1234".

To get your program to do what you want, convert the string to a number
using int():

a = int(input('give a number: '))
b = int(input('and another: '))
print('the sum is', a + b)

--
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com