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 be
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
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
--
https:
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...
>>
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 m
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* th
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 i
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 o
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 regu
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. There'
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 regula
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 test
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
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 te
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 disk.
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
Alfa
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
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 Hybri
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 = [str(a**2+a*
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
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 announceme
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!
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 Win
23 matches
Mail list logo
