Re: can't add variables to instances of built-in classes
breamore...@gmail.com wrote: > I hereby request that the moderators take this idiot offline as he's Mark, please behave yourself. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python packages listed in PyPI
"I don't understand what difference you intend between “implementations” and “packages”." I meant whether the package is self-contained, that is, all the different implementations for different OS and versions of Python are already contained in the package itself. But you've already answered my question that additional downloads of the correct version for specific OS and Python version is required. -- https://mail.python.org/mailman/listinfo/python-list
Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]
Rustom Mody :
> The field of numerical analysis came into existence only because this
> fact multiplied by the fact that computers do their (inaccurate ≠
> inexact) computations billions of times faster than we do makes
> significance a very significant problem!
A couple of related anecdotes involving integer errors.
1. I worked on a (video) product that had to execute a piece of code
every 7 µs or so. A key requirement was that the beat must not drift
far apart from the ideal over time. At first I thought the
traditional nanosecond resolution would be sufficient for the purpose
but then made a calculation:
maximum rounding error = 0.5 ns/7 µs
= 70 µs/s
= 6 s/day
That's why I decided to calculate the interval down to a femtosecond,
whose error was well within our tolerance.
2. After running the LXDE GUI on my 32-bit Linux environment for some
time, the CPU utilization monitor showed the CPU was mysteriously
doing work 100% of the time. The only way out was to reboot the
machine.
After a few months and a few reboots, I investigated the situation
more carefully. It turned out LXDE's CPU meter was reading jiffy
counts from a textual /proc file with scanf("%ld"). Jiffies start
from 0 at the time of the boot and increment every millisecond. Thus,
the maximum signed 32-bit integer is reached in less than 25 days.
When scanf("%ld") overflows, it sets the value to MAX_LONG. That
effectively meant time stopped going forward and all rate
calculations would shoot through the roof. This problem would not
have occurred if the C standard consistently specified modulo
arithmetics for integer operations.
The solution was to use scanf("%lld") instead.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]
On Thu, Jul 21, 2016 at 5:52 PM, Marko Rauhamaa wrote: > A couple of related anecdotes involving integer errors. > > 1. I worked on a (video) product that had to execute a piece of code >every 7 µs or so. A key requirement was that the beat must not drift >far apart from the ideal over time. At first I thought the >traditional nanosecond resolution would be sufficient for the purpose >but then made a calculation: > > maximum rounding error = 0.5 ns/7 µs >= 70 µs/s >= 6 s/day > >That's why I decided to calculate the interval down to a femtosecond, >whose error was well within our tolerance. I'd be curious to know whether, had you used nanosecond resolution, you ever would have seen anything like that +/- 6s/day error. One convenient attribute of the real world [1] is that, unless there's a good reason for it to do otherwise [2], random error will tend to cancel out rather than accumulate. With error of +/- 0.5 ns, assume (for the sake of argument) that the actual error at each measurement is random.choice((-0.4, -0.3, -0.2, -0.1, 0.1, 0.2, 0.3, 0.4)) ns, with zero and the extremes omitted to make the calculations simpler. In roughly twelve billion randomizations (86400 seconds divided by 7µs), the chances of having more than one billion more positive than negative are... uhh actually, I don't know how to calculate probabilities off numbers that big, but pretty tiny. So you're going to have at least 5.5 billion negatives to offset your positives (or positives to offset your negatives, same diff); more likely they'll be even closer. So if you have (say) 5.5 to 6.5 ratio of signs, what you're actually working with is half a second per day of accumulated error - and I think you'd have a pretty tiny probability of even *that* extreme a result. If it's more like 5.9 to 6.1, you'd have 0.1 seconds per day of error, at most. Plus, the same probabilistic calculation can be done for days across a month, so even though the theory would let you drift by three minutes a month, the chances of shifting by even an entire second over that time are fairly slim. This is something where I'd be more worried about systematic bias in the code than anything from measurement or rounding error. (I don't believe I've ever actually used a computer that's capable of nanosecond-accurate time calculations. Generally they return time in nanoseconds for consistency, but they won't return successive integer values. You must have been on some seriously high-end hardware - although that doesn't surprise me much, given that you were working on a video product.) ChrisA [1] Believe you me, it has no shortage of INconvenient attributes, so it's nice to have one swing the balance back a bit! [2] If there's systematic error - if your 7 µs is actually averaging 7.25 µs - you need to deal with that separately. -- https://mail.python.org/mailman/listinfo/python-list
Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]
Chris Angelico : > On Thu, Jul 21, 2016 at 5:52 PM, Marko Rauhamaa wrote: >> A couple of related anecdotes involving integer errors. >> >> 1. I worked on a (video) product that had to execute a piece of code >>every 7 µs or so. A key requirement was that the beat must not drift >>far apart from the ideal over time. At first I thought the >>traditional nanosecond resolution would be sufficient for the purpose >>but then made a calculation: >> >> maximum rounding error = 0.5 ns/7 µs >>= 70 µs/s >>= 6 s/day >> >>That's why I decided to calculate the interval down to a femtosecond, >>whose error was well within our tolerance. > > I'd be curious to know whether, had you used nanosecond resolution, > you ever would have seen anything like that +/- 6s/day error. One > convenient attribute of the real world [1] is that, unless there's a > good reason for it to do otherwise [2], random error will tend to > cancel out rather than accumulate. With error of +/- 0.5 ns, assume > (for the sake of argument) that the actual error at each measurement > is random.choice((-0.4, -0.3, -0.2, -0.1, 0.1, 0.2, 0.3, 0.4)) ns, No, this is a systematic error due to the rounding of a rational number to the nearest nanosecond interval. Systematic errors of this kind are a real thing and not even all that uncommon. > (I don't believe I've ever actually used a computer that's capable of > nanosecond-accurate time calculations. Generally they return time in > nanoseconds for consistency, but they won't return successive integer > values. You must have been on some seriously high-end hardware - > although that doesn't surprise me much, given that you were working on > a video product.) Nanosecond, even femtosecond, calculations are trivially simple integer arithmetics that can be performed with pencil and paper. The hardware was nothing fancy, and the timing error due to various hardware, software and network realities was in the order of ±100 µs. That was tolerable and could be handled through buffering. However, a cumulative error of 6 seconds per day was *not* tolerable. The calculations needed to be extremely simple because the interrupt routine had to execute every 7 microseconds. You had to let the hardware RTC do most of the work and do just a couple of integer operations in the interrupt routine. In particular, you didn't have time to recalculate and reprogram the RTC at every interrupt. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]
On Thursday, July 21, 2016 at 12:04:35 PM UTC+5:30, Steven D'Aprano wrote: > On Thursday 21 July 2016 15:28, Rustom Mody wrote: > > BTW APL whose main domain of application is scientific chooses to enshrine > > this —equality is ε-neighborhood checking not exact equality checking — into > > its builtin ‘==’ > > I have a lot of respect for Ken Iverson, and a lot of admiration for language > designers willing to experiment with alternate paradigms. This choice has significant(!!) costs: Fuzzy equality is not transitive: One can get a = b ∧ b = c ∧ a ≠ c > > But keeping in mind that in APL, if you set ⎕ct to 0 you get an exact > comparison, can you find any quotes from Iverson saying that you should > *never* > perform exact equality comparisons? There you go with your strawmen! Remember it was you (and Chris) who expressed extreme positions: “Pernicious myth” “FUD” etc -- https://mail.python.org/mailman/listinfo/python-list
How to do Integration testing of a C code/firmware in python
I am doing an Internship at a company. I have a multi threaded code/firmware in c. I have done its unit testing with cantata in c++ and now want to do Integration testing in python with the device connected to my PC. From where do I start. How and what to write. The code has various functions with sensor, adc,dac, etc If any more info let me know I am a newbie with no experience so let me know if any mistake -- https://mail.python.org/mailman/listinfo/python-list
Ide or code editor confusion
I'm learning Python and something is really unclear on the chapter im on. So Python has its own IDE to write code but now it's talking about "code editors" My confusion is so I need a code editor like Sublime text? Is that what Python IDE is for? -- https://mail.python.org/mailman/listinfo/python-list
Re: Ide or code editor confusion
On Thu, Jul 21, 2016 at 11:56 PM, wrote: > I'm learning Python and something is really unclear on the chapter im on. > > So Python has its own IDE to write code but now it's talking about "code > editors" > > My confusion is so I need a code editor like Sublime text? Is that what > Python IDE is for? You can use any text editor to write your Python code. If you're using nothing except Python, IDLE is excellent, but if you work with several different languages, you may prefer Sublime, or Atom, or SciTE, or GNU Nano, or something else. You can pick up pretty much any text editor (not a word processor, and not Windows Notepad, but virtually anything else will do) and use that to work on your code. Without knowing what chapter of what book you're reading, I can't advise any further. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Ide or code editor confusion
Beginning Python: using Python 2.6 and Python 3.1. By James Payne Part II. But I think that answered my question. Great because au was worried -- https://mail.python.org/mailman/listinfo/python-list
Re: Ide or code editor confusion
On 2016-07-21 15:07, Chris Angelico wrote: On Thu, Jul 21, 2016 at 11:56 PM, wrote: I'm learning Python and something is really unclear on the chapter im on. So Python has its own IDE to write code but now it's talking about "code editors" My confusion is so I need a code editor like Sublime text? Is that what Python IDE is for? You can use any text editor to write your Python code. If you're using nothing except Python, IDLE is excellent, but if you work with several different languages, you may prefer Sublime, or Atom, or SciTE, or GNU Nano, or something else. You can pick up pretty much any text editor (not a word processor, and not Windows Notepad, but virtually anything else will do) and use that to work on your code. Without knowing what chapter of what book you're reading, I can't advise any further. The key is that the editor should work with "plain text". A "code editor" is one that works with plain text, but has been designed with programming in mind. It will have useful features such as syntax colouring (different colours for reserved words, strings, ...), case conversion, easy indentation of multiple lines, and so on. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ide or code editor confusion
sigmaphine1...@gmail.com writes: > I'm learning Python and something is really unclear on the chapter im > on. > > So Python has its own IDE to write code but now it's talking about > "code editors" > > My confusion is so I need a code editor like Sublime text? Is that > what Python IDE is for? You need a code editor that you are comfortable with. If you are already comfortable with this IDE thing that you talk about, you can use it as your code editor. You can also use some other editor. If you like. If you are curious. Even one that doesn't know about Python (but those who claim to edit code by moving magnets over the hard disk are only joking. That's not done). -- https://mail.python.org/mailman/listinfo/python-list
Re: Ide or code editor confusion
On Fri, Jul 22, 2016 at 12:22 AM, wrote: > Beginning Python: using Python 2.6 and Python 3.1. By James Payne > > Part II. > > But I think that answered my question. Great because au was worried Ugh, that's extremely old now. The current versions of Python are 2.7 (first released in 2010, and getting periodic bugfix releases) and 3.5 (released 2015, and also getting bugfix releases). I strongly recommend you use a newer version - either 3.4 or 3.5, one of which will be available in most Linux repositories. You can always grab the latest from python.org. If you can't find a book that makes use of 3.4+, ask around; there are quite a few books which have been updated to that. The feature difference between 3.1 and 3.5 is huge. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Technique for safely reloading dynamically generated module
We're designing a server application that parses a custom DSL (domain specific language) source file, generates a Python module with the associated logic, and runs the associated code. Since this is a server application, we need to reload the module after each regeneration. Is this process is simple as the following pseudo code or are there other issues we need to be aware of? Are there better techniques for this workflow (eval, compile, etc)? We're working in Python 3.5.1. import importlib # custom_code is the module our code will generate - a version of this # file will always be present # if custom_code.py is missing, a blank version of this file is created # before this step import custom_code while True: # (re)generates custom_code.py visible in sys.path generate_custom_code( source_file ) # reload the module whose source we just generated importlib.reload( custom_code ) # run the main code in generated module custom_code.go() Thank you, Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: Technique for safely reloading dynamically generated module
On Fri, Jul 22, 2016 at 12:42 AM, Malcolm Greene wrote:
> We're designing a server application that parses a custom DSL (domain
> specific language) source file, generates a Python module with the
> associated logic, and runs the associated code. Since this is a server
> application, we need to reload the module after each regeneration. Is
> this process is simple as the following pseudo code or are there other
> issues we need to be aware of? Are there better techniques for this
> workflow (eval, compile, etc)?
>
> We're working in Python 3.5.1.
>
> import importlib
>
> # custom_code is the module our code will generate - a version of this
> # file will always be present
> # if custom_code.py is missing, a blank version of this file is created
> # before this step
> import custom_code
>
> while True:
> # (re)generates custom_code.py visible in sys.path
>generate_custom_code( source_file )
>
># reload the module whose source we just generated
>importlib.reload( custom_code )
>
># run the main code in generated module
>custom_code.go()
>
I would avoid importlib.reload() if I can. Using compile/eval is
probably more effective; you might need to change how the module gets
organized, but if you already require a go() function, that's probably
enough. Something like this:
while True:
python_code = generate_custom_code(source_file)
ns = {}
exec(python_code, ns)
ns["go"]()
(Presumably your go() function doesn't return until you want to
regenerate the code?)
Personally, what I'd do is have an initializer function, and have that
register the module in whatever way is appropriate (eg some sort of
"handle_request" function). Then the main program runs an event loop,
everything's handled asynchronously, and you can have either a file
system trigger "this file has changed, go and regenerate it" or an
explicit action by the admin to regenerate. But definitely I'd craft
the source code as a string, not writing anything to disk, and exec it
directly; the import machinery is unnecessary here.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python packages listed in PyPI
On 21 July 2016 at 07:28, Rayne wrote: > Thanks! One more question: Does "pip install" require Internet to work? Or > are all implementations already contained in the packages and so do not > require additional downloads? > pip install is downloading from https://pypi.python.org so yes you do need internet access. Having said that there are a couple of ways to feed pip. You can run a local pypi server to host previously downloaded packages or tell pip to install from a file. "pip help install" Automatic handling of additional downloads is automatic in pip. If the package you are installing requires some other packages then it will install those too. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Technique for safely reloading dynamically generated module
Malcolm Greene wrote:
> We're designing a server application that parses a custom DSL (domain
> specific language) source file, generates a Python module with the
> associated logic, and runs the associated code. Since this is a server
> application, we need to reload the module after each regeneration. Is
> this process is simple as the following pseudo code or are there other
> issues we need to be aware of? Are there better techniques for this
> workflow (eval, compile, etc)?
>
> We're working in Python 3.5.1.
>
> import importlib
>
> # custom_code is the module our code will generate - a version of this
> # file will always be present
> # if custom_code.py is missing, a blank version of this file is created
> # before this step
> import custom_code
>
> while True:
> # (re)generates custom_code.py visible in sys.path
>generate_custom_code( source_file )
>
># reload the module whose source we just generated
>importlib.reload( custom_code )
>
># run the main code in generated module
>custom_code.go()
If the go() function in that loop is the only place where the generated
module is used you can avoid writing code to the file system altogether.
Here's a really simple alternative suggestion based on exec():
SOURCEFILE = "whatever.dsl"
def make_func(sourcefile):
ns = {}
exec(generated_code(sourcefile), ns)
return ns["go"]
def generated_code(sourcefile):
# placeholder for your actual source generation
return """
def go():
print("Generated from", {!r})
""".format(sourcefile)
while True:
# XXX should we wait for updates of sourcefile here?
go = make_func(SOURCEFILE)
go()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Technique for safely reloading dynamically generated module
Thank you Chris and Peter. The source file we're generating has one main function (go) with some supporting functions and classes as well. Will there be any problems referencing additional functions or classes defined in the source that gets passed to exec ... as long as references to those functions and classes happen within the generated module? I assume that one downside to the exec() approach is that there is no persistent namespace for this code's functions and classes, eg. after the exec() completes, its namespace disappears and is not available to code that follows? The Python documentation also warns: "Be aware that the return and yield statements may not be used outside of function definitions even within the context of code passed to the exec() function. The return value is None." Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: reversed(enumerate(x))
On Wed, Jul 20, 2016 at 1:16 PM, Random832 wrote: > On Wed, Jul 20, 2016, at 13:42, Ian Kelly wrote: >> I had occasion to write something like this: >> >> for i, n in reversed(enumerate(x)): pass >> >> How would you write this? > > I'd write my own version of enumerate with a step argument, and call > enumerate(reversed(x), start=len(x), step=-1) Makes it a little too easy to commit an off-by-one error, I think. As you did here. -- https://mail.python.org/mailman/listinfo/python-list
Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]
On Thu, 21 Jul 2016 11:14 pm, Rustom Mody wrote: > On Thursday, July 21, 2016 at 12:04:35 PM UTC+5:30, Steven D'Aprano wrote: >> On Thursday 21 July 2016 15:28, Rustom Mody wrote: >> > BTW APL whose main domain of application is scientific chooses to >> > enshrine this —equality is ε-neighborhood checking not exact equality >> > checking — into its builtin ‘==’ >> >> I have a lot of respect for Ken Iverson, and a lot of admiration for >> language designers willing to experiment with alternate paradigms. > > This choice has significant(!!) costs: Fuzzy equality is not transitive: > One can get > a = b ∧ b = c ∧ a ≠ c >> >> But keeping in mind that in APL, if you set ⎕ct to 0 you get an exact >> comparison, can you find any quotes from Iverson saying that you should >> *never* perform exact equality comparisons? > > There you go with your strawmen! > Remember it was you (and Chris) who expressed extreme positions: > “Pernicious myth” “FUD” etc And YOU'RE the one who is raising APL as an argument *against* my characterisation. Do you think that Iverson would agree with the conventional wisdom that we should NEVER test floats for exact equality? Do you know of ANY expert in numeric computation who will agree with the conventional wisdom? If so, who? I'll admit that I've stolen my description of this rule as "superstition" from perhaps the world's foremost authority on numeric computation, Professor William Kahan. (See the forward to "Apple Numerics Manual, Second Edition, 1988.) You don't like my use of the term "pernicious"? In my opinion, any conventional wisdom which keeps people *more* rather than *less* ignorant is pernicious. Anything which discourages them from testing their numeric functions to the full precision possible is pernicious. Anything which encourages the idea that numeric computation using floats is non-deterministic is pernicious. But if you don't agree, feel free to dismiss the word as mere hyperbola and MOVE ON. You don't have to nit pick about every word I use. The bottom line is, while it is often true that using exact equality is going to surprise people, the conventional wisdom to NEVER do so is both (1) factually wrong, there are plenty of examples where one can and should use exact equality, and (2) rather useless, as the conventional wisdom gives no clue as to the practicalities of what to replace it with. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Technique for safely reloading dynamically generated module
On Fri, Jul 22, 2016 at 2:07 AM, Malcolm Greene wrote: > The source file we're generating has one main function (go) with some > supporting functions and classes as well. Will there be any problems > referencing additional functions or classes defined in the source that > gets passed to exec ... as long as references to those functions and > classes happen within the generated module? > > I assume that one downside to the exec() approach is that there is no > persistent namespace for this code's functions and classes, eg. after > the exec() completes, its namespace disappears and is not available to > code that follows? Functions keep references to their globals, so you should be safe. > The Python documentation also warns: "Be aware that the return and yield > statements may not be used outside of function definitions even within > the context of code passed to the exec() function. The return value is > None." Yeah, that's just emphasizing that exec() is looking for module-level code. Just as you can't put a flush-left "return" statement into a .py file, you can't use one in exec(). As long as your code builder is returning a string equivalent to what you'd find in an actual Python module (that is, exactly what it's already doing, given that you currently attempt to import it), you'll be fine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: reversed(enumerate(x))
On Wed, Jul 20, 2016 at 11:54 AM, Brendan Abel <007bren...@gmail.com> wrote: > You could create your own generator that wraps enumerate > > def reverse_enumerate(iterable): > for i, val in enumerate(reversed(iterable)): > yield len(iterable) - 1 - i, val > > for i, val in reverse_enumerate(x): > ... Thanks, I like this. But I think I'll define it as: def reverse_enumerate(sequence): return zip(reversed(range(len(sequence))), reversed(sequence)) To avoid performing the loop in Python. -- https://mail.python.org/mailman/listinfo/python-list
Max size of Python source code and compiled equivalent
We're writing a DSL parser that generates Python code. While the size of our generated code will be small (< 32K), I wanted to re-assure the rest of our team that there are no reasonable code size boundaries that we need to be concerned about. I've searched for Python documentation that covers max Python source (*.py) and compiled file (*.pyc) sizes without success. Any tips on where to look for this information? Background: Python 3.5.1 on Linux. Thank you, Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: Max size of Python source code and compiled equivalent
On Fri, Jul 22, 2016 at 2:51 AM, Malcolm Greene wrote: > We're writing a DSL parser that generates Python code. While the size of > our generated code will be small (< 32K), I wanted to re-assure the rest > of our team that there are no reasonable code size boundaries that we > need to be concerned about. I've searched for Python documentation that > covers max Python source (*.py) and compiled file (*.pyc) sizes without > success. Any tips on where to look for this information? Heh, great question, and I'm curious too! But one place to get a bit more info is the standard library. rosuav@sikorsky:~/cpython/Lib$ find -name \*.py|xargs ls -lS|head -rw-r--r-- 1 rosuav rosuav 624122 Jul 17 17:38 ./pydoc_data/topics.py -rw-r--r-- 1 rosuav rosuav 229348 Jun 15 23:20 ./_pydecimal.py -rw-r--r-- 1 rosuav rosuav 210900 Jul 21 22:41 ./test/test_decimal.py -rw-r--r-- 1 rosuav rosuav 205399 Jun 15 23:20 ./test/test_email/test_email.py -rw-r--r-- 1 rosuav rosuav 203297 Jun 23 13:22 ./test/test_socket.py -rw-r--r-- 1 rosuav rosuav 183195 Jul 17 17:38 ./test/test_descr.py -rw-r--r-- 1 rosuav rosuav 166684 Jun 29 16:26 ./tkinter/__init__.py -rw-r--r-- 1 rosuav rosuav 164583 Jun 15 23:20 ./test/test_argparse.py -rw-r--r-- 1 rosuav rosuav 162603 Jun 15 23:20 ./test/test_buffer.py -rw-r--r-- 1 rosuav rosuav 159528 Jun 15 23:20 ./test/datetimetester.py rosuav@sikorsky:~/cpython/Lib$ find -name \*.pyc|xargs ls -lS|head -rw-r--r-- 1 rosuav rosuav 387893 Jul 22 00:03 ./pydoc_data/__pycache__/topics.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 231742 Jul 18 12:45 ./test/__pycache__/test_descr.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 202168 Jul 11 12:40 ./test/test_email/__pycache__/test_email.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 179521 Jul 11 12:40 ./tkinter/__pycache__/__init__.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 178331 Jul 11 12:40 ./test/__pycache__/test_socket.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 166424 Jul 11 12:40 ./test/__pycache__/test_argparse.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 162697 Jul 11 12:40 ./__pycache__/_pydecimal.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 160564 Jul 22 00:04 ./test/__pycache__/test_decimal.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 157038 Jul 11 12:40 ./test/__pycache__/test_inspect.cpython-36.pyc -rw-r--r-- 1 rosuav rosuav 149682 Jul 11 12:41 ./lib2to3/tests/__pycache__/test_fixers.cpython-36.pyc So you can have 600KB of source code or 350KB of pyc without any trouble whatsoever. (You won't actually be using .pyc files if you use exec as recommended in the other thread, but it's still a reasonable way of estimating compiled size.) If there are limits, they're certainly no lower than this. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Max size of Python source code and compiled equivalent
> Heh, great question, and I'm curious too! But one place to get a bit more > info is the standard library. > > rosuav@sikorsky:~/cpython/Lib$ find -name \*.py|xargs ls -lS|head > -rw-r--r-- 1 rosuav rosuav 624122 Jul 17 17:38 ./pydoc_data/topics.py Brilliant! :) Thanks Chris! Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: Technique for safely reloading dynamically generated module
On 7/21/2016 12:07 PM, Malcolm Greene wrote: I assume that one downside to the exec() approach is that there is no persistent namespace for this code's functions and classes, eg. after the exec() completes, its namespace disappears and is not available to code that follows? Objects only disappear when no references are left. So it is up to you whether you drop the namespace and use a new one for the next exec call or whether you use the same namespace over and over. IDLE's run module does the latter. Simplified, IDLE's Shell simulates the interactive interpreter by sending user input to this code in the run module. main = fake_main() # with __name__ = '__main__', __builtins__ = ... while True: try: code = user_input() exec(code, main) except BaseException as e: handle_exception(e) -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Max size of Python source code and compiled equivalent
Malcolm Greene wrote:
> We're writing a DSL parser that generates Python code. While the size of
> our generated code will be small (< 32K), I wanted to re-assure the rest
> of our team that there are no reasonable code size boundaries that we
> need to be concerned about. I've searched for Python documentation that
> covers max Python source (*.py) and compiled file (*.pyc) sizes without
> success. Any tips on where to look for this information?
>
> Background: Python 3.5.1 on Linux.
I don't know if/where this is documented, but there are structural limits:
>>> def nested(N):
... return "".join(" " * i + "if 1:\n" for i in range(N)) + " " * N +
"print('hi')"
...
>>> print(nested(3))
if 1:
if 1:
if 1:
print('hi')
>>> exec(nested(99))
hi
>>> exec(nested(100))
Traceback (most recent call last):
File "", line 1, in
File "", line 101
print('hi')
^
IndentationError: too many levels of indentation
--
https://mail.python.org/mailman/listinfo/python-list
Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]
Steven D'Aprano writes: > Or you might be using a language like Javascript, which intentionally has > only floats for numbers. That's okay, you can still perform exact integer > arithmetic, so long as you stay within the bounds of ±2**16. Small point: it's 2**52. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]
On Thu, Jul 21, 2016 at 4:54 PM, Ben Bacarisse wrote: > Steven D'Aprano writes: > > > Or you might be using a language like Javascript, which intentionally has > > only floats for numbers. That's okay, you can still perform exact integer > > arithmetic, so long as you stay within the bounds of ±2**16. > > Small point: it's 2**52. > If you really want to be picky, it is 2**53, inclusive: >>> 2**53-2.0 9007199254740990.0 >>> 2**53-1.0 9007199254740991.0 >>> 2**53+0.0 # Can no longer store odd numbers, but 2**53 is even so it can still be stored. 9007199254740992.0 >>> 2**53+1.0 9007199254740992.0 >>> 2**53+2.0 9007199254740994.0 This works as there is an implied one bit in the field for floats, giving 53 bits of storage despite only having 52 bits of storage. As the sign is stored in a separate bit, the same limit applies to both positive and negative numbers. -- https://mail.python.org/mailman/listinfo/python-list
learning python. learning defining functions . need help
having a little trouble with defining functions. i have a doc called ch5.py and
when i was trying the following i had issues
"
Try It Out: Defining a Function
Try saving the following in your file for Chapter 5, ch5.py.def in_fridge():
try:
count = fridge[wanted_food]
except KeyError:
count = 0
return count
How It Works
When you invoke ch5.py (press F5 while in Code Editor) with just the in_fridge
function defined, you won't see any output. However, the function will be
defined, and it can be invoked from the interactive Python session that you've
created.
To take advantage of the in_fridge function, though, you have to ensure that
there is a dictionary called fridge with food names in it. In addition, you
have to have a string in the name wanted_food. This string is how you can ask,
using in_fridge, whether that food is available. Therefore, from the
interactive session, you can do this to use the function:
>>> fridge = {'apples':10, 'oranges':3, 'milk':2}
>>> wanted_food = 'apples'
>>> in_fridge()
10
>>> wanted_food = 'oranges'
>>> in_fridge()
3
>>> wanted_food = 'milk'
>>> in_fridge()
2"
---this is what I have and tried to run--
def in_fridge():
fridge = {'apples':10, 'oranges':3, 'milk':2}
wanted_food = 'apples'
in_fridge()
where am i going wrong
--
https://mail.python.org/mailman/listinfo/python-list
Stupid question, just need a quick and dirty fix
I'm trying to modify some code to suit my purposes and I'm just trying to filter results as necessary. Basically, the code is returning one of a number from a subset of 150 numbers. I want to only do anything with it if the number is a 'good' one. I'm by no means a Python programmer (C# for me by trade) and I'm not looking for anything that will be distributed..I just want something that works. Basically, here's what I'm trying to insert: global blnDesiredInd blnDesiredInd == False if IDNum < 10: blnDesiredInd = True if IDNum == 12: blnDesiredInd = True if IDNum == 15: blnDesiredInd = True if IDNum == 24: blnDesiredInd = True if IDNum == 25: blnDesiredInd = True if IDNum == 26: blnDesiredInd = True if IDNum == 27: blnDesiredInd = True if IDNum == 28: blnDesiredInd = True if IDNum == 31: blnDesiredInd = True if IDNum == 34: blnDesiredInd = True if IDNum == 35: blnDesiredInd = True if IDNum == 36: blnDesiredInd = True if IDNum == 37: blnDesiredInd = True if IDNum == 38: blnDesiredInd = True if IDNum == 39: blnDesiredInd = True if IDNum == 40: blnDesiredInd = True if IDNum == 45: blnDesiredInd = True if IDNum == 50: blnDesiredInd = True if IDNum == 51: blnDesiredInd = True if IDNum == 53: blnDesiredInd = True if IDNum == 55: blnDesiredInd = True if IDNum == 56: blnDesiredInd = True if IDNum == 57: blnDesiredInd = True if IDNum == 59: blnDesiredInd = True if IDNum == 62: blnDesiredInd = True if IDNum == 65: blnDesiredInd = True if IDNum == 68: blnDesiredInd = True if IDNum == 71: blnDesiredInd = True if IDNum == 76: blnDesiredInd = True if IDNum == 78: blnDesiredInd = True if IDNum == 80: blnDesiredInd = True if IDNum == 82: blnDesiredInd = True if IDNum == 83: blnDesiredInd = True if IDNum == 87: blnDesiredInd = True if IDNum == 88: blnDesiredInd = True if IDNum == 89: blnDesiredInd = True if IDNum == 91: blnDesiredInd = True if IDNum == 93: blnDesiredInd = True if IDNum == 94: blnDesiredInd = True if IDNum == 96: blnDesiredInd = True if IDNum == 97: blnDesiredInd = True if IDNum == 101: blnDesiredInd = True if IDNum == 103: blnDesiredInd = True if IDNum == 105: blnDesiredInd = True if IDNum == 106: blnDesiredInd = True if IDNum == 107: blnDesiredInd = True if IDNum == 109: blnDesiredInd = True if IDNum == 110: blnDesiredInd = True if IDNum == 112: blnDesiredInd = True if IDNum == 113: blnDesiredInd = True if IDNum == 115: blnDesiredInd = True if IDNum == 122: blnDesiredInd = True if IDNum == 124: blnDesiredInd = True if IDNum == 125: blnDesiredInd = True if IDNum == 126: blnDesiredInd = True if IDNum == 130: blnDesiredInd = True if IDNum == 131: blnDesiredInd = True if IDNum == 132: blnDesiredInd = True if IDNum > 133: blnDesiredInd = True if blnDesiredInd == True: I get various errors no matter what I do to this to try and make it work. Variable not defined. Referenced before assignment. etc etc. I'm lost. How do I make it work? -- https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
On Fri, Jul 22, 2016 at 2:19 PM, Jordan Bayless wrote:
> I get various errors no matter what I do to this to try and make it work.
> Variable not defined. Referenced before assignment. etc etc. I'm lost. How do
> I make it work?
It might be easier if you post all your code. To be honest, what I'd
be looking at is something like this:
good_ids = {
12, 15, 24,
... # fill in all of these
}
desired = id < 10 or id > 133 or id in good_ids
But it's possible your problem has nothing to do with your massive
'if' tree and everything to do with indentation or other problems we
can't see.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
On Thursday, July 21, 2016 at 11:28:55 PM UTC-5, Chris Angelico wrote:
> On Fri, Jul 22, 2016 at 2:19 PM, Jordan Bayless wrote:
> > I get various errors no matter what I do to this to try and make it work.
> > Variable not defined. Referenced before assignment. etc etc. I'm lost. How
> > do I make it work?
>
> It might be easier if you post all your code. To be honest, what I'd
> be looking at is something like this:
>
> good_ids = {
> 12, 15, 24,
> ... # fill in all of these
> }
> desired = id < 10 or id > 133 or id in good_ids
>
> But it's possible your problem has nothing to do with your massive
> 'if' tree and everything to do with indentation or other problems we
> can't see.
>
> ChrisA
Posting the entire code snippet is tough because it's thousands of lines of
code. Basically, I'm inside of a For loop already. The code worked when I got
it, but I'm trying to tap into it and extend it outward to notify me via email
in certain circumstances. I got it to send the email, but it seems there's a)
no case statement (WTF?) and b) I'm limited to how many elif statements I can
use. Again, I don't particularly care how elegant this is because it's
ultimately getting disposed of sooner rather than later..I just want it to work.
Let me review my code and see if I can pare it down to the essentials so I can
give a better idea of what I'm doing.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
On Fri, Jul 22, 2016 at 2:39 PM, Jordan Bayless wrote: > it seems there's a) no case statement (WTF?) and b) I'm limited to how many > elif statements I can use. The latter isn't true; and you're not using elif anyway. With no case statement, you get pushed to other, better ways of doing things, like the much simpler way I showed in my previous email - it uses set membership rather than a series of individual equality checks. Faster, cleaner, much easier to work with. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
> On Jul 22, 2016, at 12:39 AM, Jordan Bayless wrote: > > Posting the entire code snippet is tough because it's thousands of lines of > code. You could paste into a GitHub gist (https://gist.github.com/) and share the link. -- https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
No, I tried using a bunch of elif statements earlier and when I added more than
around 3 of them it threw errors. I just assumed that was some kind of limit.
We both agree that's piss-poor, lazy coding. I'm just trying to find something
that works though. To this point, everything I try fails.
I added your code and now it's telling me my variable isn't defined.
good_ids = {
2, 3, 4, 5, 6, 7, 8, 9, 12, 15, 24, 25, 26, 27, 28, 31, 34, 35, 36, 37,
38, 39, 40, 45, 50, 51, 53, 55, 56, 57, 59, 62, 65, 68, 71, 76, 78, 80,
82, 83, 87, 88, 89, 91, 93, 94, 96, 97, 101, 103, 105, 106, 107, 109,
110, 112, 113, 115, 122, 124, 125, 126, 130, 131, 132, 134, 135, 136,
137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151
}
desired = Id < 10 or Id > 133 or Id in good_ids
When I try to validate whether I passed that check, I'm told there's a Name
error and it's not defined (using the last line of the snippet above).
Also, I guess I'm at a loss for what I'm supposed to do with "desired" to check
it prior to running my email code.
if desired == True: doesn't work
I'm headed to bed. Too tired to focus on making this work and I apparently
really don't 'get' what I'm doing. Maybe I'll be better off with fresh eyes on
it tomorrow.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
Jordan Bayless writes: > desired = Id < 10 or Id > 133 or Id in good_ids > When I try to validate whether I passed that check, I'm told there's a > Name error and it's not defined (using the last line of the snippet > above). Id was called IDNum in your earlier pst > Also, I guess I'm at a loss for what I'm supposed to do with "desired" > to check it prior to running my email code. > > if desired == True: doesn't work That should work, but it's more concise and idiomatic to say "if desired: ..." > I'm headed to bed. Too tired to focus on making this work and I > apparently really don't 'get' what I'm doing. Maybe I'll be better off > with fresh eyes on it tomorrow. You're probably better off reading a basic Python tutorial than trying to mess with a working piece of code by trial and error without knowing the language. https://docs.python.org/2/tutorial/index.html is a good place to get started. -- https://mail.python.org/mailman/listinfo/python-list
Convert from unsigned long long to PyLong
HI There,
I'm using MySQLdb as the MySQL client. Recently I got a weird problem of this
library. After looking into it, I suspect the problem may related to the
conversion from unsigned long to PyLongObject.
Here is the detail, If you are familiar with MySQLdb, the following snippet is
a way to query the data from MySQL:
connection = MySQLdb.connect(...)
connection.autocommit(True)
try:
cursor = connection.cursor()
if not cursor.execute(sql, values) > 0:
return None
row = cursor.fetchone()
finally:
connection.close()
return row[0]
Sometimes the return value of execute method would be 18446744073709552000 even
there is no matched data available. I checked the source code of the library,
the underlying implementation is
https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L835,
static PyObject *
_mysql_ConnectionObject_affected_rows(
_mysql_ConnectionObject *self,
PyObject *args)
{
if (!PyArg_ParseTuple(args, "")) return NULL;
check_connection(self);
return
PyLong_FromUnsignedLongLong(mysql_affected_rows(&(self->connection)));
}
And here is the official doc for mysql_affected_rows
http://dev.mysql.com/doc/refman/5.7/en/mysql-affected-rows.html.
Let me give a superficial understanding, please correct me if I were wrong.
In a 64-bit system, the mysql_affected_rows is supposed to return a number of
unsigned long, which means the range should be 0 ~ 2^64 (18446744073709551616),
How could it be possible the function PyLong_FromUnsignedLongLong return a
converted value larger than 2^64, that's what I don't understand.
Does anyone have some ideas of it?
The versions of the components I used:
Python: 2.7.6
MySQL 5.7.11
MySQLdb 1.2.5
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
On Fri, 22 Jul 2016 03:18 pm, Michael Selik wrote: > >> On Jul 22, 2016, at 12:39 AM, Jordan Bayless wrote: >> >> Posting the entire code snippet is tough because it's thousands of lines >> of code. > > You could paste into a GitHub gist (https://gist.github.com/) and share > the link. Are you going to read "thousands of lines" of unfamiliar code trying to work out what changes need to be made to fix an underspecified problem? Yeah, sure you are. Have fun. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
On Fri, Jul 22, 2016 at 3:26 PM, Jordan Bayless wrote: > When I try to validate whether I passed that check, I'm told there's a Name > error and it's not defined (using the last line of the snippet above). You're still not posting (a) your code, or (b) the full traceback, so it's not easy for us to help you. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Stupid question, just need a quick and dirty fix
On Fri, 22 Jul 2016 03:26 pm, Jordan Bayless wrote:
> No, I tried using a bunch of elif statements earlier and when I added more
> than around 3 of them it threw errors. I just assumed that was some kind
> of limit.
Right, because a 20+ years old programming language used by millions of
professionals all around the world *obviously* must have a limit of three
elif statements in a clause. What else could it be? *wink*
If only Python would print an exception and an error message so that we
could diagnose the error. Oh wait, it does.
Instead of just complaining about the limitations of a language you clearly
know nothing about, why don't you copy and paste the exceptions so that we
can see them? There's no sin in knowing nothing about a language. We all
started off ignorant. But jumping to conclusions, particularly the
conclusion "well it must be the language's fault", that's just pretty poor.
I know you're frustrated. You need to relax, and approach this
systematically, and not just blindly make changes without understanding
them. More below.
> We both agree that's piss-poor, lazy coding. I'm just trying to
> find something that works though. To this point, everything I try fails.
>
> I added your code and now it's telling me my variable isn't defined.
Have you tried defining it?
Which variable? If you read the error message, it will tell you which
variable is not defined. Then you read the code to see where you are trying
to access the variable before defining it. This won't work:
print(x)
x = 1
but this will:
x = 1
print(x)
Can you see why? You need to have given the variable a value *before* using
it.
> good_ids = {
> 2, 3, 4, 5, 6, 7, 8, 9, 12, 15, 24, 25, 26, 27, 28, 31, 34, 35, 36,
> 37, 38, 39, 40, 45, 50, 51, 53, 55, 56, 57, 59, 62, 65, 68, 71, 76,
> 78, 80, 82, 83, 87, 88, 89, 91, 93, 94, 96, 97, 101, 103, 105, 106,
> 107, 109, 110, 112, 113, 115, 122, 124, 125, 126, 130, 131, 132, 134,
> 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148,
> 149, 150, 151
> }
>
> desired = Id < 10 or Id > 133 or Id in good_ids
>
> When I try to validate whether I passed that check, I'm told there's a
> Name error and it's not defined (using the last line of the snippet
> above).
Right. And what name does it say is not defined? Is is "Id"? Ask yourself:
is Id defined anywhere? The answer will be No. Where does the name come
from?
You blindly copied it from Chris Angelico's code. He said:
desired = Id < 10 or Id > 133 or Id in good_ids
(actually he used lowercase "id" rather than "Id"). But go back to your
original request, where you wrote:
Basically, here's what I'm trying to insert:
global blnDesiredInd
blnDesiredInd == False
if IDNum < 10:
blnDesiredInd = True
if IDNum == 12:
blnDesiredInd = True
[...]
Maybe if you replace the names Chris used with the names your program
already uses?
good_ids = { blah blah blah }
blnDesiredInd = IDNum < 10 or IDNum > 133 or IDNum in good_ids
> Also, I guess I'm at a loss for what I'm supposed to do with "desired" to
> check it prior to running my email code.
>
> if desired == True: doesn't work
What were you planning on doing with blnDesiredInd?
if blnDesiredInd: # no need to say "== True"
# do the thing you want to do when blnDesiredInd is true
...
else:
# do the thing you want to do when blnDesiredInd is not true
...
You have to replace the dots ... with actual code, of course, but we can't
help you with that. It's *your* project, not ours, we have no idea what you
want to happen.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
