Re: unable to resolve readline issues
On 04/12/2022 17:08, Eryk Sun wrote: > On 12/2/22, biglee12...@gmail.com wrote: >> >> From this point on Python became unusable as I uninstalled rebooted then >> reinstalled to find I have the same issues as stated. Finally uninstalled >> Python as it doesn't perform as usual especially trying to understand the >> use of pyreadline, gnureadline and or just readline. > > When Python runs interactively, it implicitly tries to import the > readline module. On POSIX, Python has a builtin readline module that > usually uses the GNU Readline library. > > On Windows, Python does not include a readline module. Instead, if > standard I/O is a console, the high-level WinAPI ReadConsoleW() > function is used, which implements its own line editor and > command-line history. It's not as general, flexible, or capable as the > readline interface, so a third-party pyreadline package was > implemented for Windows. However, as far as I know, pyreadline is no > longer actively developed. Thus it has out-of-date code, which may be > broken in newer releases of Python, such as isinstance(x, > collections.Callable). > > Your choice is to either patch pyreadline to fix the bug or uninstall it. (*) How to patch it Open the file Lib/site-packages/pyreadline/py3k_compat.py and locate the procedure def callable(x): return isinstance(x, collections.Callable) Change it to def callable(x): return isinstance(x, collections.abc.Callable) You're done. -- https://mail.python.org/mailman/listinfo/python-list
on the python paradox
The Python Paradox Paul Graham August 2004 In a recent talk [1] I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project. I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart. It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know. Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job. Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they're exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience. A friend of mine who knows nearly all the widely used languages uses Python for most of his projects. He says the main reason is that he likes the way source code looks. That may seem a frivolous reason to choose one language over another. But it is not so frivolous as it sounds: when you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor. At the mention of ugly source code, people will of course think of Perl. But the superficial ugliness of Perl is not the sort I mean. Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts. Perl may look like a cartoon character swearing, but there are cases where it surpasses Python conceptually. So far, anyway. Both languages are of course moving targets. But they share, along with Ruby (and Icon, and Joy, and J, and Lisp, and Smalltalk) the fact that they're created by, and used by, people who really care about programming. And those tend to be the ones who do it well. (*) Footnotes [1] Audio of the talk, also attached to this post http://origin.conversationsnetwork.org/Paul%20Graham%20-%20Great%20Hackers.mp3 -- https://mail.python.org/mailman/listinfo/python-list
Re: Nonuniform PRNG?
On 07/12/2022 13:05, David Lowry-Duda wrote: > Inspired by the recent thread about pseudorandom number generators on > python-ideas (where I also mistakenly first wrote this message), I began > to wonder: suppose that I had a pseudorandom number generator that > attempted to generate a nonuniform distribution. Suppose for instance > that it was to generate a 0 bit 2/3 of the time, and a 1 bit 1/3 of the > time. > > How would one go about testing this PRNG against an idealized (similarly > biased) PRNG? I believe things go like this. If you have a uniform PRNG, you test it against the state-of-the-art in statistical tests then build from it your nonuniform one. Now you have a nonuniform one that's tested. But you want things the other way around. Having a nonuniform one to start, you build a uniform one from the nonuniform one and then test it against the state-of-the-art in statistical tests. I believe you might be wondering how to build one from the other, but I'll let you check that. By the way, there's no such thing as an idealized PRNG. All PRNG fail all statistical tests. The question is when. A bad PRNG fails quickly and obviously. A good one requires large samples or a nontrivial test. -- https://mail.python.org/mailman/listinfo/python-list
Re: Nonuniform PRNG?
On 07/12/2022 14:04, Stefan Ram wrote: > r...@zedat.fu-berlin.de (Stefan Ram) writes: >> So, in this case, careful code reviews might be better than >> tests. For example, assuming, random.intrange( 0, 2 ) works >> as advertised, we can be pretty sure that >> 0 if random.randint( 0, 2 ) else 1 >> fulfills the requirement. > > In practice, tests should still be done. When such a function > returns the same result a hundred times, it does make sense > to become suspicious and investigate it. Whatever it does a hundred times is not enough. Code review is definitely not enough. The design of PRNGs should be good in theory --- designed with good mathematical foundations --- and in practice by passing all tests in the best-designed batteries. As far as I know, the state-of-the-art in statistical tests against PRNGs is the TestU01 library, available at http://simul.iro.umontreal.ca/testu01/tu01.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Nonuniform PRNG?
On 07/12/2022 13:45, Stefan Ram wrote: [...] > |One of the oldest interpretations is the /limit frequency/ > |interpretation. If the conditioning event /C/ can lead > |to either A or "not A", and if in /n/ repetitions of such > |a situation the event A occurs /m/ times, then it is asserted > |that P(A|C) = lim n-->oo (m/n). This provides not only > |an interpretation of probability, but also a definition > |of probability in terms of a numerical frequency ratio. > |Hence the axioms of abstract probability theory can > |be derived as theorems of the frequency theory. > | > |In spite of its superficial appeal, the limit frequency > |interpretation has been widely discarded, primarily because > |there is no assurance that the above limit really exists for > |the actual sequences of events to which one wishes to apply > |probability theory. > | > "Quantum Mechanics" (1998) - Leslie E. Ballentine That's pretty interesting. Indeed, we really must discard this frequency interpretation, even though it is what's in my mind when I think of estimating the probability of a certain event, which I think would be called the empirical distribution of probability? -- https://mail.python.org/mailman/listinfo/python-list
Re: on the python paradox
On 11/12/2022 10:57, Martin Di Paola wrote: >> On Mon, Dec 05, 2022 at 10:37:39PM -0300, Sabrina Almodóvar wrote: >>> The Python Paradox >>> Paul Graham >>> August 2004 >>> >>> [SNIP] >>> >>> Hence what, for lack of a better name, I'll call the Python paradox: >>> if a company chooses to write its software in a comparatively >>> esoteric language, they'll be able to hire better programmers, >>> because they'll attract only those who cared enough to learn it. And >>> for programmers the paradox is even more pronounced: the language to >>> learn, if you want to get a good job, is a language that people don't >>> learn merely to get a job. >>> >>> [SNIP] > > I don't think that an esoteric language leads to better programmers. When you say this, I interpret it as a theorem, A implies B, but surely nobody would be so foolish to claim such thing, so perhaps you can review your reading or writing. > I know really good people that work mostly in assembly which by today > standard would be considered "esoteric". So, I wouldn't consider assembly esoteric, but I certainly would not try to define esoteric. > They are really good at their field but they write shitty code in higher > languages as python. I bet. If all they know is assembly, then they master very few linguistic abstractions. > That same goes for the other direction: I saw Ruby programmers writing C > code and trust me, it didn't result in good quality code. A Ruby person who doesn't know C must also know very little about machines and operating systems, so that is bound to failure in C. > I would be more inclined to think that a good programmer is not the one > that knows an esoteric language but the one that can jump from one > programming paradigm to another. That makes a lot of sense. Such person knows so many ways of expression, which most likely implies mastery of linguistic abstractions and expression. > And when I say "jump" I mean that he/she can understand the problem to > solve, find the best tech stack to solve it and do it in an efficient > manner using that tech stack correctly. Got ya. > It is in the "using that tech stack correctly" where some programmers > that "think" they know languages A, B and C get it wrong. I agree with that too. > Just writing code that "compiles" and "it does not immediately crash" is > not enough to say that "you are using the tech stack correctly". So true. Good thoughts. -- https://mail.python.org/mailman/listinfo/python-list
Re: String to Float, without introducing errors
On 17/12/2022 18:55, Stefan Ram wrote: > Grant Edwards writes: >> Yes, fixed point (or decimal) is a better fit for what he's doing. but >> I suspect that floating point would be a better fit for the problem >> he's trying to solve. > > I'd like to predict that within the next ten posts in this > thread someone will mention "What Every Computer Scientist > Should Know About Floating-Point Arithmetic". Lol! Speaking of which, let us guide ourselves by https://floating-point-gui.de/basic/ and learn that calculations such as ``0.1 + 0.4 work correctly.'' That's the Internet. You learn a thing on a Tuesday, and on a Wednesday you're a teacher. That's why we need peer review. -- https://mail.python.org/mailman/listinfo/python-list
