[issue14671] isinstance(obj, object) returns True for _old style_ classes

[Q]

New submission from Q :

$python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
>>> class Old: pass
>>> class New(object): pass
>>> o = Old()
>>> n = New()
>>> isinstance(o, object)
True

This is it, basically. Is it a bug or a feature?

More tests :

>>> isinstance(o, Old)
True
>>> isinstance(o, New)
False
>>> isinstance(n, Old)
False
>>> isinstance(o, int)
False

Please note that some unimportant output was deleted from above.

PS. If this is a feature, how do I detect an old-style class then ?

--
components: Interpreter Core
messages: 159351
nosy: thread13
priority: normal
severity: normal
status: open
title: isinstance(obj, object) returns True for _old style_ classes
type: behavior
versions: Python 2.6

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

[issue14671] isinstance(obj, object) returns True for _old style_ class instances

[Q]

Changes by Q :


--
title: isinstance(obj, object) returns True for _old style_ classes -> 
isinstance(obj, object) returns True for _old style_ class instances

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

[issue14671] isinstance(obj, object) returns True for _old style_ class instances

[Q]

Q  added the comment:

In addition:

>>> issubclass(Old, object)
False

--

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

[issue14671] isinstance(obj, object) returns True for _old style_ class instances

[Q]

Q  added the comment:

>>> help(isinstance)

isinstance(...)
isinstance(object, class-or-type-or-tuple) -> bool

Return whether an object is an instance of a class or of a subclass thereof.
(...)

So are the old-style class instances descendants of the object?

I feel like I am missing something (except for the fact that you have closed 
the bug).

--
resolution: invalid -> 
status: closed -> open

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

[issue14671] isinstance(obj, object) returns True for _old style_ class instances

[Q]

Q  added the comment:

I do not mean to reopen the bug (there are supposedly much more important 
things to work on in Python). 

But just for the record, let me state that I feel like there is some misleading 
inconsistency here:

- by definition, a new style class is "Any class which inherits from object" ( 
see http://docs.python.org/glossary.html#term-new-style-class ) ;

- to support this statement, new classes are indeed explicitly defined in the 
form "NewClass(object)" ;

- now isinstance(), that is supposed to "return whether an object is an 
instance of a class or of a subclass thereof" (see help(isinstance)), returns 
True for old-style objects.

It also seems reasonable if the descendants of a class will inherit its powers, 
which -- in the case of the old-style classes -- they obviously don't.

Furthermore, I personally see no /point/ in returning True for 
isinstance(Old(), object): as it is quite misleading, one could easily have 
made it returning e.g. None as well.

As I completely accept the fact it's a feature -- ( may be slightly confusing, 
and probably also useless -- but ... hey, nobody's perfect ) -- should I take 
then calling

issubclass(obj.__class__, object) 

to be the official way to distinguish between the new-style and the old-style 
classes?

--

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

[issue14671] isinstance(obj, object) returns True for _old style_ class instances

[Q]

Q  added the comment:

thanks, that's rather convenient

--

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

[issue14823] Simplify threading.Lock.acquire() description

[Q]

New submission from Q :

Hi there,

I suggest to improve the description of Lock.acquire()
[ http://docs.python.org/library/threading.html#threading.Lock.acquire ]
in the following way:

>>>>> current version >>>>>
Lock.acquire([blocking])

   Acquire a lock, blocking or non-blocking.

   When invoked without arguments, block until the lock is unlocked,
   then set it to locked, and return true.

   When invoked with the *blocking* argument set to true, do the same
   thing as when called without arguments, and return true.

   When invoked with the *blocking* argument set to false, do not
   block.  If a call without an argument would block, return false
   immediately; otherwise, do the same thing as when called without
   arguments, and return true.

<<<<< current version <<<<<


>>>>> suggested version >>>>>
Lock.acquire([blocking])

   Acquire a lock, blocking or non-blocking.

   When invoked with the *blocking* argument set to true 
   (the default), block until the lock is unlocked, 
   then set it to locked, and return true.

   When invoked with the *blocking* argument set to false, do not
   block.  If a call without an argument would block, return false
   immediately; otherwise, set the lock to locked, and return true.

<<<<< suggested version <<<<<

The idea is to simplify the structure of the explanation: get rid of an 
unnecessary "goto" -- "do the same thing as" as well as the extra branching 
("when invoked without arguments" ... "when invoked with *blocking* argument 
set to true") .

The suggested patch for the text version of the documentation ( 
http://docs.python.org/download.html -> 
http://docs.python.org/archives/python-2.7.3-docs-text.tar.bz2 ) is attached. 

PS. I did not dare to capitalize the boolean variables ("true" -> "True") to 
adhere to the general style of the document (obviously inherited from Java). 
For the same reason I didn't either change the argument signature from 
"[blocking]" to "[blocking=True]".

--
assignee: docs@python
components: Documentation
files: threading.txt.patch
keywords: patch
messages: 160786
nosy: docs@python, thread13
priority: normal
severity: normal
status: open
title: Simplify threading.Lock.acquire() description
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file25604/threading.txt.patch

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

[issue14823] Simplify threading.Lock.acquire() description

[Q]

Q  added the comment:

Well, as threading is a Python wrapper, this could easily be fixed. (I am not 
certain whether it *should* be fixed or not -- perhaps things are fine just as 
they are, at least with that particular detail. ) 

But this is good to know, thank you.

--

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

[issue14823] Simplify threading.Lock.acquire() description

[Q]

Q  added the comment:

My bad. That's indeed what I did. Won't repeat the mistake, sorry.

--

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

[issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly

[Q]

New submission from Q:

On Ubuntu LTS 16.04, SysLogHandler with a custom formatter does not seem to 
expand loglevel/levelno fields properly, when there are square brackets ( see 
the attached examples ). Instead, it seems to replace '[%(loglevel)s]' with a 
'[pid]', and '%(loglevel)s' with 'LOGLEVEL[pid]' .

To test, run 'journalctl -f | grep test_test_test' on one console, and the 
attached files on another. The output for 'bad.py' looks as follows:
===
Feb 28 21:30:05 hostname [7117]: logging was configured for 
process <7117>
===

And should have looked like:
===
Feb 28 21:30:05 hostname [INFO]: logging was configured for 
process <7117>
===

For 'good.py', the output is as follows:
===
Feb 28 21:30:04 hostname INFO[7114]: logging was configured for 
process <7114>
===

and should have probably been: 
===
Feb 28 21:30:04 hostname INFO: logging was configured for 
process <7114>
===

Kind regards, /t13

--
files: bad.py
messages: 288702
nosy: thread13
priority: normal
severity: normal
status: open
title: SysLogHandler does not seem to always expand %(loglevel)s properly
versions: Python 2.7
Added file: http://bugs.python.org/file46679/bad.py

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

[issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly

[Q]

Q added the comment:

Attaching the other file mentioned.

--
Added file: http://bugs.python.org/file46680/good.py

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

[issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly

[Q]

Q added the comment:

PS. I'm not sure if that is a systemd/journald issue, or indeed a Python bug.

However, it would be nice to clear one possibility. 

For a StreamHandler, it all works as it should.

--

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