On 12/17/18 5:20 PM, Brian Christiansen wrote:
I don't know if this follow up to my original message will even be seen
because of all the spam advertising e-books that at least from the
titles appear to have nothing to do with python.
I apologize for being overly wordy in my description, but I
On Tue, Dec 18, 2018 at 12:26 PM Brian Christiansen
wrote:
>
> I don't know if this follow up to my original message will even be seen
> because of all the spam advertising e-books that at least from the
> titles appear to have nothing to do with python.
It's easy enough to see the important info
I don't know if this follow up to my original message will even be seen
because of all the spam advertising e-books that at least from the
titles appear to have nothing to do with python.
I apologize for being overly wordy in my description, but I suppose I
was worried that if I did not go int
On Tue, Dec 18, 2018 at 9:12 AM eryk sun wrote:
> Objects are heap allocated and use reference counting in CPython (i.e.
> Python implemented in C). A scope reference in CPython could be a fast
> (function) local that's internal to a frame object; a cell object
> that's used to share variables in
On 12/17/18, Rob Gaddi wrote:
>
> Python's objects all have a lifespan dictated by the continued existence
> of references to them and thus can transcend the lifetime of the current
> function in ways not known at translation time. So am I right in
> thinking that all Python objects are out on th
On Tue, Dec 18, 2018 at 6:36 AM Rob Gaddi
wrote:
>
> I've been writing Python for good long while now without thinking too
> hard about this, but I just had a realization this weekend.
>
> Back when the earth's crust was still cooling and we all rode dinosaurs
> to our jobs, local variables got al
I've been writing Python for good long while now without thinking too
hard about this, but I just had a realization this weekend.
Back when the earth's crust was still cooling and we all rode dinosaurs
to our jobs, local variables got allocated onto the stack, and dynamic
memory from malloc or
When Python looks up an attribute on an object (i.e. when it executes
`o.a`), it uses an interesting priority order [1]. It looks for:
1. A class attribute that is a data-descriptor (most commonly a property)
2. An instance attribute
3. Any other class attribute
We can confirm this using the c
argparse works fine on 3.x
https://docs.python.org/3.6/library/argparse.html
You can't really have back to back _positional_ arguments with nargs = "+" as
it won't be able to tell where you meant one group to end and the next to
begin. You'd have to call it with switches like
script.py -if inFi
My script is used by a web interface which gets some parameters from a form.
The parameters are passed on as arguments like this:
(...)
def start(self, _Inputfile ,_Outputfile ,_Stopwordsfile)
As long as the number of arguments is set (i.e. 3), there are no problems
running the script.
Currentl
Neal Becker wrote:
> I find pickle really handy for saving results from my (simulation)
> experiments. But recently I realized there is an issue. Reading the
> saved results requires loading the pickle, which in turn will load any
> referenced
> modules. Problem is, what if the modules have cha
This can definitely be a problem, but there are tried and true strategies to
deal with it and the best course of action depends a lot on what works for you.
Pickle deserialization is just an API instantiating your class instances. That
means all the same rules and approaches to API changes apply
I find pickle really handy for saving results from my (simulation)
experiments. But recently I realized there is an issue. Reading the saved
results requires loading the pickle, which in turn will load any referenced
modules. Problem is, what if the modules have changed?
For example, I just
13 matches
Mail list logo
