[Python-Dev] Possible bug in class-init, lookin for mentors

2017-04-21 Thread Justus Schwabedal 
Hi everyone,

I possibly found a bug in class __init__ and would like to fix it.  So I'm
looking for a mentor to help me.

`class Foo:
def __init__(self, bar=[]):
self.list = bar

spam_1 = Foo()
spam_2 = Foo()

spam_1.list.append(42)
print(spam_2.list)`

At least I think it's a bug.  Maybe it's a feature..

Best Regards, Jus





-- 
Justus Schwabedal

Handy (D): +49 177 939 5281
email: [email protected]
skype: justus1802

Görlitzer Str. 22
01099 Dresden, Sachsen
Germany

Steinkreuzstr. 23
53757 Sankt Augustin, NRW
Germany
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Possible bug in class-init, lookin for mentors

2017-04-21 Thread Justus Schwabedal 
Hi everyone,

I possibly found a bug in class initialization and would like to fix it.
Because it's my first journey to core-dev, I would really appreciate the
help of a mentor that I may ask a few questions to get me up to speed.

To my person, I have previously worked on larger projects in python, c, and
c++ if that information helps, and I'm really curious to learn more about
the interiors of the greatest interpreter known to wo-/men.

Here comes the bug-producing example:

`class Foo:
def __init__(self, bar=[]):
self.list = bar

spam_1 = Foo()
spam_2 = Foo()

spam_1.list.append(42)
print(spam_2.list)`

At least I think it's a bug.  Maybe it's a feature..

Best Regards, Jus

---

f*** me  on github :)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible bug in class-init, lookin for mentors

2017-04-21 Thread Paul Moore 
This is correct behaviour. I would suggest that you post this to
python-list for a full discussion of what's going on here, but
basically the default value for argument bar of __init__ is created at
class creation time, and then reused for every instance. This is a
common mistake made by newcomers, using mutable default arguments for
functions (or methods).

A google search for "python mutable default argument" should find you
some useful explanations of what's going on.

Cheers,
Paul

On 21 April 2017 at 10:47, Justus Schwabedal  wrote:
> Hi everyone,
>
> I possibly found a bug in class __init__ and would like to fix it.  So I'm
> looking for a mentor to help me.
>
> `class Foo:
> def __init__(self, bar=[]):
> self.list = bar
>
> spam_1 = Foo()
> spam_2 = Foo()
>
> spam_1.list.append(42)
> print(spam_2.list)`
>
> At least I think it's a bug.  Maybe it's a feature..
>
> Best Regards, Jus
>
>
>
>
>
> --
> Justus Schwabedal
>
> Handy (D): +49 177 939 5281
> email: [email protected]
> skype: justus1802
>
> Görlitzer Str. 22
> 01099 Dresden, Sachsen
> Germany
>
> Steinkreuzstr. 23
> 53757 Sankt Augustin, NRW
> Germany
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/p.f.moore%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible bug in class-init, lookin for mentors

2017-04-21 Thread Guyzmo via Python-Dev 
On Fri, Apr 21, 2017 at 11:47:24AM +0200, Justus Schwabedal wrote:
> At least I think it's a bug.  Maybe it's a feature..

it's indeed a feature.

> I possibly found a bug in class __init__ and would like to fix it

technically, it's a method. More precisely, it's the constructor method.

> So I'm looking for a mentor to help me.
> 
> class Foo:
> def __init__(self, bar=[]):
> self.list = bar
> 
> spam_1 = Foo()
> spam_2 = Foo()
> 
> spam_1.list.append(42)
> print(spam_2.list)`

the argument `bar` of your method is instanciated at the time you're
declaring the method. It's happening once for the the lifetime of the
execution of your code.

By allocating the `bar` reference into the `self.list` member, you're
assigning the same *instance* of that list into the `self.list` member.

So everytime you create a new Foo instance, you're actually assigning
the same `[]` instance into `self.list` which is why, when you mutate
the list, it's happening in all the instances of Foo as well.

I hope it makes sense to you !

-- 
Guyzmo
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible bug in class-init, lookin for mentors

2017-04-21 Thread Max Zettlmeißl 
On 21 April 2017 at 12:09, Justus Schwabedal  wrote:
> I possibly found a bug in class initialization and would like to fix it.
>
> Here comes the bug-producing example:
>
> `class Foo:
> def __init__(self, bar=[]):
> self.list = bar
>
> spam_1 = Foo()
> spam_2 = Foo()
>
> spam_1.list.append(42)
> print(spam_2.list)`
>
> At least I think it's a bug.  Maybe it's a feature..
>

It is not a bug.

It is the way in which Python handles mutable keyword arguments.
If you want to use something in this way you should go with

def __init__(self, bar=None):
if bar is None:
bar = []
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible bug in class-init, lookin for mentors

2017-04-21 Thread Manolis Mavrofidis 
In a nutshell.
You create two instances and you assign the same list to both of them
which you instantiate when you run your code.
>>> id(spam_1.list)
4530230984 # <- Here
>>> id(spam_2.list)
4530230984 # <- Here
>>> id(spam_1)
4530231632 # Nice unique instance
>>> id(spam_2)
4530231200 # Nice unique instance as well

Try
>>> class Foo:
... def __init__(self, list=None):
... self.list = list
...
>>> spam_1 = Foo()
>>> spam_2 = Foo([]) <- Cheating.
>>> spam_1
<__main__.Foo instance at 0x10e05d9e0>
>>> spam_2
<__main__.Foo instance at 0x10e05d950>
>>> spam_2.list.append(42)
>>> print(spam_1.list)
None
>>> print(spam_2.list)
[42]
>>> id(spam_1.list)
4527705752
>>> id(spam_2.list)
4530231488

Or something along those lines :)

On 21 April 2017 at 16:03, Guyzmo via Python-Dev  wrote:
> On Fri, Apr 21, 2017 at 11:47:24AM +0200, Justus Schwabedal wrote:
>> At least I think it's a bug.  Maybe it's a feature..
>
> it's indeed a feature.
>
>> I possibly found a bug in class __init__ and would like to fix it
>
> technically, it's a method. More precisely, it's the constructor method.
>
>> So I'm looking for a mentor to help me.
>>
>> class Foo:
>> def __init__(self, bar=[]):
>> self.list = bar
>>
>> spam_1 = Foo()
>> spam_2 = Foo()
>>
>> spam_1.list.append(42)
>> print(spam_2.list)`
>
> the argument `bar` of your method is instanciated at the time you're
> declaring the method. It's happening once for the the lifetime of the
> execution of your code.
>
> By allocating the `bar` reference into the `self.list` member, you're
> assigning the same *instance* of that list into the `self.list` member.
>
> So everytime you create a new Foo instance, you're actually assigning
> the same `[]` instance into `self.list` which is why, when you mutate
> the list, it's happening in all the instances of Foo as well.
>
> I hope it makes sense to you !
>
> --
> Guyzmo
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/mmavrofides%40gmail.com



-- 
"Only those who will risk going too far
can possibly find out how far one can go.
 "T.S. Eliot
http://0x109.tuxfamily.org
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2017-04-21 Thread Python tracker 

ACTIVITY SUMMARY (2017-04-14 - 2017-04-21)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open5882 ( -7)
  closed 36004 (+64)
  total  41886 (+57)

Open issues with patches: 2389 


Issues opened (39)
==

#30075: Printing ANSI Escape Sequences on Windows 10
http://bugs.python.org/issue30075  opened by Tithen Firion

#30076: Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK
http://bugs.python.org/issue30076  opened by serhiy.storchaka

#30077: Support Apple AIFF-C pseudo compression in aifc.py
http://bugs.python.org/issue30077  opened by thruston

#30079: Explain why it is recommended to pass args as a string rather 
http://bugs.python.org/issue30079  opened by iMath

#30080: Add the --duplicate option for timeit
http://bugs.python.org/issue30080  opened by serhiy.storchaka

#30082: hide command prompt when using subprocess.Popen with shell=Fal
http://bugs.python.org/issue30082  opened by iMath

#30083: Asyncio: GeneratorExit + strange exception
http://bugs.python.org/issue30083  opened by socketpair

#30085: Discourage operator.__dunder__ functions
http://bugs.python.org/issue30085  opened by steven.daprano

#30088: mailbox.Maildir doesn't create subdir structure when create=Tr
http://bugs.python.org/issue30088  opened by webknjaz

#30089: Automatic Unload of Dynamic Library Cause Segfault
http://bugs.python.org/issue30089  opened by Chinh Nguyen

#30094: PDB enhancement
http://bugs.python.org/issue30094  opened by erixoltan

#30095: HTMLCalendar allow custom classes
http://bugs.python.org/issue30095  opened by Oz.Tiram

#30096: Update examples in abc documentation to use abc.ABC
http://bugs.python.org/issue30096  opened by brett.cannon

#30097: Command-line option to suppress "from None" for debugging
http://bugs.python.org/issue30097  opened by rhettinger

#30098: Verbose TypeError for asyncio.ensure_future
http://bugs.python.org/issue30098  opened by crenwick

#30099: Lib2to3 fails with unreadable pickle file
http://bugs.python.org/issue30099  opened by Jake Merdich

#30100: WeakSet should all discard and remove on items that can have w
http://bugs.python.org/issue30100  opened by donkopotamus

#30101: Add support for ncurses A_ITALIC
http://bugs.python.org/issue30101  opened by Eijebong

#30102: improve performance of libSSL usage on hashing
http://bugs.python.org/issue30102  opened by gut

#30103: uu package uses old encoding
http://bugs.python.org/issue30103  opened by LawfulEvil

#30104: clang 4.0 miscompiles dtoa.c, giving broken float parsing and 
http://bugs.python.org/issue30104  opened by haypo

#30105: Duplicated connection_made() call for some SSL connections
http://bugs.python.org/issue30105  opened by kyuupichan

#30106: test_asyncore: test_handle_write() fails in tearDown()
http://bugs.python.org/issue30106  opened by haypo

#30107: python.core file created when running tests on AMD64 FreeBSD C
http://bugs.python.org/issue30107  opened by haypo

#30109: make reindent failed.
http://bugs.python.org/issue30109  opened by corona10

#30110: test_asyncio reports reference leak
http://bugs.python.org/issue30110  opened by xiang.zhang

#30113: Add profile test case for trace_dispatch_return assertion
http://bugs.python.org/issue30113  opened by louielu

#30115: test_logging report reference leak
http://bugs.python.org/issue30115  opened by xiang.zhang

#30117: test_lib2to3.test_parser.test_all_project_files() fails
http://bugs.python.org/issue30117  opened by haypo

#30118: Adding unittest for cProfile / profile command line interface
http://bugs.python.org/issue30118  opened by louielu

#30119: (ftplib) A remote attacker could possibly attack by containing
http://bugs.python.org/issue30119  opened by corona10

#30121: Windows: subprocess debug assertion on failure to execute the 
http://bugs.python.org/issue30121  opened by Segev Finer

#30122: Added missing archive programs and close option to Windows doc
http://bugs.python.org/issue30122  opened by Decorater

#30124: Fix C aliasing issue in Python/dtoa.c to use strict aliasing o
http://bugs.python.org/issue30124  opened by haypo

#30125: test_SEH() of test_ctypes logs "Windows fatal exception: acces
http://bugs.python.org/issue30125  opened by haypo

#30126: CheckTraceCallbackContent of test_sqlite3 fails on OS X Tiger
http://bugs.python.org/issue30126  opened by haypo

#30128: xid_start definition for Unicode identifiers refers to xid_con
http://bugs.python.org/issue30128  opened by ralph.corderoy

#30129: functools.partialmethod should look more like what it's impers
http://bugs.python.org/issue30129  opened by skip.montanaro

#30130: array.array is not an instance of collections.MutableSequence
http://bugs.python.org/issue30130  opened by Alexander Gosselin



Most recent 15 issues with no replies (15)
==

#30130: array.array is not an ins

Re: [Python-Dev] Possible bug in class-init, lookin for mentors

2017-04-21 Thread Antoine Rozo 
And it is not related to __init__ method.
You have the same behaviour with any other function or method.

>>> def append_to_list(item, l=[]):
... l.append(item)
... return l
...
>>> append_to_list(1)
[1]
>>> append_to_list(2)
[1, 2]

2017-04-21 17:18 GMT+02:00 Manolis Mavrofidis :

> In a nutshell.
> You create two instances and you assign the same list to both of them
> which you instantiate when you run your code.
> >>> id(spam_1.list)
> 4530230984 # <- Here
> >>> id(spam_2.list)
> 4530230984 # <- Here
> >>> id(spam_1)
> 4530231632 # Nice unique instance
> >>> id(spam_2)
> 4530231200 # Nice unique instance as well
>
> Try
> >>> class Foo:
> ... def __init__(self, list=None):
> ... self.list = list
> ...
> >>> spam_1 = Foo()
> >>> spam_2 = Foo([]) <- Cheating.
> >>> spam_1
> <__main__.Foo instance at 0x10e05d9e0>
> >>> spam_2
> <__main__.Foo instance at 0x10e05d950>
> >>> spam_2.list.append(42)
> >>> print(spam_1.list)
> None
> >>> print(spam_2.list)
> [42]
> >>> id(spam_1.list)
> 4527705752
> >>> id(spam_2.list)
> 4530231488
>
> Or something along those lines :)
>
> On 21 April 2017 at 16:03, Guyzmo via Python-Dev 
> wrote:
> > On Fri, Apr 21, 2017 at 11:47:24AM +0200, Justus Schwabedal wrote:
> >> At least I think it's a bug.  Maybe it's a feature..
> >
> > it's indeed a feature.
> >
> >> I possibly found a bug in class __init__ and would like to fix it
> >
> > technically, it's a method. More precisely, it's the constructor method.
> >
> >> So I'm looking for a mentor to help me.
> >>
> >> class Foo:
> >> def __init__(self, bar=[]):
> >> self.list = bar
> >>
> >> spam_1 = Foo()
> >> spam_2 = Foo()
> >>
> >> spam_1.list.append(42)
> >> print(spam_2.list)`
> >
> > the argument `bar` of your method is instanciated at the time you're
> > declaring the method. It's happening once for the the lifetime of the
> > execution of your code.
> >
> > By allocating the `bar` reference into the `self.list` member, you're
> > assigning the same *instance* of that list into the `self.list` member.
> >
> > So everytime you create a new Foo instance, you're actually assigning
> > the same `[]` instance into `self.list` which is why, when you mutate
> > the list, it's happening in all the instances of Foo as well.
> >
> > I hope it makes sense to you !
> >
> > --
> > Guyzmo
> > ___
> > Python-Dev mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mmavrofides%40gmail.com
>
>
>
> --
> "Only those who will risk going too far
> can possibly find out how far one can go.
>  "T.S. Eliot
> http://0x109.tuxfamily.org
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> antoine.rozo%40gmail.com
>



-- 
Antoine Rozo
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Possible bug in class-init, lookin for mentors

2017-04-21 Thread Mark Lawrence via Python-Dev 

On 21/04/2017 16:03, Guyzmo via Python-Dev wrote:

On Fri, Apr 21, 2017 at 11:47:24AM +0200, Justus Schwabedal wrote:

At least I think it's a bug.  Maybe it's a feature..


it's indeed a feature.


I possibly found a bug in class __init__ and would like to fix it


technically, it's a method. More precisely, it's the constructor method.



No, __new__ is the constructor, __init__ is the initializer. It is 
completely impossible to state when a Python object has been initialised 
as you can throw in attributes any time you like.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com