Re: Who are the "spacists"?
> On Mar 17, 2017, at 8:52 PM, Mikhail V wrote: > > So Python supports both spaces and tabs for indentation. > > I just wonder, why not forbid spaces in the beginning of lines? > How would one come to the idea to use spaces for indentation at all? > That convention dates all the way back to the IBM 026 and 029 card punches and FORTRAN. > Space is not even a control/format character, but a word separator. > And when editors will be proportional font based, indenting with > spaces will not make *any* sense so they are just annoyance. > Neither makes it sense in general case of text editing. > I think it would be a salvation to forbid spaces for indentation, > did such attemps take place? > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
Mikhail V writes: > I just wonder, why not forbid spaces in the beginning of lines? > How would one come to the idea to use spaces for indentation at all? Those are two very different questions. I think you may be under the false impression that the decision you refer to was made in a vacuum. The truth is that there was an impressive culture of programming convention before Python ever existed; and, now that Python does exist, there is an enormous amount of Python code to continue supporting. For the first: > I just wonder, why not forbid spaces in the beginning of lines? Because that would make countless lines of existing Python code illegal. For the second: > How would one come to the idea to use spaces for indentation at all? Because, whether in the context of programming or not, the space character is the most obvious way to make invisible horizontal separation when typing at a keyboard. Therefore, it's the most obvious way for people to type what they see in programming examples. Therefore, it would be astonishing to reject it for indentation. Astonishment is a property to be minimised in a programming language. > I think it would be a salvation to forbid spaces for indentation, did > such attemps take place? Feel free to start your own discussion forum for your new programming language that forbids spaces for indentation. That language will never be Python, so please don't ask us to discuss it here. -- \ “We are stuck with technology when what we really want is just | `\ stuff that works.” —Douglas Adams | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On Fri, Mar 17, 2017 at 8:52 PM, Mikhail V wrote: > So Python supports both spaces and tabs for indentation. > > I just wonder, why not forbid spaces in the beginning of lines? > How would one come to the idea to use spaces for indentation at all? > > Space is not even a control/format character, but a word separator. > And when editors will be proportional font based, indenting with > spaces will not make *any* sense so they are just annoyance. > Neither makes it sense in general case of text editing. > I think it would be a salvation to forbid spaces for indentation, > did such attemps take place? > -- > https://mail.python.org/mailman/listinfo/python-list This is not a useful conversation. It has been had over and over in the past. Some people like tabs, some like spaces. In python you can use either, but you must stick to one or the other -- Joel Goldstick http://joelgoldstick.com/blog http://cc-baseballstats.info/stats/birthdays -- https://mail.python.org/mailman/listinfo/python-list
Who are the "spacists"?
So Python supports both spaces and tabs for indentation. I just wonder, why not forbid spaces in the beginning of lines? How would one come to the idea to use spaces for indentation at all? Space is not even a control/format character, but a word separator. And when editors will be proportional font based, indenting with spaces will not make *any* sense so they are just annoyance. Neither makes it sense in general case of text editing. I think it would be a salvation to forbid spaces for indentation, did such attemps take place? -- https://mail.python.org/mailman/listinfo/python-list
Re: Dynamically replacing an objects __class__; is it safe?
On Thursday, March 16, 2017 at 7:07:17 PM UTC-7, Deborah Swanson wrote:
> Steve D'Aprano wrote,on March 16, 2017 5:07 AM
> >
> > On Thu, 16 Mar 2017 09:03 am, Gregory Ewing wrote:
> >
> > > Steve D'Aprano wrote:
> > >> You probably can't make a whale fly just by changing the class to
> > >> bird. It will need wings, and feathers, at the very least.
> > >
> > > Some things succeed in flying with neither wings nor feathers.
> > > Helicopters, for example.
> >
> > For some definition of "no wings".
> >
> > But regardless of rockets, balloons, helicopters, Boeing 747s
> > and Dr Strange's mystical Cloak Of Levitation, *birds*
> > require wings and feathers to fly. If you just paint "BIRD"
> > on the side of a whale, it won't get off the ground, and if
> > you do manage to get it airborne (via a catapult,
> > perhaps) it will just come down with a rather large splat.
> >
> > The point is that dynamically swapping the class of an
> > existing instance at runtime is *not* just a way of doing
> > duck-typing. It really does matter if your duck flies by
> > flapping feathered wings or by blasting an exhaust of hot
> > gasses out of its rear end at high speed.
> >
> > With duck-typing, you don't care whether you have a duck or a
> > goose, so long as they both can fly: you don't care *how* it
> > flies, so long as it does, and even a rocket-propelled
> > balloon will be fine.
> >
> > But when you dynamically swap out __class__ (I think
> > Objective-C "swizzling" is conceptually equivalent, so I'll
> > call it by that word) you have to care about the
> > implementation. The whole point of swizzling is that it
> > allows you to swap out one implementation ("run forward and
> > flap your wings") with another implementation ("light the
> > blue touch paper"). But if you do that, you have to care
> > about implementation details. There's no point in setting
> > your swizzled fly() method to that of Rocket if your instance
> > doesn't have blue touch paper to light.
> >
> > With duck-typing, making the methods work isn't your
> > responsibility. But when you swizzle, you are responsible for
> > making sure that the instance provides whatever the methods
> > need to work.
> >
> > A very old but good example of Python swizzling is here:
> > http://code.activestate.com/recipes/68429-ring-buffer/
>
> --
> Steve
> "Cheer up," they said, "things could be worse." So I cheered up, and
> sure enough, things got worse.
>
> Condolences, Steve. Nobody on this thread wants to plumb the depths of
> Python swizzling. Or anything else Python, so it appears.
Hey Deborah,
If you're getting discouraged by a certain spammer who posts to this newsgroup
in ALL CAPS and ITALIAN, don't let him beat you. Go find newsreader software
that allows you to define filters and killfiles. It will help.
If you read further into that article about the RingBuffer class and
"swizzling", Steve Alexander suggests a method that I have used myself, and
which I consider to be generally superior: conditionally rebinding the names of
methods you want to change within a class, rather than overriding __class__
itself.
I suppose that each approach has its merits. If you want the object's type to
advertise that a condition has changed, rebinding __class__ is good. If you
have many methods to change, and you don't like long lists of similarly-named
functions in one class, rebinding __class__ could also be good.
I don't encounter those conditions much myself. In the RingBufferFull case,
only two methods need to change, .append() and .get(). Both methods are short.
Both methods' eventual replacements, which we might name ._full_append() and
._get(), are also short. I would do it Steve Alexander's way.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dynamically replacing an objects __class__; is it safe?
On Sat, Mar 18, 2017 at 8:24 AM, wrote: > On Thursday, March 16, 2017 at 9:27:56 PM UTC-7, Gregory Ewing wrote: >> Chris Angelico wrote: >> > Maybe what the ISS does isn't flying - it's falling with style? >> >> Yep. They didn't really launch it into orbit with rockets, >> that was all faked. They actually hauled it up there with >> a crane, let it go and pulled the earth away at the last >> moment. >> >> -- >> Greg > > Chris, this is evidence you need to stick to Flying Circus references when > attempting to construct a joke in this newsgroup. Buzz Lightyear won't cut > it. And cue the discussion of whether Joke.__init__() is the constructor or not. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Dynamically replacing an objects __class__; is it safe?
On Thursday, March 16, 2017 at 9:27:56 PM UTC-7, Gregory Ewing wrote: > Chris Angelico wrote: > > Maybe what the ISS does isn't flying - it's falling with style? > > Yep. They didn't really launch it into orbit with rockets, > that was all faked. They actually hauled it up there with > a crane, let it go and pulled the earth away at the last > moment. > > -- > Greg Chris, this is evidence you need to stick to Flying Circus references when attempting to construct a joke in this newsgroup. Buzz Lightyear won't cut it. -- https://mail.python.org/mailman/listinfo/python-list
Re: __del__ is not called after creating a new reference
On 03/17, Terry Reedy wrote: > > On 3/17/2017 10:54 AM, Oleg Nesterov wrote: >> I started to learn python a few days ago and I am trying to understand what >> __del__() actually does. https://docs.python.org/3/reference/datamodel.html >> says: >> >> object.__del__(self) >> ... >> Note that it is possible (though not recommended!) for the __del__() >> method to postpone destruction of the instance by creating a new >> reference to it. > > If I understand the below, 'that persists after the function call' > should be added. Yes, > Note that the function call itself 'creates a new > reference' by binding 'self' to the obj. Well, not really if I have read this code correctly (quite possibly not), PyObject_CallFinalizer() is called with the "artificial" ob_refcnt == 1 after it was already zero, and I am not sure call_unbound_noarg() binds "self", but this doesn't mattter at all afaics. > I suspect that this was added after the doc. If git has an annotate > function, you could check. I did. And it is not clear to me if this behavioural change was intentional or not. I don't have the sources right now so I can't tell you the commit id, I can do this later when I return home. I have python2.5 on my working laptop, the test-case works as documented. Oleg. -- https://mail.python.org/mailman/listinfo/python-list
Re: __del__ is not called after creating a new reference
On 3/17/2017 10:54 AM, Oleg Nesterov wrote:
I started to learn python a few days ago and I am trying to understand what
__del__() actually does. https://docs.python.org/3/reference/datamodel.html
says:
object.__del__(self)
...
Note that it is possible (though not recommended!) for the __del__()
method to postpone destruction of the instance by creating a new
reference to it.
If I understand the below, 'that persists after the function call'
should be added. Note that the function call itself 'creates a new
reference' by binding 'self' to the obj.
It may then be called at a later time when this new
reference is deleted.
However, this trivial test-case
class C:
def __del__(self):
print("DEL")
global X
X = self
C()
print(X)
X = 0
print(X)
shows that __del__ is called only once, it is not called again after "X = 0":
DEL
<__main__.C object at 0x7f067695f4a8>
0
(Just in case, I verified later that this object actually goes away and its
memory is freed, so the problem is not that it still has a reference).
I've cloned https://github.com/python/cpython.git and everything looks clear
at first glance (but let me repeat that I am very new to python):
PyObject_CallFinalizerFromDealloc() calls PyObject_CallFinalizer()
which finally calls "__del__" method in slot_tp_finalize(), then it
notices that "X = self" creates the new reference and does:
/* tp_finalize resurrected it! Make it look like the original Py_DECREF
* never happened.
*/
refcnt = self->ob_refcnt;
_Py_NewReference(self);
self->ob_refcnt = refcnt;
However, PyObject_CallFinalizer() also does _PyGC_SET_FINALIZED(self, 1)
and that is why __del__ is not called again after "X = 0":
/* tp_finalize should only be called once. */
if (PyType_IS_GC(tp) && _PyGC_FINALIZED(self))
return;
I suspect that this was added after the doc. If git has an annotate
function, you could check.
The comment and the code are very explicit, so this does nt look like a
bug in cpython.
Probably the docs should be fixed?
Or this code is actually wrong? The test-case works as documented if I
remove _PyGC_SET_FINALIZED() in PyObject_CallFinalizer() or add another
_PyGC_SET_FINALIZED(self, 0) into PyObject_CallFinalizerFromDealloc()
after _Py_NewReference(self), but yes, yes, I understand that this is
not correct and won't really help.
Oleg.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
__del__ is not called after creating a new reference
I started to learn python a few days ago and I am trying to understand what
__del__() actually does. https://docs.python.org/3/reference/datamodel.html
says:
object.__del__(self)
...
Note that it is possible (though not recommended!) for the __del__()
method to postpone destruction of the instance by creating a new
reference to it. It may then be called at a later time when this new
reference is deleted.
However, this trivial test-case
class C:
def __del__(self):
print("DEL")
global X
X = self
C()
print(X)
X = 0
print(X)
shows that __del__ is called only once, it is not called again after "X = 0":
DEL
<__main__.C object at 0x7f067695f4a8>
0
(Just in case, I verified later that this object actually goes away and its
memory is freed, so the problem is not that it still has a reference).
I've cloned https://github.com/python/cpython.git and everything looks clear
at first glance (but let me repeat that I am very new to python):
PyObject_CallFinalizerFromDealloc() calls PyObject_CallFinalizer()
which finally calls "__del__" method in slot_tp_finalize(), then it
notices that "X = self" creates the new reference and does:
/* tp_finalize resurrected it! Make it look like the original Py_DECREF
* never happened.
*/
refcnt = self->ob_refcnt;
_Py_NewReference(self);
self->ob_refcnt = refcnt;
However, PyObject_CallFinalizer() also does _PyGC_SET_FINALIZED(self, 1)
and that is why __del__ is not called again after "X = 0":
/* tp_finalize should only be called once. */
if (PyType_IS_GC(tp) && _PyGC_FINALIZED(self))
return;
The comment and the code are very explicit, so this does nt look like a
bug in cpython.
Probably the docs should be fixed?
Or this code is actually wrong? The test-case works as documented if I
remove _PyGC_SET_FINALIZED() in PyObject_CallFinalizer() or add another
_PyGC_SET_FINALIZED(self, 0) into PyObject_CallFinalizerFromDealloc()
after _Py_NewReference(self), but yes, yes, I understand that this is
not correct and won't really help.
Oleg.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dynamically replacing an objects __class__; is it safe?
On 17/03/17 04:18, Gregory Ewing wrote: Dennis Lee Bieber wrote: I'd say satellites do "not" fly, as they have no force/action opposing the fall caused by the pull of gravity. Arrows, bullets, thrown stones, etc. are often said to be flying. Seems to me the word gets applied to anything that is moving while not contacting the ground. Yep, like a Ferrari on a motorway -- Tony van der Hoff| mailto:t...@vanderhoff.org Buckinghamshire, England | -- https://mail.python.org/mailman/listinfo/python-list
Re: How to add a built-in library in pyhton
Am 17.03.2017 05:08 schrieb chenchao: I use python2.7.10 and want to add a c language library in python. So how can i built it as a built-in module in python? Why do you want to build it as a built-in module? Why not a simple module as described on https://docs.python.org/2/extending/index.html ? Lutz -- https://mail.python.org/mailman/listinfo/python-list
