[issue494066] Access to readline history elements

Change by admin : -- github: None -> 35765 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue474831] Command history doesn't work on Mandrake

Change by admin : -- github: None -> 35402 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400738] add history file functions for Modules/readline.c

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400742] readline history read/write

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400739] add history file functions for Modules/readline.c

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400739] add history file functions for Modules/readline.c

Change by admin : -- github: None -> 32521 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400742] readline history read/write

Change by admin : -- github: None -> 32524 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400738] add history file functions for Modules/readline.c

Change by admin : -- github: None -> 32520 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45729] [doc] "history and license" link has wrong target

Julien Palard added the comment: > dev docs direct to `/license.html` which redirects to `/3/license.html` All docs are redirecting to `/license.html`, this allow it to work also out of docs.python.org. > 3.9 docs have the same; wouldn’t it be better to have `/3.9/license.html`? It's maybe

[issue45729] [doc] "history and license" link has wrong target

Éric Araujo added the comment: dev docs direct to `/license.html` which redirects to `/3/license.html` 3.9 docs have the same; wouldn’t it be better to have `/3.9/license.html`? -- ___ Python tracker

[issue45729] [doc] "history and license" link has wrong target

Julien Palard added the comment: I checked on docs.python.org and it's fixed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue45729] [doc] "history and license" link has wrong target

Change by miss-islington : -- pull_requests: +28745 pull_request: https://github.com/python/cpython/pull/30541 ___ Python tracker ___

[issue45729] [doc] "history and license" link has wrong target

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +28744 pull_request: https://github.com/python/cpython/pull/30540 ___ Python tracker

[issue45729] [doc] "history and license" link has wrong target

Change by Julien Palard : -- keywords: +patch pull_requests: +28728 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30527 ___ Python tracker ___

[issue45729] [doc] "history and license" link has wrong target

Julien Palard added the comment: This should be fixed in python-docs-theme==2022.1. I'll close the issue when I actually see the fix applied on docs.python.org. -- nosy: +mdk ___ Python tracker

[issue45729] [doc] "history and license" link has wrong target

Change by Alex Waygood : -- nosy: -AlexWaygood ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45729] [doc] "history and license" link has wrong target

Alex Waygood added the comment: @Éric: I personally found it difficult to immediately understand what the issue was about when reading only the title on the BPO homepage, and thought the change in title would help clarify, having seen other documentation issues marked similarly on the

[issue45729] [doc] "history and license" link has wrong target

Éric Araujo added the comment: Tracked to https://github.com/python/python-docs-theme/issues/89 AlexWaygood: can I ask why add pseudo-tags to the title field when we do have structured data (components set to doc) on this tracker? Is it a new practice? -- nosy: +AlexWaygood

[issue45729] [doc] "history and license" link has wrong target

Change by Alex Waygood : -- title: "history and license" link has wrong target -> [doc] "history and license" link has wrong target ___ Python tracker <https://

[issue45729] "history and license" link has wrong target

Éric Araujo added the comment: It happens on all pages for all versions, because the link is empty. 3.8 doesn’t have that line so doesn’t show the bug. I am trying to find where that is defined. Strangely, I don’t find results looking for `please donate` which is the line below… --

[issue45729] "history and license" link has wrong target

New submission from Jacob Lifshay : https://docs.python.org/3.10/library/csv.html at the bottom the "history and license" link just links back to csv.html, rather than the correct target. -- assignee: docs@python components: Documentation messages: 405807 nosy: d

[issue45632] Strange readline save history behaviour in site.py

New submission from doraeric : I noticed that in site.py, it saves history to a hard-coded location if the current history length is 0. The history is considered as not loaded if the length is 0, but it may be actually loaded from a empty file. In this case, the history is save to hard-coded

[issue42626] readline history, vi-editingmode and ANSI color codes bug

Joakim Nilsson added the comment: Yes, I have noticed that too, and I agree, not as bad as if it was garbled, but still an annoyance. On Fri, Jul 30, 2021 at 1:34 AM Andrei Kulakov wrote: > > Andrei Kulakov added the comment: > > Joakim: by the way, what I was able to reproduce is just a

[issue42626] readline history, vi-editingmode and ANSI color codes bug

Andrei Kulakov added the comment: Joakim: by the way, what I was able to reproduce is just a visual bug. IOW, the text is still the same and all there in the buffer, but it shows up only after a combination of rightward movement and 'a', and a copy of it shows up on the left side. So it's

[issue42626] readline history, vi-editingmode and ANSI color codes bug

Andrei Kulakov added the comment: Also this bug happens on both iterm2 and terminal on MacOS, but note that on 'terminal', it's impossible to ctrl-c or ctrl-z out of the test script, so if you test it, you will need to close the window or the tab, and lose shell history and background jobs

[issue42626] readline history, vi-editingmode and ANSI color codes bug

Andrei Kulakov added the comment: I was able to reproduce something very similar, and I believe essentially the same issue perhaps varying due to config. I think I've actually seen similar glitches with python command line readline handling of k. So, entering 1234 always works fine. The

[issue42626] readline history, vi-editingmode and ANSI color codes bug

Joakim Nilsson added the comment: Sorry, my mistake. If you remove the last line "input()" from readline.py, it should be reproducible. Tested on Python 3.9.2. Link to video demonstration of the bug: http://nijoakim.com/readline-example.mp4. -- Added file:

[issue42626] readline history, vi-editingmode and ANSI color codes bug

Andrei Kulakov added the comment: I can't reproduce on MacOS in both Py 3.9.1 and in dev version. Works fine, I can erase everything after '2' and before it. -- nosy: +andrei.avk ___ Python tracker

[issue42626] readline history, vi-editingmode and ANSI color codes bug

New submission from Joakim Nilsson : Tested on Debian Bullseye with Python 3.9. If 'set editing-mode vi' is used in .inputrc and the attached program is run, a bug occurs when navigating the readline history. It seems only to occur when ANSI color escape characters are input to the 'input

[issue41075] IDLE: Better support history navigation

E. Paine added the comment: > but not with binding to modifier-up/down. I cannot reproduce. I have tested on both Windows and Linux and found I could successfully change to (and use) the modifier-up/down bindings both through the Keys page of the configdialog and by editing the keys def.

[issue41075] IDLE: Better support history navigation

Change by Terry J. Reedy : -- nosy: +epaine ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41075] IDLE: Better support history navigation

Terry J. Reedy added the comment: Yes, history works fine with the current bindings to alt-p and alt-n, or with binding to up or down, but not with binding to modifier-up/down. -- ___ Python tracker <https://bugs.python.org/issue41

[issue41075] IDLE: Better support history navigation

Terry J. Reedy added the comment: History and up/down is apart of #2704. It has patches that include the up/down change, but I don't expect to use any of them as they are. I tried Shift/Control/Alt - Up/Down and none worked. Rebinding just Up/Down did (in Shell only, leaving up/down

[issue40441] Plural typo in Design and History FAQ

Change by Ammar Askar : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40441] Plural typo in Design and History FAQ

Joannah Nanjekye added the comment: After merging the associated PR, I believe this is resolved. Thanks Alex for reporting and solving this -- nosy: +nanjekyejoannah stage: -> resolved ___ Python tracker

[issue40441] Plural typo in Design and History FAQ

New submission from alexpovel : The documentation under "Design and History FAQ" has a typo in its "Why doesn’t Python have a “with” statement for attribute assignments?" section: https://docs.python.org/3/faq/design.html#why-doesn-t-python-have-a-with-statement-for-a

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On 2/02/20 1:00 AM, R.Wieser wrote: As sent to the OP. I appreciate these discussions, in the expectation of learning something-new. (and with rust-removal paints at the ready!) Indeed. Even if its just a different POV which makes you rethink the reasons of your own one. +1 -- Regards =dn

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

DL, >> While I agree with you there, I've been searching for other ways to >> detect a >> keypress (in a console-based script) and have found none. > > Color me disappointed! I was disapponted too, but realized that being able to just capture any keypress (how does the 'puter know the

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On 2020-01-30 07:56:30 +1100, Chris Angelico wrote: > On Thu, Jan 30, 2020 at 7:49 AM MRAB wrote: > > On 2020-01-29 20:00, jkn wrote: > > > I could have a file with all the URLs listed and work through each line > > > in turn. > > > But then I would have to rewrite the file (say, with the > > >

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Sat, Feb 1, 2020 at 4:17 PM DL Neil via Python-list wrote: > > On 31/01/20 9:53 PM, R.Wieser wrote: > >> Using ctrl+c is a VERY BAD idea. > > > > To have it just exit the program ? Yes, indeed. > > > > Though you /could/ keep track of what needs to be finished and have the > > ctrl-c handler

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On 31/01/20 9:53 PM, R.Wieser wrote: Using ctrl+c is a VERY BAD idea. To have it just exit the program ? Yes, indeed. Though you /could/ keep track of what needs to be finished and have the ctrl-c handler do that for you (barf). Another posibility is to capture the ctrl-c and set a flag,

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On 31/01/20 9:30 AM, jkn wrote: Err, well, thanks for that discussion gents... As it happens I do know how to use a database, but I regard it as overkill for what I am trying to do here. I think a combination of hashing the URL, and using a suffix to indicate the result of previous downloaded

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

jkn, > I'm happy to consider the risk and choose (eg.) the hash function > accordingly, thanks. No problem, just wanted you to be aware and (thus) able to choose. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Friday, January 31, 2020 at 9:41:32 AM UTC, R.Wieser wrote: > jkn, > > > I think a combination of hashing the URL, > > I hope you're not thinking of saving the hash (into the "done" list) instead > if the URL itself. While hash collisions do not happen often (especially > not in a small

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Friday, January 31, 2020 at 9:41:32 AM UTC, R.Wieser wrote: > jkn, > > > I think a combination of hashing the URL, > > I hope you're not thinking of saving the hash (into the "done" list) instead > if the URL itself. While hash collisions do not happen often (especially > not in a small

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

jkn, > I think a combination of hashing the URL, I hope you're not thinking of saving the hash (into the "done" list) instead if the URL itself. While hash collisions do not happen often (especially not in a small list), you cannot rule them out. And when that happens that would mean you

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Fri, Jan 31, 2020 at 7:56 PM R.Wieser wrote: > > Dennis, > > > A full client/server RDBM should never be affected by an abort > > of a client program. > > What you describe is on the single query level. What I was thinking of was > having several queries that /should/ work as a single unit,

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

DL, >> Nothing that can't be countered by keeping copies of the last X number of >> to-be-dowloaded-URLs files. > > That's a good idea, but how would the automated system 'know' to give-up > on the current file and utilise generation n-1? Unable to open the file or > ??? Well, that would be one

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

Dennis, > A full client/server RDBM should never be affected by an abort > of a client program. What you describe is on the single query level. What I was thinking of was having several queries that /should/ work as a single unit, but could get interrupted (because of the OPs ctrl-c). Yes,

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On 30/01/20 9:35 PM, R.Wieser wrote: MRAB's scheme does have the disadvantages to me that Chris has pointed out. Nothing that can't be countered by keeping copies of the last X number of to-be-dowloaded-URLs files. That's a good idea, but how would the automated system 'know' to give-up on

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

Err, well, thanks for that discussion gents... As it happens I do know how to use a database, but I regard it as overkill for what I am trying to do here. I think a combination of hashing the URL, and using a suffix to indicate the result of previous downloaded attempts, will work adequately for

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Fri, Jan 31, 2020 at 4:11 AM R.Wieser wrote: > But, do you remember what the OP said ? > [quote] > want to download these as a 'background task'. ... you can CTRL-C out, > [/quote] > > Why now do I think that, when such a backgroud process is forgotten and the > 'puter switched off, the file,

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

Chris, > Yes, and then you backpedalled furiously when I showed that > proper transactions prevent this. You're a fool, out for a fight. /You/ might know exactly how to handle a database to make sure its /transactions/ will not leave the database in a corrupt state, but as I mentioned a few

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Fri, Jan 31, 2020 at 2:01 AM R.Wieser wrote: > > Chris, > > >> I think that a database is /definitily/ overcomplicating stuff, > > > > Okay, sure... but you didn't say that. > > I'm sorry ? In my first reply I described a file-based approach and > mentioned that the folder approach is a

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

Chris, >> I think that a database is /definitily/ overcomplicating stuff, > > Okay, sure... but you didn't say that. I'm sorry ? In my first reply I described a file-based approach and mentioned that the folder approach is a rather good one. What do you think I ment there ? > You said that

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, 30 Jan 2020 23:34:59 +1100 Chris Angelico wrote: > ... I wasn't advocating for the use of a database; my first and > strongest recommendation was, and still is, a stateless system wherein > the files themselves are the entire indication of which documents have > been downloaded. Yes, I

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, Jan 30, 2020 at 11:11 PM R.Wieser wrote: > > Chris, > > > That's what transactions are for. > > Again, > > >> I guess that that went right over your head. :-)/You/ might know > >> exactly > >> what should and shouldn't be done, what makes you think the OP currently > >> does ? > > > I

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

Chris, > That's what transactions are for. Again, >> I guess that that went right over your head. :-)/You/ might know >> exactly >> what should and shouldn't be done, what makes you think the OP currently >> does ? > I don't understand why you're denigrating databases, Am I denigrating a

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, Jan 30, 2020 at 8:36 PM R.Wieser wrote: > > Chris, > > > Uhh > > > > Proper databases don't HAVE non-atomic operations. That's kinda their job. > > Uhh... yes, /singular/ operations are considered to be atomic. A series of > operations /ment/ to be executed as a single one on the

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

Chris, > Uhh > > Proper databases don't HAVE non-atomic operations. That's kinda their job. Uhh... yes, /singular/ operations are considered to be atomic. A series of operations /ment/ to be executed as a single one on the other hand aren't. > Unless you mean that there's a non-atomic

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, Jan 30, 2020 at 7:41 PM R.Wieser wrote: > Also think of the old adagio: BTW, the word you want here is "adage", unless you mean that it's a piece of music being played slowly :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, Jan 30, 2020 at 7:41 PM R.Wieser wrote: > A database /sounds/ good, but what happens when you ctrl-c outof a > non-atomic operation ? How do you fix that ?IOW: Databases can be > corrupted for pretty-much the same reason as for a simple datafile (but with > much worse consequences).

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

jkn, > MRAB's scheme does have the disadvantages to me that Chris has pointed > out. Nothing that can't be countered by keeping copies of the last X number of to-be-dowloaded-URLs files. As for rewriting every time, you will /have/ to write something for every action (and flush the file!),

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, Jan 30, 2020 at 8:59 AM DL Neil via Python-list wrote: > * NB I don't use SQLite (in favor of going 'full-fat') and thus cannot > vouch for its behavior under load/queuing mechanism/concurrent > accesses... but I'm biased and probably think/write SQL more readily > than Python - oops! I

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On 30/01/20 10:38 AM, jkn wrote: On Wednesday, January 29, 2020 at 8:27:03 PM UTC, Chris Angelico wrote: On Thu, Jan 30, 2020 at 7:06 AM jkn wrote: I want to be a able to use a simple 'download manager' which I was going to write (in Python), but then wondered if there was something suitable

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Wednesday, January 29, 2020 at 8:27:03 PM UTC, Chris Angelico wrote: > On Thu, Jan 30, 2020 at 7:06 AM jkn wrote: > > > > Hi all > > I'm almost embarrassed to ask this as it's "so simple", but thought I'd > > give > > it a go... > > Hey, nothing wrong with that! > > > I want to be a

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, 30 Jan 2020 07:26:36 +1100 Chris Angelico wrote: > On Thu, Jan 30, 2020 at 7:06 AM jkn wrote: > > The situation is this - I have a long list of file URLs and want to > > download these as a 'background task'. I want this to process to be > > 'crudely persistent' - you can CTRL-C out,

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, Jan 30, 2020 at 7:49 AM MRAB wrote: > > On 2020-01-29 20:00, jkn wrote: > > I could have a file with all the URLs listed and work through each line in > > turn. > > But then I would have to rewrite the file (say, with the > > previously-successful > > lines commented out) as I go. > > >

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On 2020-01-29 20:00, jkn wrote: Hi all I'm almost embarrassed to ask this as it's "so simple", but thought I'd give it a go... I want to be a able to use a simple 'download manager' which I was going to write (in Python), but then wondered if there was something suitable already out

Re: Suggestions on mechanism or existing code - maintain persistence of file download history

On Thu, Jan 30, 2020 at 7:06 AM jkn wrote: > > Hi all > I'm almost embarrassed to ask this as it's "so simple", but thought I'd > give > it a go... Hey, nothing wrong with that! > I want to be a able to use a simple 'download manager' which I was going to > write > (in Python), but then

Suggestions on mechanism or existing code - maintain persistence of file download history

Hi all I'm almost embarrassed to ask this as it's "so simple", but thought I'd give it a go... I want to be a able to use a simple 'download manager' which I was going to write (in Python), but then wondered if there was something suitable already out there. I haven't found it, but thought

[issue38791] readline history file is hard-coded

Jonathan Conder added the comment: I agree. Did a cursory search before posting but missed it somehow -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue38791] readline history file is hard-coded

Zackery Spytz added the comment: This issue seems like a duplicate of bpo-29779 (which has a pull request). -- nosy: +ZackerySpytz ___ Python tracker ___

[issue38791] readline history file is hard-coded

Change by Jonathan Conder : -- keywords: +patch pull_requests: +16658 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17149 ___ Python tracker ___

[issue38791] readline history file is hard-coded

Change by pmp-p : -- nosy: +twouters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38791] readline history file is hard-coded

Change by pmp-p : -- nosy: +pmpp ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38791] readline history file is hard-coded

New submission from Jonathan Conder : Other tools such as bash and less allow their history file to be customised with an environment variable. Will add a patch for this in a bit. This could also be customised using PYTHONSTARTUP, but then the user has to duplicate a bunch of code which

[issue35217] REPL history is broken when python is invoked with cmd /c

Eryk Sun added the comment: The Windows console has a fixed number of history buffers. In Windows 7 the default maximum is four history buffers. In this case, if we run a script via cmd.exe -> py.exe -> python.exe, then only one history buffer remains for a child process. As you've ob

[issue35280] Interactive shell overwrites history

New submission from dingens : When opening two shells at the same time, history from the one that is closed first gets lost. Steps to reproduce: - let's call the contents of the history before this experiment `z` - open two interactive shells called A and B - execute commands in them, say

[issue35217] REPL history is broken when python is invoked with cmd /c

hon"]) run("python", shell=True) ``` 2. Run the script. Actual result: The script will invoke Python REPL 3 times. The first and the third REPL don't save the command history. Pressing up/down arrows would clear the entire line. Pressing F7 has no effect. The second REPL wor

[issue33887] doc Add TOC in Design and History FAQ

miss-islington added the comment: New changeset a845b7ab3e8ba1c20ef4c3ee23ebf50df7e7c4c6 by Miss Islington (bot) in branch '3.6': bpo-33887: Add TOC to Design and History FAQ(GH-7766) https://github.com/python/cpython/commit/a845b7ab3e8ba1c20ef4c3ee23ebf50df7e7c4c6

[issue33887] doc Add TOC in Design and History FAQ

miss-islington added the comment: New changeset 070c91e46579429f7af7599af6d9e67a8dc5be50 by Miss Islington (bot) in branch '3.7': bpo-33887: Add TOC to Design and History FAQ(GH-7766) https://github.com/python/cpython/commit/070c91e46579429f7af7599af6d9e67a8dc5be50

[issue33887] doc Add TOC in Design and History FAQ

miss-islington added the comment: New changeset 3e3157bd55f197ab36b280b26aea8dcd04e37fcf by Miss Islington (bot) in branch '2.7': bpo-33887: Add TOC to Design and History FAQ(GH-7766) https://github.com/python/cpython/commit/3e3157bd55f197ab36b280b26aea8dcd04e37fcf -- nosy: +miss

[issue33887] doc Add TOC in Design and History FAQ

Mariatta Wijaya added the comment: Thanks for the PR! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33887] doc Add TOC in Design and History FAQ

Change by miss-islington : -- pull_requests: +7488 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33887] doc Add TOC in Design and History FAQ

Change by miss-islington : -- pull_requests: +7487 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33887] doc Add TOC in Design and History FAQ

Change by miss-islington : -- pull_requests: +7486 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33887] doc Add TOC in Design and History FAQ

Mariatta Wijaya added the comment: New changeset 38cf49bf695903ac7a8516bca6bbb6b32d935bb5 by Mariatta (Andrés Delfino) in branch 'master': bpo-33887: Add TOC to Design and History FAQ(GH-7766) https://github.com/python/cpython/commit/38cf49bf695903ac7a8516bca6bbb6b32d935bb5 -- nosy

[issue33887] doc Add TOC in Design and History FAQ

Andrés Delfino added the comment: Sorry, Raymond, you are right. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue33887] doc Add TOC in Design and History FAQ

Raymond Hettinger added the comment: Please don't fill-up the tracker with dozens of micro-PRs for tiny documentation changes of dubious benefit or occasional detriment. On the balance, it isn't helpful to have a newcomer second-guess every little writing decision that has been made.

[issue33887] doc Add TOC in Design and History FAQ

Change by Andrés Delfino : -- keywords: +patch pull_requests: +7374 stage: -> patch review ___ Python tracker ___ ___

[issue33887] doc Add TOC in Design and History FAQ

New submission from Andrés Delfino : IHMO, having all questions put together is really useful. -- assignee: docs@python components: Documentation messages: 319824 nosy: adelfino, docs@python priority: normal severity: normal status: open title: doc Add TOC in Design and History FAQ type

Re: [OT] multicore/cpu history

On 2018-03-25, Steven D'Aprano wrote: > Not really. With multiple CPUs, you have the option of running two > distinct OSes in isolation, not merely virtual machines but actual > distinct machines in the same box. Not on any of the multi-CPU motherboards I

Re: [OT] multicore/cpu history

On 2018-03-25 22:52:59 +, Steven D'Aprano wrote: > On Sun, 25 Mar 2018 23:29:07 +0200, Peter J. Holzer wrote: > >> >> By the way, multiple CPU machines are different from CPUs with > >> >> multiple cores: > >> >> > >> >> http://smallbusiness.chron.com/multiple-cpu-vs-multicore-33195.html > >>

Re: A bit of Python history

amazing ! Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ On Fri, 6 Apr 2018, 15:52 Steven D'Aprano, < steve+comp.lang.pyt...@pearwood.info> wrote: > I stumbled across this post from the Timbot, Tim Peters, back in 2000, > where he correctly predicted that Python would get generators

A bit of Python history

I stumbled across this post from the Timbot, Tim Peters, back in 2000, where he correctly predicted that Python would get generators and iterators in Python 2: https://mail.python.org/pipermail/python-list/2000-January/033955.html as well as list comprehensions. -- Steve --

Re: [OT] multicore/cpu history

On Monday 26 March 2018 12:12:46 Dennis Lee Bieber wrote: > On Mon, 26 Mar 2018 11:30:54 -0400, Gene Heskett > > > declaimed the following: > >On Monday 26 March 2018 10:06:36 Dennis Lee Bieber wrote: > > > > >>As I recall, the bootloader on the Raspberry Pi runs

Re: [OT] multicore/cpu history

On Monday 26 March 2018 10:06:36 Dennis Lee Bieber wrote: > On Mon, 26 Mar 2018 10:02:15 + (UTC), Steven D'Aprano > > declaimed the following: > >Hardware people can probably tell you what it is that CPUs do that > > FPUs and GPUs don't do. Or

Re: [OT] multicore/cpu history

On Mon, 26 Mar 2018 10:03:43 +1100, Chris Angelico wrote: > At what point does it change from being two CPUs to being one CPU and > one auxiliary processing unit? When someone writes an OS that will run on the "auxiliary processing unit" alone, then it's probably time to start calling it a CPU

Re: [OT] multicore/cpu history

On Mon, Mar 26, 2018 at 9:52 AM, Steven D'Aprano wrote: > On Sun, 25 Mar 2018 23:29:07 +0200, Peter J. Holzer wrote: > > [...] >>> >> By the way, multiple CPU machines are different from CPUs with >>> >> multiple cores: >>> >> >>> >>

  1   2   3   4   5   6   >