RE: Cutting slices

I am not commenting on the technique or why it is chosen just the part where the last search looks for a non-existent period: s = 'alpha.beta.gamma' ... s[ 11: s.find( '.', 11 )] What should "find" do if it hits the end of a string without finding the period you claim is a divider? Could that

RE: Fast full-text searching in Python (job for Whoosh?)

Dino, Sending lots of data to an archived forum is not a great idea. I snipped most of it out below as not to replicate it. Your question does not look difficult unless your real question is about speed. Realistically, much of the time spent generally is in reading in a file and the actual search

Re: Cutting slices

On 6/03/23 11:43 am, Stefan Ram wrote: A user tries to chop of sections from a string, but does not use "split" because the separator might become more complicated so that a regular expression will be required to find it. What's wrong with re.split() in that case? -- Greg --

Re: Fast full-text searching in Python (job for Whoosh?)

On 3/4/2023 11:12 PM, Dino wrote: On 3/4/2023 10:43 PM, Dino wrote: I need fast text-search on a large (not huge, let's say 30k records totally) list of items. Here's a sample of my raw data (a list of US cars: model and make) I suspect I am really close to answering my own question...

Re: Cutting slices

On 2023-03-06 00:28, dn via Python-list wrote: On 06/03/2023 11.59, aapost wrote: On 3/5/23 17:43, Stefan Ram wrote:    The following behaviour of Python strikes me as being a bit    "irregular". A user tries to chop of sections from a string,    but does not use "split" because the separator

Re: Bug 3.11.x behavioral, open file buffers not flushed til file closed.

On Mon, 6 Mar 2023 at 12:41, Greg Ewing via Python-list wrote: > > On 6/03/23 1:02 pm, Cameron Simpson wrote: > > Also, fsync() need not expedite the data getting to disc. It is equally > > valid that it just blocks your programme _until_ the data have gone to > > disc. > > Or until it *thinks*

Re: Bug 3.11.x behavioral, open file buffers not flushed til file closed.

On 6/03/23 1:02 pm, Cameron Simpson wrote: Also, fsync() need not expedite the data getting to disc. It is equally valid that it just blocks your programme _until_ the data have gone to disc. Or until it *thinks* the data has gone to the disk. Some drives do buffering of their own, which may

Re: Bug 3.11.x behavioral, open file buffers not flushed til file closed.

On 05Mar2023 10:38, aapost wrote: Additionally (not sure if this still applies): flush() does not necessarily write the file’s data to disk. Use flush() followed by os.fsync() to ensure this behavior. Yes. You almost _never_ need or want this behaviour. A database tends to fsync at the end

Re: Cutting slices

On 05/03/2023 22:59, aapost wrote: On 3/5/23 17:43, Stefan Ram wrote:    The following behaviour of Python strikes me as being a bit    "irregular". A user tries to chop of sections from a string,    but does not use "split" because the separator might become    more complicated so that a

Re: Bug 3.11.x behavioral, open file buffers not flushed til file closed.

On 3/5/23, aapost wrote: > > If a file is still open, even if all the operations on the file have > ceased for a time, the tail of the written operation data does not get > flushed to the file until close is issued and the file closes cleanly. This is normal behavior for buffered file I/O.

Re: Cutting slices

On 06/03/2023 11.59, aapost wrote: On 3/5/23 17:43, Stefan Ram wrote:    The following behaviour of Python strikes me as being a bit    "irregular". A user tries to chop of sections from a string,    but does not use "split" because the separator might become    more complicated so that a

Re: Bug 3.11.x behavioral, open file buffers not flushed til file closed.

On 05Mar2023 09:35, aapost wrote: I have run in to this a few times and finally reproduced it. Whether it is as expected I am not sure since it is slightly on the user, but I can think of scenarios where this would be undesirable behavior.. This occurs on 3.11.1 and 3.11.2 using debian 12

Re: Cutting slices

On 3/5/23 17:43, Stefan Ram wrote: The following behaviour of Python strikes me as being a bit "irregular". A user tries to chop of sections from a string, but does not use "split" because the separator might become more complicated so that a regular expression will be required to

Re: Bug 3.11.x behavioral, open file buffers not flushed til file closed.

Am 05.03.23 um 15:35 schrieb aapost: I have run in to this a few times and finally reproduced it. Whether it is as expected I am not sure since it is slightly on the user, but I can think of scenarios where this would be undesirable behavior.. This occurs on 3.11.1 and 3.11.2 using debian 12

Re: Bug 3.11.x behavioral, open file buffers not flushed til file closed.

On 3/5/23 09:35, aapost wrote: Guess it could just be an annoying gotcha thing on me. calling at least f.flush() in any cases where an explicit close is delayed would be the solution. Additionally (not sure if this still applies): flush() does not necessarily write the file’s data to

Re: Fast full-text searching in Python (job for Whoosh?)

Here's the complete data file should anyone care. Acura,CL Acura,ILX Acura,Integra Acura,Legend Acura,MDX Acura,MDX Sport Hybrid Acura,NSX Acura,RDX Acura,RL Acura,RLX Acura,RLX Sport Hybrid Acura,RSX Acura,SLX Acura,TL Acura,TLX Acura,TSX Acura,Vigor Acura,ZDX Alfa Romeo,164 Alfa Romeo,4C

Bug 3.11.x behavioral, open file buffers not flushed til file closed.

I have run in to this a few times and finally reproduced it. Whether it is as expected I am not sure since it is slightly on the user, but I can think of scenarios where this would be undesirable behavior.. This occurs on 3.11.1 and 3.11.2 using debian 12 testing, in case the reasoning lingers

Fast full-text searching in Python (job for Whoosh?)

I need fast text-search on a large (not huge, let's say 30k records totally) list of items. Here's a sample of my raw data (a list of US cars: model and make) $ head all_cars_unique.csv\ Acura,CL Acura,ILX Acura,Integra Acura,Legend Acura,MDX Acura,MDX Sport

Re: Fast full-text searching in Python (job for Whoosh?)

On 3/4/2023 10:43 PM, Dino wrote: I need fast text-search on a large (not huge, let's say 30k records totally) list of items. Here's a sample of my raw data (a list of US cars: model and make) I suspect I am really close to answering my own question... >>> import time >>> lis =

[Python-announce] SCons 4.5.0 Released

A new SCons release, 4.5.0, is now available on the SCons download page: https://scons.org/pages/download.html Here is a summary of the changes since 4.4.0: NOTE: If you build with Python 3.10.0 and then rebuild with 3.10.1 (or higher), you may see unexpected rebuilds. This is due to

Re: Testing list sequence question -- thanks for the info

On 2023-03-05, Gabor Urban wrote: > Upgrading our Python to 3.7 seems to be out of question at the moment. Using an OrderedDict doesn't work for you? -- Grant -- https://mail.python.org/mailman/listinfo/python-list

Re: Cryptic software announcements (was: ANN: DIPY 1.6.0)

On 3/1/23 04:57, Rob Cliffe via Python-list wrote: I think it would be a good idea if software announcements would include a single paragraph (or maybe just a single sentence) summarizing what the software is and does. hp +1 Rob Cliffe Excellent adivce - and many of the

Re: Cryptic software announcements (was: ANN: DIPY 1.6.0)

On 01/03/2023 00:13, Peter J. Holzer wrote: [This isn't specifically about DIPY, I've noticed the same thing in other announcements] On 2023-02-28 13:48:56 -0500, Eleftherios Garyfallidis wrote: Hello all, We are excited to announce a new release of DIPY: DIPY 1.6.0 is out from the oven!

[Python-announce] Leo 6.7.2 released

Leo https://leo-editor.github.io/leo-editor/ 6.7.2 is now available on GitHub and pypi . Leo is an IDE, outliner and PIM . *The highlights of Leo 6.7.2* -

Testing list sequence question -- thanks for the info

Hi guys, Thank you very much for the accurate answer. Upgrading our Python to 3.7 seems to be out of question at the moment. I will check the requirement specification if the order of the keys is important at all. It could be a wish only. -- Urbán Gábor Linux is like a wigwam: no Gates, no