Is there an archive of this list with permanent URLs to each message?
Hello! When I wrote Fluent Python a few years ago I provided my readers with hundreds of links to my sources, including several links to messages in the python-list archive. Now as I prepare the 2nd edition I notice all my links to this list are broken. Apparently mailman rebuilds the archives and changes the ids of the messages. Is there an archive of python-list that preserves each message with a permanent URL? Thanks! Luciano PS. For the curious, here is an instance of the problem. The message currently at: https://mail.python.org/pipermail/python-list/2009-February/525280.html Used to be at this URL: https://mail.python.org/pipermail/python-list/2009-February/538048.html -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there an archive of this list with permanent URLs to each message?
On Tue, Jun 18, 2019 at 12:27 PM jkn wrote: > A second edition? Curses, just after I recently bought a copy of the first > edition ;-o ... > > (It's a very good book BTW - thanks!) Thanks, J! The 2nd edition won't be available until Q1 2020 at the earliest. Dave Beazley once told me that Fluent Python was very forward looking, so the 1st edition is still very relevant IMHO. The examples that broke are the ones using asyncio, which was provisional at the time and had significant API changes (aiohttp, used in several examples, had even more breaking changes). Besides the asyncio breakage, there are a few better ways of doing things. And I will cover typing. Cheers, Luciano -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: numpy array - convert hex to int
>>> int('C0FFEE', 16)
12648430
There you go!
On Sun, Sep 8, 2019 at 12:02 PM Sharan Basappa wrote:
>
> I have a numpy array that has data in the form of hex.
> I would like to convert that into decimal/integer.
> Need suggestions please.
> --
> https://mail.python.org/mailman/listinfo/python-list
--
Luciano Ramalho
| Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
| Technical Principal at ThoughtWorks
| Twitter: @ramalhoorg
--
https://mail.python.org/mailman/listinfo/python-list
Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?
Take a look at this, Christian: https://github.com/lihaoyi/macropy Best, Luciano On Sun, Sep 15, 2019 at 12:17 PM Christian Seberino wrote: > > > > I had to read this twice. It confused the hell out of me. > > Lol. Certainly didn't mean to be confusing! Hy bring Lisp to Python. I was > more interested in making a Lisp that had trivial similarities to Python like > using some of the same keywords. > > A related interested of mine is converting Python source code to Clojure > source. Imagine instead compiling Python source to an intermediate Lisp > flavor that was closer to Python. Then, later converting that "Pythonic > Lisp" to Clojure later. That "Pythonic Lisp" is what I was thinking about. > > Cheers, > > Chris > > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: OOP - how to abort an __init__ when the initialisation code fails ?
Sorry, I responded only to the OP. My response: """A failed __init__ should raise an appropriate exception. A bare return or returning None is what any __init__ is expected to do in the normal case, so it signals success.""" Actually, the Python interpreter *does* check the return of __init__. If it is anything other than None, Python 3 raises TypeError when you try to create an instance: >>> class X: ...def __init__(self): ...return 1 ... >>> x = X() Traceback (most recent call last): File "", line 1, in TypeError: __init__() should return None, not 'int' Cheers, Luciano On Mon, Nov 4, 2019 at 2:31 PM Rob Gaddi wrote: > > On 11/4/19 7:32 AM, R.Wieser wrote: > > Hello all, > > > > The whole question: How should I handle failed initialisation code inside > > the __init__ of an object ? > > > > I've seen an example doing a plain "return" (of the value "none""), but have > > no idea if that is all it takes. > > > > Also, I wonder what happens to the object itself. Does it still exist and > > only gets actually destroyed at the next garbage-collection (because of a > > zero reference count), or is it directly discarded (without having called > > the __del__ method) ? > > > > Regards, > > Rudy Wieser > > > > > > Raise an exception. Returning None will specifically NOT accomplish the thing > you want; nothing ever checks the return value of __init__. > > -- > Rob Gaddi, Highland Technology -- www.highlandtechnology.com > Email address domain is currently out of order. See above to fix. > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: OOP - how to abort an __init__ when the initialisation code fails ?
On Mon, Nov 4, 2019 at 5:52 PM R.Wieser wrote: > I was thinking of (the needed) wrapping of the "newObject = classObject()" > line in such a try..except block (to capture the re-casted exception). I > take it that that that means that the full contents of the __init__ block > are wrapped too. Python is not Java (also the title of a great post, look for it). In this context, what I mean by that quote is to say that Python never forces you to wrap anything in try/except blocks. Sometimes there is nothing your program can do to fix the issue, so let the exception run its course and terminate the program. The only reason to catch an exception prior to aborting is to provide a better error message, or log something. But in many situations aborting with a traceback is good enough, and it costs 0. In addition, as Rob said, it is usually a bad idea to wrap several lines of code in a single try/except block, because that makes it difficult to be specific when handling the different exceptions that may happen. You should strive to be as specific as possible in the exceptions that you choose to handle, and that pretty much requires wrapping few (often just one) line of code in a try/except block. > > or b) your except condition is too broad. Don't "except Exception". Only > > catch specific exceptions where you can provide benefit by doing do. > > And that means I have to study the "try ... except" methodology a bit more, > as I've currently got only a fleeting knowledge to how it works (including > which error classes it can selectivily catch/filter). Yes, you totally should learn how try/except works in Python, and also learn a bit of Python culture, "the way we do things around here" ;-). It is considered totally OK to use exception handling as a control flow mechanism in Python. The interpreter and the standard library have many examples of exceptions that do not signal errors, but merely that something happened. For example, at a low level, Python iterators/generators (pretty much synonyms around here) raise StopIteration to signal the iterating for loop that there are no more items. So the for statement implementation swallows StopIteration and cleanly ends the loop. Another example: the built-in function hasattr(obj, name) is actually implemented (in C) by calling getattr(obj, name) and returning True if no exception is raised, or False if AttributeError is raised. That is common Python style. Cheers, Luciano > > Regards, > Rudy Wieser > > > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: psutil.boot_time() ... doesn't ?
On Wed, Nov 6, 2019 at 7:54 PM Terry Reedy wrote: > I don't know how much Linux is customized for RP, but last I knew, > Python on RP is MicroPython, not CPython. So I expect OS-related > functions to not necessarily match Linux on a desktop. The default OS on all Raspberry Pi models is Raspbian, a full-blown Debian Linux derivative, which comes with Python 2 and Python 3 installed -- CPython, to be clear. MicroPython was designed for microcontroller boards that are too small to run an OS. Popular boards are the BBC microbit and ESP8266. Those devices don't run Linux. To use MicroPython on them, you install firmware that boots directly into the MicroPython runtime, which includes a REPL. Cheers, Luciano > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: How to delay until a next increment of time occurs ?
Mr. Wieser, I haven't seen you mention which library you're using to write to GPIO with Python. I know of two options: 1) RPi.GPIO: https://sourceforge.net/projects/raspberry-gpio-python/ -- the more popular option 2) WiringPy: https://github.com/WiringPi/WiringPi-Python -- an alternative with better performance See (7 year old) benchmarks here: https://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ WiringPy has it's own delay function, which may have better performance than using any Python alternative. See an example here: https://github.com/WiringPi/WiringPi-Python/blob/master/examples/softpwm.py RPi.GPIO has dedicated PWM functions, which may or may not solve your problem. See docs here: https://sourceforge.net/p/raspberry-gpio-python/wiki/PWM/ Cheers, Luciano On Wed, Nov 13, 2019 at 3:27 PM R.Wieser wrote: > > Dennis, > > > So... you need to adjust for the time spent in processing between > > calls to sleep(). > > That was my first thought too, but any code calculating that adjustment > before ultimatily calling sleep itself can also be interrupted.With that > in mind I was aiming/hoping for something with a /very/ short path between > the calculation and executing the sleep (as in: none at all, done by the > system itself). > > > The creep could be mitigated some by having the handler's first > > action being to start the next timer instance, and then doing "stuff". > > Yup. But the cost of using that command is generating threads - which some > search results warned against (not sure why though). > > The best solution I can think of would be a build-in (hardware?) timer which > would generate "ticks" until its stopped. > > Regards, > Rudy Wieser > > > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: nonlocal fails ?
Re: the whole pass by reference discussion. I've seen Python's argument passing described as "call by value, except that all values are references". This makes sense, but is confusing. Michael Scott, in his textbook Programming Language Pragmatics (4e) terms the Python way "call by sharing". That is the same mode used in most OO languages that don't have pointers, including Ruby, SmallTalk, and Java (this applies to Java reference types; primitive types use call by value). Call by sharing means that each formal parameter of the function gets a copy of each reference in the arguments. Cheers, Luciano On Fri, Nov 15, 2019 at 3:58 PM Dennis Lee Bieber wrote: > > On Fri, 15 Nov 2019 11:54:50 -0500, Richard Damon > declaimed the following: > > > > >I remember in early FORTRAN being able to do something like this (its > >been years since I have done this so syntax is probably a bit off) > > > > > > > >foo(1) > > > >and after that if you did > > > >j = 1 > > > >then now j might have the value 2 as the constant 1 was changed to the > >value 2 (this can cause great confusion) > > > > It was a very early FORTRAN that did that, since literals were stored > in general R/W memory and the address was passed. Later FORTRAN compilers > would flag a section of memory for R/O and stored literals in that section > -- so attempts at modification would result in an error. > > >later I believe they added the ability to specify by value and by > >reference, and you weren't allowed to pass constants by reference, > > Many compilers added extensions for interfacing to other languages > (DEC > is famous for %val(), %ref(), %descr() for controlling parameters, and > %loc() external to parameters. %ref wasn't really useful in FORTRAN since > that is the native method. %loc returned the address of the target item. > %descr was a weird one -- things like character strings were passed by > descriptor: first word was the address [standard reference model], second > word encapsulated information like the length allocated to the string [not > the length used, but the size of the memory allocation]. > > Literals were still passed by reference -- just to read-only memory > block. Otherwise the called function wouldn't know how to behave! > > subroutine xyz(parm) > integer parm > > ... > > call xyz(1) > call xyz(abc) > > if the first was passed by value and the second by reference, what was > "parm" in the called function to do > > > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ > > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
Now that’s a novel approach to asking for free help: pretending to be
smarter than the people who are trying to help you.
On Tue, 19 Nov 2019 at 14:17 R.Wieser wrote:
> Michael,
>
> > Sure but the Python methods* themselves are exposed and accessible
> > and according to your previous posts, all you want to do is add an
> > argument to a call to the existing method. If that's true, then you
> > should be able to do that part from pure Python.
>
> >* class methods defined by the C code
>
> Feel free to post code showing that it can be done. The extension is
> RPi.GPIO, the method is "output", and the extra argument is the pinnaming
> scheme (BCM or BOARD). Success! :-p
>
> > I can understand that the pure C stuff is not accessible of course.
> > But the snippets you've shown so far don't show any of that.
>
> Where did you think that "static PyObject *py_proc1(PyObject *self,
> PyObject
> *args)" came from, or why I said "I've also tried to go the C way" ?
> Besides that, the subject line should have been a dead giveaway by
> itself ...
>
> > We're working in the dark here
>
> Are you sure ? MRAB didn't seem to have too much problems with both
> recognising and understanding what I was busy with - he posted a spot-on
> example, containing not more, but also not anything less than what I was
> asking for.
>
> > Looking at existing examples, as well as the C API documentation
>
> I did not find any example that showed me what I needed to know - simply
> one
> CPython function calling another one.And yes, I've found multiple
> documentation pages, including the "Extending and Embedding the Python
> Interpreter" ones. Alas, no dice.
>
> Most of that documentation is only good when you already know what you are
> looking for, and need to make sure of its exact usage. Not so much the
> other way around, when you have no clue and are searching for what you need
> to use to solve a particular problem (even one as stupid as just calling
> another method)
>
>
> By the way, the whole solution consists outof the following:
>
> static PyObject *py_proc1(PyObject *self, int ExtraArg, PyObject *args)
> {
> ....
> Py_RETURN_NONE
> }
>
> static PyObject *py_proc2(PyObject *self, PyObject *args)
> {
>return py_proc1(self, 42, args)
> }
>
> Regards,
> Rudy Wieser
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
Luciano Ramalho
| Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
| Technical Principal at ThoughtWorks
| Twitter: @ramalhoorg
--
https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
I apologize to all but the intended recipient for this. I’d have given him
feedback in private if I knew his email.
I will take leave from the list now. Keep up the good work, friendly
responders.
On Tue, 19 Nov 2019 at 17:13 Luciano Ramalho wrote:
> Now that’s a novel approach to asking for free help: pretending to be
> smarter than the people who are trying to help you.
>
> On Tue, 19 Nov 2019 at 14:17 R.Wieser wrote:
>
>> Michael,
>>
>> > Sure but the Python methods* themselves are exposed and accessible
>> > and according to your previous posts, all you want to do is add an
>> > argument to a call to the existing method. If that's true, then you
>> > should be able to do that part from pure Python.
>>
>> >* class methods defined by the C code
>>
>> Feel free to post code showing that it can be done. The extension is
>> RPi.GPIO, the method is "output", and the extra argument is the pinnaming
>> scheme (BCM or BOARD). Success! :-p
>>
>> > I can understand that the pure C stuff is not accessible of course.
>> > But the snippets you've shown so far don't show any of that.
>>
>> Where did you think that "static PyObject *py_proc1(PyObject *self,
>> PyObject
>> *args)" came from, or why I said "I've also tried to go the C way" ?
>> Besides that, the subject line should have been a dead giveaway by
>> itself ...
>>
>> > We're working in the dark here
>>
>> Are you sure ? MRAB didn't seem to have too much problems with both
>> recognising and understanding what I was busy with - he posted a spot-on
>> example, containing not more, but also not anything less than what I was
>> asking for.
>>
>> > Looking at existing examples, as well as the C API documentation
>>
>> I did not find any example that showed me what I needed to know - simply
>> one
>> CPython function calling another one.And yes, I've found multiple
>> documentation pages, including the "Extending and Embedding the Python
>> Interpreter" ones. Alas, no dice.
>>
>> Most of that documentation is only good when you already know what you are
>> looking for, and need to make sure of its exact usage. Not so much the
>> other way around, when you have no clue and are searching for what you
>> need
>> to use to solve a particular problem (even one as stupid as just calling
>> another method)
>>
>>
>> By the way, the whole solution consists outof the following:
>>
>> static PyObject *py_proc1(PyObject *self, int ExtraArg, PyObject *args)
>> {
>>
>> Py_RETURN_NONE
>> }
>>
>> static PyObject *py_proc2(PyObject *self, PyObject *args)
>> {
>>return py_proc1(self, 42, args)
>> }
>>
>> Regards,
>> Rudy Wieser
>>
>>
>>
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
> --
> Luciano Ramalho
> | Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> | Technical Principal at ThoughtWorks
> | Twitter: @ramalhoorg
>
--
Luciano Ramalho
| Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
| Technical Principal at ThoughtWorks
| Twitter: @ramalhoorg
--
https://mail.python.org/mailman/listinfo/python-list
Coercing two numbers without coerce()
Python 3 dropped the coerce() built-in, but I have a situation where I'd love to use it. I have two numbers A, B and I need to get the value of A coerced to the type of A+B. This is for a generator function that will produce a series similar to what itertools.count does. I know I can do type(A+B)(A), or A+B-B, but both alternatives are ugly and perform needless arithmetic. What do you suggest, now that the coerce() built-in is not available? Cheers, Luciano -- Luciano Ramalho Twitter: @ramalhoorg Professor em: http://python.pro.br Twitter: @pythonprobr -- https://mail.python.org/mailman/listinfo/python-list
Re: zip files as nested modules?
Importing modules from zip files was proposed in PEP-273 [1] Here is how the spec of PEP-273 begins: ''' Currently, sys.path is a list of directory names as strings. If this PEP is implemented, an item of sys.path can be a string naming a zip file archive. ''' My interpretation of the above is that, to be importable, a zip file must be explicitly named in sys.path. So the mere fact that a zip file lies somewhere in a directory which is part of the sys.path does not make it importable. Cheers, Luciano [1] http://www.python.org/dev/peps/pep-0273/ -- http://mail.python.org/mailman/listinfo/python-list
