Re: Python is DOOMED! Again!
Steven D'Aprano writes: > No apples and no oranges aren't the same thing, but if somebody is expecting > no apples, and I give them no oranges instead, it would be churlish for them > to complain that none of them are the wrong kind of fruit. https://davedevine.wordpress.com/2011/01/20/the-sartre-joke/ -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
-- Devin On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano wrote: > Gregory Ewing wrote: > >> Steven D'Aprano wrote: >>> [quote] >>> If the object has a method named __dir__(), this method will >>> be called and must return the list of attributes. >>> [end quote] >>> >>> The first inaccuracy is that like all (nearly all?) dunder methods, >>> Python only looks for __dir__ on the class, not the instance itself. >> >> It says "method", not "attribute", so technically >> it's correct. The methods of an object are defined >> by what's in its class. > > Citation please. I'd like to see where that is defined. https://docs.python.org/3/glossary.html#term-method > Even if it is so defined, the definition is wrong. You can define methods on > an instance. I showed an example of an instance with its own personal > __dir__ method, and showed that dir() ignores it if the instance belongs to > a new-style class but uses it if it is an old-style class. You didn't define a method, you defined a callable attribute. Old-style classes will call those for special method overriding, because it's the simplest thing to do. New-style classes look methods up on the class as an optimization, but it also really complicates the attribute semantics. The lookup strategy is explicitly defined in the docs. pydoc is, like always, incomplete or inaccurate. See https://docs.python.org/2/reference/datamodel.html#special-method-names -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Michael Torrie : > http://en.cppreference.com/w/cpp/utility/functional/function > > Thus if we were to shoehorn your example into C++, the result would be > idiomatically very similar to what you have in your Python code. I can understand why you wouldn't write out my example in C++: using std::placeholders::_1; std::function f_add_display2 = std::bind( &Foo::print_add, foo, _1 ); vs f_add_display2 = foo.print_add The cherry on top: "_1"! The C++ compiler figures out template types heroically but can't wrap its head around the arity of the method. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
Gregory Ewing wrote: > Steven D'Aprano wrote: >> [quote] >> If the object has a method named __dir__(), this method will >> be called and must return the list of attributes. >> [end quote] >> >> The first inaccuracy is that like all (nearly all?) dunder methods, >> Python only looks for __dir__ on the class, not the instance itself. > > It says "method", not "attribute", so technically > it's correct. The methods of an object are defined > by what's in its class. Citation please. I'd like to see where that is defined. Even if it is so defined, the definition is wrong. You can define methods on an instance. I showed an example of an instance with its own personal __dir__ method, and showed that dir() ignores it if the instance belongs to a new-style class but uses it if it is an old-style class. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Paul Rubin wrote: > Chris Angelico writes: >> So since you can set something to Nothing regardless of type, and >> compare it against Nothing regardless of type, it doesn't really much >> matter that there are different types of Nothing. Right? > > No that's not how type inference works. If you have x = Nothing and > pass it to a function that takes a Maybe Int, type inference means the > compiler figures out that x must have type Maybe Int. If you then also > pass x to something that takes Maybe String, you are telling the > compiler that x has two different types at the same time, so the > compiler reports a type error. No apples and no oranges aren't the same thing, but if somebody is expecting no apples, and I give them no oranges instead, it would be churlish for them to complain that none of them are the wrong kind of fruit. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Chris Angelico wrote: > On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano > wrote: >> And there are underspecified rules too. What is the plural of octopus? No >> fair looking it up in the dictionary. > > Standard and well-known piece of trivia, and there are several > options. "Octopodes" is one of the most rigorously formal, but > "octopuses" is perfectly acceptable. "Octopi" is technically > incorrect, as the -us ending does not derive from the Latin. And that would be relevant if we were speaking Latin, but we aren't :-P -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Chris Angelico writes: > If you say "x = 5" and pass it to a function that accepts "Int or > String", the compiler knows that it's actually an Int. If you then > also pass that x to something that takes "Int or List", is that legal? You'd have to do that with type classes, but yeah, the compiler figures out that x is an Int. > If so, then 5 is separate from the "or String" and "or List" parts, > and Nothing is actually typed. If not, then it's x, not Nothing, that > has the type. Not sure what you mean there. Haskell is statically typed which means all expressions including literals have types. And an equality like x = y + z requires the two sides of the equality to have the same type. So if you say x = Nothing and the compiler infers (from some other place in the program) that x has type Maybe String, then the Nothing you wrote also has type Maybe String. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Mon, Feb 2, 2015 at 5:07 PM, Paul Rubin wrote: > Chris Angelico writes: >> So since you can set something to Nothing regardless of type, and >> compare it against Nothing regardless of type, it doesn't really much >> matter that there are different types of Nothing. Right? > > No that's not how type inference works. If you have x = Nothing and > pass it to a function that takes a Maybe Int, type inference means the > compiler figures out that x must have type Maybe Int. If you then also > pass x to something that takes Maybe String, you are telling the > compiler that x has two different types at the same time, so the > compiler reports a type error. If you say "x = 5" and pass it to a function that accepts "Int or String", the compiler knows that it's actually an Int. If you then also pass that x to something that takes "Int or List", is that legal? If so, then 5 is separate from the "or String" and "or List" parts, and Nothing is actually typed. If not, then it's x, not Nothing, that has the type. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Steven D'Aprano writes: > if type(ptr) == A: > if ptr != Anil: ... > if type(ptr) == B: > if ptr != Bnil: ... > etc. That would be insane. So how does Haskell do this? That wouldn't make sense in Haskell: the types are known at compile time, so you wouldn't do that runtime switching on them. > At the bottom of the page is a link to a .mov version. Didn't see that earlier. Managed to download and mplayer is able to show it. Thanks! You might like: http://learnyouahaskell.com/chapters -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Chris Angelico writes: > So since you can set something to Nothing regardless of type, and > compare it against Nothing regardless of type, it doesn't really much > matter that there are different types of Nothing. Right? No that's not how type inference works. If you have x = Nothing and pass it to a function that takes a Maybe Int, type inference means the compiler figures out that x must have type Maybe Int. If you then also pass x to something that takes Maybe String, you are telling the compiler that x has two different types at the same time, so the compiler reports a type error. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Devin Jeanpierre wrote: I answered my own question later, by accident: Java nulls are castable to each other if you do it explicitly (routing through Object -- e.g. (Something)((Object) ((SomeOtherThing) null. So in that sense, there is only one null, just with some arbitrary compiler distinctions you can break through if you try hard enough. You can't conclude that they all have the same runtime representation, though. The compiler could be generating code to convert them in response to the cast. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Mon, Feb 2, 2015 at 4:19 PM, Gregory Ewing wrote: > In Haskell you would just go ahead and compare ptr > with Nothing (or more likely pattern-match it against > Nothing). So since you can set something to Nothing regardless of type, and compare it against Nothing regardless of type, it doesn't really much matter that there are different types of Nothing. Right? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
Steven D'Aprano wrote: > Checking the REPL first would have revealed that [].__dir__ raises > AttributeError. In other words, lists don't have a __dir__ method. ? Python 3.4.2 (default, Nov 29 2014, 00:45:45) [GCC 4.8.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [].__dir__() ['sort', '__contains__', '__init__', '__ge__', 'count', '__class__', '__format__', '__mul__', 'index', '__rmul__', '__hash__', '__iter__', 'clear', '__subclasshook__', '__getitem__', 'reverse', 'append', '__ne__', 'pop', '__reduce__', '__add__', 'extend', '__gt__', '__sizeof__', '__setattr__', '__imul__', '__dir__', '__le__', 'insert', '__repr__', '__str__', '__getattribute__', '__len__', '__lt__', 'remove', '__new__', '__reduce_ex__', 'copy', '__reversed__', '__delattr__', '__eq__', '__setitem__', '__iadd__', '__doc__', '__delitem__'] >>> -- By ZeD -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Steven D'Aprano wrote: If I have an arbitrary pointer, and I want to check if it is safe to dereference, how do I do it? Surely I'm not expected to write something like: if type(ptr) == A: if ptr != Anil: ... if type(ptr) == B: if ptr != Bnil: ... etc. That would be insane. So how does Haskell do this? In Haskell you would just go ahead and compare ptr with Nothing (or more likely pattern-match it against Nothing). Haskell knows the type of the thing you're comparing to, and uses type inference to select the right type of Nothing to use. BTW, technically, Nothing isn't really a null pointer, it's a member of an algebraic type defined in the standard library: data Maybe a = Just a | Nothing So conceptually, there is a different Nothing for each possible type 'a' in Maybe a. But since the Nothing constructor doesn't have any arguments, the implementation could represent them all by the same value if it wanted. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
Steven D'Aprano wrote: [quote] If the object has a method named __dir__(), this method will be called and must return the list of attributes. [end quote] The first inaccuracy is that like all (nearly all?) dunder methods, Python only looks for __dir__ on the class, not the instance itself. It says "method", not "attribute", so technically it's correct. The methods of an object are defined by what's in its class. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] ‘python-daemon’ version 2.0.5 released
Howdy all, I am pleased to announce the release of version 2.0.5 of the ‘python-daemon’ library. The current release is always available at https://pypi.python.org/pypi/python-daemon/>. The project's forums and VCS are hosted at Alioth https://alioth.debian.org/projects/python-daemon/>. Significant changes since the previous version == This is a bug fix release, addressing these bugs: * Specify the text encoding when opening the changelog file. This addresses some reported failures of building the package from source. Thanks to those who reported problems. * Refine compatibility of exceptions for file operations. Different Python versions have drifted the hierarchy location of exceptions resulting from file operations. This release tests more conditions, and captures the correct exceptions more robustly. What is the ‘python-daemon’ library? ‘python-daemon’ is a Python library to implement a well-behaved Unix daemon process. -- \“Institutions will try to preserve the problem to which they | `\ are the solution.” —Clay Shirky, 2012 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On Mon, Feb 2, 2015 at 3:14 PM, Roy Smith wrote: > In article <54ceda0b$0$12977$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: > >> What is the plural of octopus? > > It's a trick question. Octopus is already plural. Monopus is singular. People is already plural, too, but you can talk about all the peoples of the world. Also, I can use "people" as the subject and "is" as the verb, just to completely destroy any chance of a simple grammar parser being able to cope with English. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
On Monday, February 2, 2015 at 9:34:53 AM UTC+5:30, Rustom Mody wrote:
> On Monday, February 2, 2015 at 9:22:51 AM UTC+5:30, Rustom Mody wrote:
> > On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> > > Rustom Mody wrote:
> > >
> > > > The other day I was taking a class in which I was showing
> > > > - introspection for discovering -- help, type, dir etc at the repl
> > > > - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b)
> > > >
> > > > And a student asked me the diff between
> > > > dir([])
> > > > and
> > > > [].__dir__()
> > > >
> > > > I didnt know what to say...
> > >
> > > Surely the right answer would have been "I don't know, let's check the
> > > interactive interpreter first, and the docs second."
> > >
> > > Checking the REPL first would have revealed that [].__dir__ raises
> > > AttributeError. In other words, lists don't have a __dir__ method.
> >
> > ??
> >
> > $ python3
> > Python 3.4.2 (default, Oct 8 2014, 13:08:17)
> > [GCC 4.9.1] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> [].__dir__
> >
> > >>> dir([])
> > ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__',
> > '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
> > '__getitem__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__',
> > '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__',
> > '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__',
> > '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__',
> > 'append', 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop',
> > 'remove', 'reverse', 'sort']
> > >>> [].__dir__()
> > ['__rmul__', '__str__', '__gt__', 'remove', '__class__', '__getitem__',
> > '__format__', '__ne__', '__sizeof__', '__contains__', '__reduce__',
> > '__add__', 'sort', 'count', 'extend', '__mul__', '__imul__',
> > '__reduce_ex__', '__setitem__', '__doc__', '__ge__', 'copy', '__init__',
> > '__iadd__', '__hash__', '__delitem__', 'insert', '__iter__', '__repr__',
> > '__le__', '__setattr__', 'reverse', '__new__', '__eq__', '__len__',
> > 'index', '__lt__', 'clear', '__subclasshook__', 'append', '__dir__',
> > '__reversed__', '__getattribute__', 'pop', '__delattr__']
> > >>>
> >
> > What you are describing seems to be true for python2 though
>
> And since they *looked* different I believed they were different.
>
> Evidently not…
>
> >>> s1= set([].__dir__())
> >>> s2=set(dir([]))
> >>> s1
> {'__rmul__', '__str__', '__class__', '__ne__', '__repr__', '__format__',
> '__sizeof__', '__contains__', '__add__', 'sort', 'count', 'extend', 'remove',
> '__mul__', '__reduce__', '__imul__', '__reduce_ex__', '__setitem__',
> 'insert', '__doc__', '__ge__', 'index', 'copy', '__subclasshook__',
> '__getitem__', '__init__', '__iadd__', '__hash__', '__delitem__', '__iter__',
> '__le__', '__setattr__', 'reverse', '__new__', '__eq__', '__len__', '__lt__',
> 'clear', '__gt__', 'append', '__dir__', '__reversed__', '__getattribute__',
> 'pop', '__delattr__'}
> >>> s2
> {'__rmul__', '__str__', '__class__', '__ne__', '__repr__', '__format__',
> '__sizeof__', '__contains__', '__add__', 'sort', 'count', 'extend',
> '__mul__', 'remove', '__imul__', '__reduce__', '__reduce_ex__',
> '__setitem__', 'insert', '__doc__', '__ge__', '__subclasshook__', 'copy',
> 'index', '__getitem__', '__iadd__', '__init__', '__hash__', '__delitem__',
> '__iter__', '__le__', '__setattr__', 'reverse', '__new__', '__eq__',
> '__len__', '__lt__', 'clear', '__gt__', 'append', '__dir__', '__reversed__',
> '__getattribute__', 'pop', '__delattr__'}
> >>> len(s1)
> 45
> >>> len(s2)
> 45
> >>> s1 - s2
> set()
> >>> s2 - s1
> set()
Well I continue to be fooled
>>> d1 = {k:getattr([],k) for k in [].__dir__()}
>>> d2 = {k:getattr([],k) for k in dir([])}
>>> d1 == d2
False
>>> len(d1)
45
>>> len(d2)
45
>>> d1.keys()
dict_keys(['__rmul__', '__str__', '__gt__', '__mul__', '__class__', '__ne__',
'__format__', '__sizeof__', '__contains__', '__imul__', '__add__', 'sort',
'count', 'extend', 'remove', '__init__', 'insert', '__setitem__', 'index',
'__subclasshook__', 'copy', '__getitem__', '__iadd__', '__hash__',
'__delitem__', '__reduce_ex__', '__iter__', '__repr__', '__le__',
'__setattr__', 'reverse', '__new__', '__eq__', '__len__', '__doc__', '__lt__',
'clear', '__ge__', 'append', '__dir__', '__reversed__', '__getattribute__',
'pop', '__delattr__', '__reduce__'])
>>> d1.keys() == d2.keys()
True
--
https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
In article <54ceda0b$0$12977$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > What is the plural of octopus? It's a trick question. Octopus is already plural. Monopus is singular. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
In article , Chris Angelico wrote: > On Mon, Feb 2, 2015 at 1:35 PM, Matthew Barnett > wrote: > > And the plural of "virus" is "viruses", not "viri" (that's the plural of > > "vir") or "virii" (that would be the plural of "virius", if it existed). > > Yes indeed."Virii" and "octopi" are as wrong as "hice" for "houses" > (paralleling mice). And, of course, I die, but we dice. -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
On Monday, February 2, 2015 at 9:22:51 AM UTC+5:30, Rustom Mody wrote:
> On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> > Rustom Mody wrote:
> >
> > > The other day I was taking a class in which I was showing
> > > - introspection for discovering -- help, type, dir etc at the repl
> > > - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b)
> > >
> > > And a student asked me the diff between
> > > dir([])
> > > and
> > > [].__dir__()
> > >
> > > I didnt know what to say...
> >
> > Surely the right answer would have been "I don't know, let's check the
> > interactive interpreter first, and the docs second."
> >
> > Checking the REPL first would have revealed that [].__dir__ raises
> > AttributeError. In other words, lists don't have a __dir__ method.
>
> ??
>
> $ python3
> Python 3.4.2 (default, Oct 8 2014, 13:08:17)
> [GCC 4.9.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> [].__dir__
>
> >>> dir([])
> ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__',
> '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
> '__getitem__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__',
> '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__',
> '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__',
> '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__',
> 'append', 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop',
> 'remove', 'reverse', 'sort']
> >>> [].__dir__()
> ['__rmul__', '__str__', '__gt__', 'remove', '__class__', '__getitem__',
> '__format__', '__ne__', '__sizeof__', '__contains__', '__reduce__',
> '__add__', 'sort', 'count', 'extend', '__mul__', '__imul__', '__reduce_ex__',
> '__setitem__', '__doc__', '__ge__', 'copy', '__init__', '__iadd__',
> '__hash__', '__delitem__', 'insert', '__iter__', '__repr__', '__le__',
> '__setattr__', 'reverse', '__new__', '__eq__', '__len__', 'index', '__lt__',
> 'clear', '__subclasshook__', 'append', '__dir__', '__reversed__',
> '__getattribute__', 'pop', '__delattr__']
> >>>
>
> What you are describing seems to be true for python2 though
And since they *looked* different I believed they were different.
Evidently not…
>>> s1= set([].__dir__())
>>> s2=set(dir([]))
>>> s1
{'__rmul__', '__str__', '__class__', '__ne__', '__repr__', '__format__',
'__sizeof__', '__contains__', '__add__', 'sort', 'count', 'extend', 'remove',
'__mul__', '__reduce__', '__imul__', '__reduce_ex__', '__setitem__', 'insert',
'__doc__', '__ge__', 'index', 'copy', '__subclasshook__', '__getitem__',
'__init__', '__iadd__', '__hash__', '__delitem__', '__iter__', '__le__',
'__setattr__', 'reverse', '__new__', '__eq__', '__len__', '__lt__', 'clear',
'__gt__', 'append', '__dir__', '__reversed__', '__getattribute__', 'pop',
'__delattr__'}
>>> s2
{'__rmul__', '__str__', '__class__', '__ne__', '__repr__', '__format__',
'__sizeof__', '__contains__', '__add__', 'sort', 'count', 'extend', '__mul__',
'remove', '__imul__', '__reduce__', '__reduce_ex__', '__setitem__', 'insert',
'__doc__', '__ge__', '__subclasshook__', 'copy', 'index', '__getitem__',
'__iadd__', '__init__', '__hash__', '__delitem__', '__iter__', '__le__',
'__setattr__', 'reverse', '__new__', '__eq__', '__len__', '__lt__', 'clear',
'__gt__', 'append', '__dir__', '__reversed__', '__getattribute__', 'pop',
'__delattr__'}
>>> len(s1)
45
>>> len(s2)
45
>>> s1 - s2
set()
>>> s2 - s1
set()
--
https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote: > Rustom Mody wrote: > > > The other day I was taking a class in which I was showing > > - introspection for discovering -- help, type, dir etc at the repl > > - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b) > > > > And a student asked me the diff between > > dir([]) > > and > > [].__dir__() > > > > I didnt know what to say... > > Surely the right answer would have been "I don't know, let's check the > interactive interpreter first, and the docs second." > > Checking the REPL first would have revealed that [].__dir__ raises > AttributeError. In other words, lists don't have a __dir__ method. ?? $ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [].__dir__ >>> dir([]) ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'append', 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort'] >>> [].__dir__() ['__rmul__', '__str__', '__gt__', 'remove', '__class__', '__getitem__', '__format__', '__ne__', '__sizeof__', '__contains__', '__reduce__', '__add__', 'sort', 'count', 'extend', '__mul__', '__imul__', '__reduce_ex__', '__setitem__', '__doc__', '__ge__', 'copy', '__init__', '__iadd__', '__hash__', '__delitem__', 'insert', '__iter__', '__repr__', '__le__', '__setattr__', 'reverse', '__new__', '__eq__', '__len__', 'index', '__lt__', 'clear', '__subclasshook__', 'append', '__dir__', '__reversed__', '__getattribute__', 'pop', '__delattr__'] >>> What you are describing seems to be true for python2 though -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On Mon, Feb 2, 2015 at 1:35 PM, Matthew Barnett wrote: > And the plural of "virus" is "viruses", not "viri" (that's the plural of > "vir") or "virii" (that would be the plural of "virius", if it existed). Yes indeed."Virii" and "octopi" are as wrong as "hice" for "houses" (paralleling mice). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On 2015-02-02 02:04, Chris Angelico wrote: On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano wrote: And there are underspecified rules too. What is the plural of octopus? No fair looking it up in the dictionary. Standard and well-known piece of trivia, and there are several options. "Octopodes" is one of the most rigorously formal, but "octopuses" is perfectly acceptable. "Octopi" is technically incorrect, as the -us ending does not derive from the Latin. And the plural of "virus" is "viruses", not "viri" (that's the plural of "vir") or "virii" (that would be the plural of "virius", if it existed). -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Steven D'Aprano wrote: > Of course people make grammar mistakes that they don't spot. Ironically, this is one of them. It should of course be "grammatical mistakes". Seriously, I didn't do that on purpose. I only noticed the error on reading it back after sending. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Devin Jeanpierre wrote: > So in that sense, there is only one null, just with some arbitrary > compiler distinctions you can break through if you try hard enough. Woo hoo! I was right! *Dances the Dance of Victory!* -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On Mon, Feb 2, 2015 at 12:59 PM, Steven D'Aprano wrote: > And there are underspecified rules too. What is the plural of octopus? No > fair looking it up in the dictionary. Standard and well-known piece of trivia, and there are several options. "Octopodes" is one of the most rigorously formal, but "octopuses" is perfectly acceptable. "Octopi" is technically incorrect, as the -us ending does not derive from the Latin. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Marko Rauhamaa wrote: > Steven D'Aprano : > >> Marko Rauhamaa wrote: >> >>> The natural language has a rigorous grammar plus a lexicon that includes >>> a number of idioms. Nobody has so far been able to codify a natural >>> language completely because the rigorous grammar consists of maybe >>> 10,000 rules. >> >> If nobody has codified the rigorous grammar, how do they know it is >> rigorous? > > Even a five-year-old will immediately spot grammar mistakes (and let you > know about them!). That doesn't make it rigorous. That just means that there are rules, and five-years olds know some of the rules. There may be ambiguities in the rules. There could be sentences where no rule applies, or multiple contradictory rules. Children go through a period of language acquisition where they over-generalise rules, saying things like "I eated the biscuit". Amusingly, there are at least some reports of children getting angry when their parents copy those over-generalisations, saying words to the effect of "No Daddy, I say eated, you don't!" This suggests that they know that the rule is wrong even when they say it, yet they continue to say it. This in turn suggests that there are multiple parts of the brain involved in grammar, and they aren't always in sync. Adults also commit hyper-correction. Anyone who has said a sentence like "The dog barked at my daughter and I" is being ungrammatical. Cross out the second party, and you are left with: "The dog barked at I" which is clearly wrong. And there are underspecified rules too. What is the plural of octopus? No fair looking it up in the dictionary. [...] > Whatever it is, your brain will recognize its native language. You never > make a grammar mistake that you don't spot yourself right away. Of course people make grammar mistakes that they don't spot. If you're interested in this topic, I can strongly recommend Steven Pinker's book "Words And Rules". -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On 02/01/2015 05:50 PM, Michael Torrie wrote: > Honestly with the C++ standard library implementing std::function and > std::bind macros, idiomatically it would look very much similar to the > Python code you showed. Make that templates, not macros. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On 02/01/2015 12:12 PM, Marko Rauhamaa wrote: > So please implement this small piece of Python code in C++ so we can > compare the idioms: So I though I might just for kicks code up a C++ version. In doing so, I realized that idomatically, this particular example would not really use callbacks in real life, but rather stream objects. Would look nearly the same but be more idiomatic C++. However, C++ function pointers are actually pretty slick in C++11. See the example near the bottom of the page: http://en.cppreference.com/w/cpp/utility/functional/function Thus if we were to shoehorn your example into C++, the result would be idiomatically very similar to what you have in your Python code. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On 02/01/2015 12:12 PM, Marko Rauhamaa wrote:
> Christian Gollwitzer :
>
>> Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
>>> Qt gave up on C++ when it comes to callbacks ("signals") and went for
>>> an apocryphal metacompiler.
>>
>> Yes, but only because C++ compilers were not good enough when QT came
>> out, and later is was too late to change it to a templated system.
>> Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
>> using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
>> for a reasoning of QT.
>>
>> In C++11 (supported by MSVC, g++, clang) there re also lambda expressions
>
> So please implement this small piece of Python code in C++ so we can
> compare the idioms:
Honestly with the C++ standard library implementing std::function and
std::bind macros, idiomatically it would look very much similar to the
Python code you showed.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Sun, Feb 1, 2015 at 2:27 PM, Paul Rubin wrote: > Devin Jeanpierre writes: >> That said, Haskell (and the rest) do have a sort of type coercion, of >> literals at compile time (e.g. 3 can be an Integer or a Double >> depending on how you use it.) > > That's polymorphism, not coercion. OK, yes, that fits better into how Haskell works. After all, that's how "Nothing" works. If 3 is just a (magic) constructor, then it's no different. > The compiler figures out at compile > time what type of 3 you actually mean: there is never an automatic > runtime conversion. sqrt(3) works because sqrt expects a floating > argument so the compiler deduces that the 3 that you wrote denotes a > float. sqrt(3+length(xs)) has to fail because length returns an int, so > 3+length(xs) is an int, and you can't pass an int to sqrt. > >> BTW it's weird that in this thread, and in the programmer community at >> large, int->string is considered worse than int->float > > Hehe, though int->string leads to plenty of weird bugs. > >>> Haskell's idiomatic substitute for a null pointer is a Nothing value >> For that matter, how is this (first part) different from, say, Java? > > In Java, functions expecting to receve sensible values can get null by > surprise. In Haskell, if a term can have a Nothing value, that has to > be reflected in its type. Haskell's bug-magnet counterpart to Java's > null values is Bottom, an artifact of lazy evaluation. E.g. you can > write >x = 3 / 0 > someplace in your program, and the program will accept this and run > merrily until you try to actually print something that depends on x, > at which point it crashes. This isn't a difference in whether there are multiple nulls, though. I answered my own question later, by accident: Java nulls are castable to each other if you do it explicitly (routing through Object -- e.g. (Something)((Object) ((SomeOtherThing) null. So in that sense, there is only one null, just with some arbitrary compiler distinctions you can break through if you try hard enough. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Devin Jeanpierre writes: > That said, Haskell (and the rest) do have a sort of type coercion, of > literals at compile time (e.g. 3 can be an Integer or a Double > depending on how you use it.) That's polymorphism, not coercion. The compiler figures out at compile time what type of 3 you actually mean: there is never an automatic runtime conversion. sqrt(3) works because sqrt expects a floating argument so the compiler deduces that the 3 that you wrote denotes a float. sqrt(3+length(xs)) has to fail because length returns an int, so 3+length(xs) is an int, and you can't pass an int to sqrt. > BTW it's weird that in this thread, and in the programmer community at > large, int->string is considered worse than int->float Hehe, though int->string leads to plenty of weird bugs. >> Haskell's idiomatic substitute for a null pointer is a Nothing value > For that matter, how is this (first part) different from, say, Java? In Java, functions expecting to receve sensible values can get null by surprise. In Haskell, if a term can have a Nothing value, that has to be reflected in its type. Haskell's bug-magnet counterpart to Java's null values is Bottom, an artifact of lazy evaluation. E.g. you can write x = 3 / 0 someplace in your program, and the program will accept this and run merrily until you try to actually print something that depends on x, at which point it crashes. -- https://mail.python.org/mailman/listinfo/python-list
Re: pydoc3.5 borks on my Mac
On 01Feb2015 14:17, Skip Montanaro wrote: On Sun, Feb 1, 2015 at 1:35 PM, Peter Otten <__pete...@web.de> wrote: $ LANG=en_US.UTF-8 python3 -c 'import locale; print(locale.getpreferredencoding(False))' Aha! hgpython% LANG=en_US.UTF-8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' UTF-8 hgpython% LANG=en_US.utf8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' US-ASCII Thank you. I always thought these Unicode encodings were supposed to be case-insensitive. The latter lacks a dash. See if it's that. Cheers, Cameron Simpson A feature is a bug with seniority. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Steven D'Aprano writes: > C has a single nil pointer compatible with all pointer types. C++11 has a separate type just for the null pointer, which can be automatically coerced to other pointer types. I'm not sure but I think that means it is couthing up slightly. http://en.cppreference.com/w/cpp/types/nullptr_t http://en.cppreference.com/w/cpp/language/nullptr -- https://mail.python.org/mailman/listinfo/python-list
Re: pydoc3.5 borks on my Mac
On Sun, Feb 1, 2015 at 2:31 PM, Chris Angelico wrote: > Try the other variations: include the hyphen > but don't capitalize, and the other way around. On my system, all four > work equally: Yes, on my system, case doesn't matter, but the hyphen does. I just tried it out on one of my Linux systems at work. It's an aging openSuSE 12.2 system, so all I could install was 3.2.3, but it worked exactly like your system. Any capitalization, with or without the hyphen, and the pydoc3.2 command worked. With LANG=C or with LANG unset, I get the UnicodeEncodeError traceback. FYI, I did open a bug report, and tried to transfer the useful bits from this thread to it: http://bugs.python.org/issue23374 Thanks to Peter and Chris. I'm off and running. Well, until I stumble over the next tree root or crack in the sidewalk... Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
On 2/1/2015 12:45 PM, Chris Angelico wrote: Simple answer: You write dunder methods and the interpreter calls them. You don't call them yourself. I can't currently think of any situation where it's appropriate to call a dunder method manually (cue the swamping of such situations on the list); you just call dir() or the + operator or whatever it be. calling the parent dunder method from within the overiding new method comes to mind. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
On Sun, Feb 1, 2015 at 4:36 PM, Rustom Mody wrote: > The other day I was taking a class in which I was showing > - introspection for discovering -- help, type, dir etc at the repl > - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b) > > And a student asked me the diff between > dir([]) > and > [].__dir__() > > I didnt know what to say... Simple answer: You write dunder methods and the interpreter calls them. You don't call them yourself. I can't currently think of any situation where it's appropriate to call a dunder method manually (cue the swamping of such situations on the list); you just call dir() or the + operator or whatever it be. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On Mon, Feb 2, 2015 at 6:36 AM, Ian Kelly wrote: >> At long last my quest seeking the final entry for the Zen of Python is over. >> I'll be delighted to let you accept the honour of raising an issue on the >> bug tracker to get the "this" module changed to reflect my new found wisdom. > > And while you're at it, please also work on changing the name of the > module to "self" -- "this" is for Java. I thought it was meant to be like English - "Here, import this". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: pydoc3.5 borks on my Mac
On Mon, Feb 2, 2015 at 7:17 AM, Skip Montanaro wrote: > Thank you. I always thought these Unicode encodings were supposed to > be case-insensitive. I'd have thought so, too. Try the other variations: include the hyphen but don't capitalize, and the other way around. On my system, all four work equally: rosuav@sikorsky:~$ echo $LANG en_AU.UTF-8 rosuav@sikorsky:~$ LANG=en_AU.utf8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' UTF-8 rosuav@sikorsky:~$ LANG=en_AU.utf-8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' UTF-8 rosuav@sikorsky:~$ LANG=en_AU.UTF8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' UTF-8 rosuav@sikorsky:~$ LANG=en_AU.UTF-8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' UTF-8 However, and very interestingly, en_US does not: rosuav@sikorsky:~$ LANG=en_US.UTF-8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' ANSI_X3.4-1968 Which is probably because I don't have US locales installed. Maybe there's something about exactly what's installed?? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On 01/02/2015 19:36, Ian Kelly wrote: On Sun, Feb 1, 2015 at 11:49 AM, Mark Lawrence wrote: On 01/02/2015 18:14, Grant Edwards wrote: A loop containing 1 line of code will execute in the same abount of time as that loop with 1 line of code and 99 blanks lines. The latter loop is running at 100 times as many lines/second as the former. That's _got_ to be better. At long last my quest seeking the final entry for the Zen of Python is over. I'll be delighted to let you accept the honour of raising an issue on the bug tracker to get the "this" module changed to reflect my new found wisdom. And while you're at it, please also work on changing the name of the module to "self" -- "this" is for Java. I think that'll need a PEP :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: pydoc3.5 borks on my Mac
On Sun, Feb 1, 2015 at 1:35 PM, Peter Otten <__pete...@web.de> wrote: > $ LANG=en_US.UTF-8 python3 -c 'import locale; > print(locale.getpreferredencoding(False))' Aha! hgpython% LANG=en_US.UTF-8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' UTF-8 hgpython% LANG=en_US.utf8 python3.5 -c 'import locale; print(locale.getpreferredencoding(False))' US-ASCII Thank you. I always thought these Unicode encodings were supposed to be case-insensitive. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On Sun, Feb 1, 2015 at 11:49 AM, Mark Lawrence wrote: > On 01/02/2015 18:14, Grant Edwards wrote: >> A loop containing 1 line of code will execute in the same abount of >> time as that loop with 1 line of code and 99 blanks lines. >> >> The latter loop is running at 100 times as many lines/second as the >> former. That's _got_ to be better. >> > > At long last my quest seeking the final entry for the Zen of Python is over. > I'll be delighted to let you accept the honour of raising an issue on the > bug tracker to get the "this" module changed to reflect my new found wisdom. And while you're at it, please also work on changing the name of the module to "self" -- "this" is for Java. -- https://mail.python.org/mailman/listinfo/python-list
Re: pydoc3.5 borks on my Mac
Skip Montanaro wrote:
> On Sun, Feb 1, 2015 at 11:20 AM, Peter Otten <__pete...@web.de> wrote:
>> Try setting the environment variable
>>
>> PYTHONIOENCODING=UTF-8
>
> Thanks, but that didn't help. I still get the same exception.
The pager is invoked by os.popen(), and after some digging I find that it
uses a io.TestIOWrapper() to write the help text. This in turn uses
locale.getpreferredencoding(False), i. e. you were right to set LANG and
PYTHONIOENCODING is not relevant.
I'm able to provoke what I think causes your problem on linux with Python 3.4:
$ LANG=en_US.utf-8 python3 -c 'import os; os.popen("cat", "w").write("\xe4\n")'
ä
$ LANG=en_US.ascii python3 -c 'import os; os.popen("cat", "w").write("\xe4\n")'
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 0:
ordinal not in range(128)
Perhaps LANG=en_US.utf-8 is not understood by your system (uppercase UTF-8? I
really don't know the Mac).
What does
$ LANG=en_US.UTF-8 python3 -c 'import locale;
print(locale.getpreferredencoding(False))'
UTF-8
print?
--
https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Christian Gollwitzer :
> Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
>> Qt gave up on C++ when it comes to callbacks ("signals") and went for
>> an apocryphal metacompiler.
>
> Yes, but only because C++ compilers were not good enough when QT came
> out, and later is was too late to change it to a templated system.
> Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
> using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
> for a reasoning of QT.
>
> In C++11 (supported by MSVC, g++, clang) there re also lambda expressions
So please implement this small piece of Python code in C++ so we can
compare the idioms:
import sys, time
class MyLogger:
def __init__(self, write):
self.write = sys.stderr.write
def register_writer(self, write):
self.write = write
def log(self, text):
self.write("{} {}\n".format(time.time(), text))
class MyApp:
def __init__(self, logger):
self.logf = open("thelog.log", "a")
logger.register_writer(self.log_write)
def log_write(self, text):
self.logf.write(text)
self.logf.flush()
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: CSV and number formats
On 1/31/2015 10:45 PM, Frank Millman wrote: If the opening balance is positive, it appears as '+0021.45' If it is negative, it appears as '+0-21.45' My advise is to get cash in payment. :) Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Steven D'Aprano : > Marko Rauhamaa wrote: > >> The natural language has a rigorous grammar plus a lexicon that includes >> a number of idioms. Nobody has so far been able to codify a natural >> language completely because the rigorous grammar consists of maybe >> 10,000 rules. > > If nobody has codified the rigorous grammar, how do they know it is > rigorous? Even a five-year-old will immediately spot grammar mistakes (and let you know about them!). > Given how natural languages are constantly in flux (in both space and time), > I don't even know how you could define all the rules of a grammar > rigorously. By the time you finished, it would be different. Every brain has a slightly different variant, and that is evolving, too. However, you can spot a non-native speaker (or a speaker outside your community) in a fraction of a second after they open their mouth. > If grammar is defined by usage, not formal rule books (which don't > exist!), then surely LOLspeak is grammatical. (It's probably closer to > an argot than a full language, but even so.) Whatever it is, your brain will recognize its native language. You never make a grammar mistake that you don't spot yourself right away. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On 01/02/2015 18:14, Grant Edwards wrote: No, you've got that backwards. You want_more_ blank lines. A blank line takes zero time to run, but it still counts as a line in your lines/second stats. You want more blanks lines to satisfy bean counting managers who want you to report "number of lines of code written per week". More blank lines equals happier managers! ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On Sat, Jan 31, 2015 at 7:38 PM, Jason Friedman wrote:
>> I have two lists
>>
>> l1 = ["a","b","c","d","e","f","g","h","i","j"]
>> l2 = ["aR","bR","cR"]
>>
>> l2 will always be smaller or equal to l1
>>
>> numL1PerL2 = len(l1)/len(l2)
>>
>> I want to create a dictionary that has key from l1 and value from l2 based
>> on numL1PerL2
>>
>> So
>>
>> {
>> a:aR,
>> b:aR,
>> c:aR,
>> d:bR,
>> e:bR,
>> f:bR,
>> g:cR,
>> h:cR,
>> i:cR,
>> j:cR
>> }
>
> Another possibility is:
> import itertools
> my_dict = {x:y for x,y in zip(list1, itertools.cycle(list2))}
That results in a different mapping than the one specified by the OP,
though. An alternate itertools approach could be:
dict(zip_longest(l1, chain.from_iterable(
map(partial(repeat, times=len(l1) // len(l2)), l2)), fillvalue=l2[-1]))
although this requires the inputs to be sequences, not arbitrary iterables.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On 01/02/2015 18:14, Grant Edwards wrote: On 2015-02-01, Chris Angelico wrote: On Sun, Feb 1, 2015 at 2:06 PM, Mark Lawrence wrote: The one-liner might not be better code, but it must be better speed wise precisely because it's on one line, right? :) Well of course it is. Python code speed is always measured in lines per minute. That's why you should eliminate blank lines from your code. No, you've got that backwards. You want _more_ blank lines. A blank line takes zero time to run, but it still counts as a line in your lines/second stats. A loop containing 1 line of code will execute in the same abount of time as that loop with 1 line of code and 99 blanks lines. The latter loop is running at 100 times as many lines/second as the former. That's _got_ to be better. At long last my quest seeking the final entry for the Zen of Python is over. I'll be delighted to let you accept the honour of raising an issue on the bug tracker to get the "this" module changed to reflect my new found wisdom. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: pydoc3.5 borks on my Mac
On Sun, Feb 1, 2015 at 11:20 AM, Peter Otten <__pete...@web.de> wrote: > Try setting the environment variable > > PYTHONIOENCODING=UTF-8 Thanks, but that didn't help. I still get the same exception. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On 2015-02-01, Chris Angelico wrote: > On Sun, Feb 1, 2015 at 2:06 PM, Mark Lawrence wrote: >> The one-liner might not be better code, but it must be better speed wise >> precisely because it's on one line, right? :) > > Well of course it is. Python code speed is always measured in lines > per minute. That's why you should eliminate blank lines from your > code. No, you've got that backwards. You want _more_ blank lines. A blank line takes zero time to run, but it still counts as a line in your lines/second stats. A loop containing 1 line of code will execute in the same abount of time as that loop with 1 line of code and 99 blanks lines. The latter loop is running at 100 times as many lines/second as the former. That's _got_ to be better. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Sun, Feb 1, 2015 at 8:31 AM, Steven D'Aprano
wrote:
> Paul Rubin wrote:
>> It's completely practical: polymorphism and type inference get you the
>> value you want with usually no effort on your part.
>
> But it's the "usually" that bites you.
>
> If I have an arbitrary pointer, and I want to check if it is safe to
> dereference, how do I do it? Surely I'm not expected to write something
> like:
>
> if type(ptr) == A:
> if ptr != Anil: ...
> if type(ptr) == B:
> if ptr != Bnil: ...
>
> etc. That would be insane. So how does Haskell do this?
Haskell has different nulls in the same sense Java does: there's one
keyword, whose type varies by context. Unlike Java, there is no way at
all to cast different nulls to different types. Haskell has return
value polymorphism and generics, so it's very easy for a function to
return values of different types depending on type parameters. So this
isn't even compiler hackery, it's ordinary.
Also, you don't dereference in Haskell, you unpack. Python and Haskell code:
if x is None:
print("Not found!")
else:
print x
case x of
Nothing -> putStrLn "Not found"
Some y -> putStrLn (show y)
Both of these work whenever x is something that can be null and can be
shown -- in Haskell, that's anything of type Maybe T, where you have
access to a Show implementation for T. In Python, None is its own
type/value, in Haskell there is an incompatible Nothing for each T.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
On Sun, Feb 1, 2015 at 9:55 AM, Steven D'Aprano wrote: > Steven D'Aprano wrote: > >> len tries to call __len__ if it exists, and if not, it tries walking the >> iterable counting items. > > Hmmm, I may have mis-remembered that. Perhaps I'm thinking of Ruby. I think you just got it backward. iter will call __iter__ if it exists, and will try to fall back on __len__ and __getitem__ to iterate otherwise. -- https://mail.python.org/mailman/listinfo/python-list
Re: pydoc3.5 borks on my Mac
Skip Montanaro wrote: > I finally got sort of smart, and started up a pydoc server. Looking at > the sqlite3 docs through my browser, I see right off the bat, I see > > #-*- coding: ISO-8859-1 -*- > # pysqlite2/__init__.py: the pysqlite2 package. > # > # Copyright (C) 2005 Gerhard Häring > > so my challenge is how to tell Python my terminal's encoding? It's > clearly assuming ASCII. Mine is actually normally set to UTF-8, but I > can select from a number of different encodings in the Preferences. Try setting the environment variable PYTHONIOENCODING=UTF-8 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Steven D'Aprano wrote: > Devin Jeanpierre wrote: > >> It's really only dynamically typed languages that have a single null >> value of a single type. Maybe I misunderstand the original statement. > > Pascal is statically typed and has a single null pointer compatible with > all pointer types. I'm not having a good night... In Pascal, it is spelled *nil*, not null, and it is a keyword. > C has a single nil pointer compatible with all pointer > types. And in C it is null, which apparently isn't an actual value but a macro. > I expect that the Modula and Oberon family of languages copied > Pascal, which probably copied Algol. At least I was right about Modula: The constant NIL is compatible with all pointer types, and designates a pointer that does not point to any object. NIL can be assigned to any pointer type, and any pointer type can be compared to NIL. http://www.modula2.org/reference/pointertypes.php Likewise for Oberon and Oberon-2. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
Steven D'Aprano wrote: > len tries to call __len__ if it exists, and if not, it tries walking the > iterable counting items. Hmmm, I may have mis-remembered that. Perhaps I'm thinking of Ruby. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Sun, Feb 1, 2015 at 8:34 AM, Steven D'Aprano wrote: > Devin Jeanpierre wrote: > >> It's really only dynamically typed languages that have a single null >> value of a single type. Maybe I misunderstand the original statement. > > Pascal is statically typed and has a single null pointer compatible with all > pointer types. C has a single nil pointer compatible with all pointer > types. I expect that the Modula and Oberon family of languages copied > Pascal, which probably copied Algol. No, C has a NULL macro which evaluates to something which coerces to any pointer type and will be the null value of that type. But there's one null value per type. The C standard makes no guarantees that they are compatible in any way, e.g. they can be of different sizes. On some systems, the null function pointer will have a size of N, where the null int pointer will have a size of M, where N != M -- so these are clearly not the same null value. I don't know Pascal, but I wouldn't be surprised if something similar held, as nonuniform pointer sizes were a thing once. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Marko Rauhamaa wrote: > The natural language has a rigorous grammar plus a lexicon that includes > a number of idioms. Nobody has so far been able to codify a natural > language completely because the rigorous grammar consists of maybe > 10,000 rules. If nobody has codified the rigorous grammar, how do they know it is rigorous? Given how natural languages are constantly in flux (in both space and time), I don't even know how you could define all the rules of a grammar rigorously. By the time you finished, it would be different. Of course, some rules are more rigorous than others. No English speaker would consider a sentence like Can me cheeseburger has? as grammatical. But how about: I can has cheezburger? If grammar is defined by usage, not formal rule books (which don't exist!), then surely LOLspeak is grammatical. (It's probably closer to an argot than a full language, but even so.) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: pydoc3.5 borks on my Mac
I finally got sort of smart, and started up a pydoc server. Looking at the sqlite3 docs through my browser, I see right off the bat, I see #-*- coding: ISO-8859-1 -*- # pysqlite2/__init__.py: the pysqlite2 package. # # Copyright (C) 2005 Gerhard Häring so my challenge is how to tell Python my terminal's encoding? It's clearly assuming ASCII. Mine is actually normally set to UTF-8, but I can select from a number of different encodings in the Preferences. Thx, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Devin Jeanpierre wrote: > It's really only dynamically typed languages that have a single null > value of a single type. Maybe I misunderstand the original statement. Pascal is statically typed and has a single null pointer compatible with all pointer types. C has a single nil pointer compatible with all pointer types. I expect that the Modula and Oberon family of languages copied Pascal, which probably copied Algol. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Paul Rubin wrote:
> Steven D'Aprano writes:
>> Some degree of weakness in a type system is not necessarily bad. Even the
>> strongest of languages usually allow a few exceptions, such as numeric
>> coercions.
>
> Haskell doesn't have automatic coercions of any sort. You have to call
> a conversion function if you want to turn an Int into an Integer.
That's unusual but not unheard of.
>> I've never come across a language that has pointers which insists on
>> having a separate Nil pointer for ever pointer type
>
> Haskell's idiomatic substitute for a null pointer is a Nothing value
> (like Python's None) and there's a separate one for every type. The FFI
> offers actual pointers (Foreign.Ptr) and there is a separate nullPtr
> for every type.
Well, I live and learn.
>> the compiler will allow Nil to be used for any pointer type. Anything
>> else would be impractical.
>
> It's completely practical: polymorphism and type inference get you the
> value you want with usually no effort on your part.
But it's the "usually" that bites you.
If I have an arbitrary pointer, and I want to check if it is safe to
dereference, how do I do it? Surely I'm not expected to write something
like:
if type(ptr) == A:
if ptr != Anil: ...
if type(ptr) == B:
if ptr != Bnil: ...
etc. That would be insane. So how does Haskell do this?
>> What if you add two empty objects?
>> js> {} + {}
>
> OMG, javascript is worse than I thought
>
>> https://www.destroyallsoftware.com/talks/wat
>
> Can't view, needs flash. :(
At the bottom of the page is a link to a .mov version. If you can't
play .mov files either, contact me off list.
> Try this instead (NFSW): https://www.youtube.com/watch?v=FJ7QsEytQq4
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
Rustom Mody wrote: > The other day I was taking a class in which I was showing > - introspection for discovering -- help, type, dir etc at the repl > - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b) > > And a student asked me the diff between > dir([]) > and > [].__dir__() > > I didnt know what to say... Surely the right answer would have been "I don't know, let's check the interactive interpreter first, and the docs second." Checking the REPL first would have revealed that [].__dir__ raises AttributeError. In other words, lists don't have a __dir__ method. Checking the docs would then have revealed that __dir__ is only required when a class wishes to customise the output of dir(). Or at least, that's what I recall them saying. I'm too lazy to look it up :-) Oh very well, because it's you... https://docs.python.org/2/library/functions.html#dir Note that there are two inaccuracies in the documentation for __dir__: [quote] If the object has a method named __dir__(), this method will be called and must return the list of attributes. [end quote] The first inaccuracy is that like all (nearly all?) dunder methods, Python only looks for __dir__ on the class, not the instance itself. Hence: py> class K(object): ... def __dir__(self): ... return ["eggs", "spam"] ... py> k = K() py> from types import MethodType py> k.__dir__ = MethodType(lambda self: ["cheese", "spam"], k) py> dir(k) ['eggs', 'spam'] Well, actually that's only true for new-style classes. For old-style classic classes (Python 2 only), it will work on the instance as well. That is, in Python 2 only, if I had left out the "object" base class, dir(k) would have returned ["cheese", "spam"]. Now that I have confused your students, we shall never mention classic classes again (until next time). The second inaccuracy is that method should not return the attributes themselves, but their names. > Now surely the amount of python I dont know is significantly larger than > what I know Still it would be nice to have surface-syntax ←→ dunder-magic > more systematically documented Each function or operator is unique. However, there are certain general behaviours that typically hold. Dunder methods are only looked up on the class, not the instance. (Except for classic classes, if there are any exceptions to this rule, it is probably a bug.) So the correct analog of surface syntax `obj + spam` is *not* `obj.__add__(spam)` but actually: type(obj).__add__(spam) Similar for other operators and functions. In the case of dir, the comparison should be: dir([]) versus type([]).__dir__() Except of course dir doesn't require there to be a __dir__ method. len tries to call __len__ if it exists, and if not, it tries walking the iterable counting items. bool tries calling __bool__ (Python 3) or __nonzero__ (Python 2), if it exists. If not, it tries returning len(obj) != 0. If that fails, objects are true by default. In the case of operators, operator syntax `x $ y` for some operator $ will generally do something like this: X = type(x) Y = type(y) if issubclass(Y, X): # Try the reflected version first, if it exists. dunder = getattr(Y, "__rdunder__", None) if dunder: result = dunder(y, x) if result is not NotImplemented: return result # Or the non-reflected version second. dunder = getattr(X, "__dunder__", None) if dunder: result = dunder(x, y) if result is not NotImplemented: return result else: # Like the above, except we check the non-reflected # version first, and the reflected version second. ... raise TypeError Some methods are their own reflection, e.g. __eq__. In the special case of __eq__ and __ne__, if the class defines one method but not the other, recent versions of Python will automatically call the other method and return its boolean not. Unary operators obviously have no concept of a reflected version. Comparison operators prefer to call the rich comparison methods but may fall back on the older __cmp__ dunder method (Python 2 only). -- Steven -- https://mail.python.org/mailman/listinfo/python-list
pydoc3.5 borks on my Mac
I build several versions of Python from Mercurial sources on a regular basis. I am starting on a new collection of programs for some database work and figured I should start using Python 3. I wanted to look something up quickly about the sqlite3 module, so I tried "pydoc sqlite3". That worked fine, but I figured it was probably using Python 2.x. In fact, it was using Python 2.6. So, I found all my pydoc-ish commands: % like pydoc /Users/skip/local/bin/pydoc /Users/skip/local/bin/pydoc3 /Users/skip/local/bin/pydoc3.2 /Users/skip/local/bin/pydoc3.3 /Users/skip/local/bin/pydoc3.4 /Users/skip/local/bin/pydoc3.5 /usr/bin/pydoc /usr/bin/pydoc2.6 /usr/bin/pydoc2.7 /usr/local/bin/pydoc3 /usr/local/bin/pydoc3.4 and tried pydoc3.5. That didn't work so well: % pydoc3.5 sqlite3 Traceback (most recent call last): File "/Users/skip/local/bin/pydoc3.5", line 5, in pydoc.cli() File "/Users/skip/local/lib/python3.5/pydoc.py", line 2591, in cli help.help(arg) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1874, in help elif request: doc(request, 'Help on %s:', output=self._output) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1612, in doc pager(render_doc(thing, title, forceload)) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1412, in pager pager(text) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1434, in return lambda text: pipepager(text, 'less') File "/Users/skip/local/lib/python3.5/pydoc.py", line 1455, in pipepager pipe.write(text) UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 600: ordinal not in range(128) I don't have PAGER or LANG set, but if I do, I get basically the same error: % LANG=en_US.utf8 PAGER=less pydoc3.5 sqlite3 Traceback (most recent call last): File "/Users/skip/local/bin/pydoc3.5", line 5, in pydoc.cli() File "/Users/skip/local/lib/python3.5/pydoc.py", line 2591, in cli help.help(arg) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1874, in help elif request: doc(request, 'Help on %s:', output=self._output) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1612, in doc pager(render_doc(thing, title, forceload)) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1412, in pager pager(text) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1428, in return lambda text: pipepager(text, os.environ['PAGER']) File "/Users/skip/local/lib/python3.5/pydoc.py", line 1455, in pipepager pipe.write(text) UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 600: ordinal not in range(128) I get the same thing from a python3.5 prompt using "import sqlite3 ; help(sqlite3)". Not having any idea what was in position 600, I tried getting help for each element in dir(sqlite3). That failed as well, though it appeared for some strange reason to crap out on help(sqlite3.dbapi2.__name__). Any idea how I can track down this character so I can report a proper bug? Thx, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: CSV and number formats
On Sun, Feb 1, 2015 at 12:45 AM, Frank Millman wrote:
> Is this a recognised format, and is there a standard way of parsing it? If
> not, I will have to special-case it, but I would prefer to avoid that if
> possible.
Doesn't look "standard" to me in any fashion. You shouldn't need to
special case it though, just
s = re.sub("^[+]0*", "", s)
e.g.,
>>> s = '+0-21.45'
>>> t = '+021.45'
>>> re.sub("^[+]0*", "", s)
'-21.45'
>>> re.sub("^[+]0*", "", t)
'21.45'
That should work on all numbers, not just the weird one. Unless you
have bazillions of numbers, it shouldn't be a performance hit either.
Skip
--
https://mail.python.org/mailman/listinfo/python-list
Re: parsing tree from excel sheet
alb wrote: >> But wait, "".join() only accepts strings so let's change >> >>yield [node] >> >> to >>yield [node.name] # str(node) would also work > > Again my question, why not simply yield node.name? I've been conditioned to build a string from many substrings like so >>> parts = ["foo", "bar", "baz"] >>> text = "".join(parts) >>> text 'foobarbaz' instead of >>> text = "" >>> for part in parts: ... text += part ... >>> text 'foobarbaz' mostly because ""join(...) was initially advertised as being faster than +=. For nested generators or functions this translates into >>> def outer_list(): ... return ["foo"] + inner_list() ... >>> def inner_list(): ... return ["bar"] ... >>> "".join(outer_list()) 'foobar' instead of the obvious >>> def outer(): ... return "foo" + inner() ... >>> def inner(): ... return "bar" ... >>> outer() 'foobar' Here the list-based approach may build many intermediate throwaway-lists, so it's most likely less efficient than direct string concatenation. In return it gives you flexibility: >>> "/".join(outer_list()) 'foo/bar' >>> "-->".join(outer_list()) 'foo-->bar' You'd have to pass the separator as an argument to outer/inner() to achieve this with the seemingly simpler approach. But there's more: You can reverse the order, >>> ":".join(reversed(outer_list())) 'bar:foo' treat the innermost string differently, translate each part into a different language, clip common levels, etc. Your options are unlimited. I never understood why the file system API operates on a single string... -- https://mail.python.org/mailman/listinfo/python-list
Re: CSV and number formats
On 01/31/2015 11:23 PM, Mark Lawrence wrote:
> On 01/02/2015 06:45, Frank Millman wrote:
>>
>>
>> Most transaction amounts are in the format '-0031.23' or '+0024.58'
>>
>> This can easily be parsed using decimal.Decimal().
>>
>> If the opening balance is positive, it appears as '+0021.45'
>>
>> If it is negative, it appears as '+0-21.45'
1) I have never seen that format before.
2) Regular transactions (non-opening balance) appear normally.
3) That's a bug!
4) Easiest workaround is probably to lstrip('+0').
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
> Paul Rubin :
>
>> Marko Rauhamaa writes:
>>> Stroustrup apparently has never had to deal with callbacks; his thick
>>> books never made a mention of them last time I checked.
>>
>> C++ has function pointers just like C,
>
> Et tu, Brute!
>
> C's callbacks always use a void pointer for the "self reference." In C,
> I can use void pointers and type casts idiomatically. In C++, type casts
> are apostasy.
>
> Qt gave up on C++ when it comes to callbacks ("signals") and went for an
> apocryphal metacompiler.
Yes, but only because C++ compilers were not good enough when QT came
out, and later is was too late to change it to a templated system.
Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
for a reasoning of QT.
In C++11 (supported by MSVC, g++, clang) there re also lambda expressions
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: dunder-docs (was Python is DOOMED! Again!)
On 01/31/2015 09:36 PM, Rustom Mody wrote: > > And a student asked me the diff between > dir([]) > and > [].__dir__() > > I didnt know what to say... > Now surely the amount of python I dont know is significantly larger than what > I know > Still it would be nice to have surface-syntax ←→ dunder-magic more > systematically documented I don't have a complete answer for you, but I can say this: In simple cases (such as __len__) there is little difference between calling the surface operator and the dunder version (the error message differs in this case). In more complex cases (such as __add__) using the surface syntax (+) buys lots of extras: - if one operand is a subclass of the other, calling its __add__ or __radd__ method as appropriate - if the first operand returns NotImplemented, calling the other operand's __radd__ to see if that works - possibly others that I don't recall at the moment Basically, unless you're programming at the system (or class internals) level, don't call dunder methods directly. -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Paul Rubin :
> Marko Rauhamaa writes:
>> Stroustrup apparently has never had to deal with callbacks; his thick
>> books never made a mention of them last time I checked.
>
> C++ has function pointers just like C,
Et tu, Brute!
C's callbacks always use a void pointer for the "self reference." In C,
I can use void pointers and type casts idiomatically. In C++, type casts
are apostasy.
Qt gave up on C++ when it comes to callbacks ("signals") and went for an
apocryphal metacompiler.
> but more idiomatically you'd pass a class instance and the library
> would invoke some method on it.
Yes, that's what I ended up doing, defining a class for each callback
type:
struct ButtonPushListener {
virtual void buttonPush(int x, int y) = 0;
};
(Yes, "struct" and not "class"! Why?)
Typing all of that in was quite a chore. All because Stroustrup didn't
think of delegates (Delphi, C#, Python). C++'s method pointers are
ridiculous and useless, they should have been defined as delegates.
> There is also Boost::Coroutine which can get rid of the need for
> callbacks in some situations.
Boost is the world's biggest fig leaf.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
