Re: File write, weird behaviour

[Thomas Passin]

On 2/19/2023 6:10 PM, Mats Wichmann wrote:

On 2/19/23 14:06, Dieter Maurer wrote:

Azizbek Khamdamov wrote at 2023-2-19 19:03 +0500:

...
Example 2 (weird behaviour)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code DOES NOT add new record TO THE BEGINNING of the
file IF FOLLOWED BY readline() and readlines()# Expected behaviour:
new content should be added to the beginning of the file (as in
Example 1)
file.write("new city\n")

file.readlines()
file.close()

I could not find anything in documentation to explain this strange
behaviour. Why is this happening?


The effect of "r+" (and friends) is specified by the C standard.

The Linux doc (of `fopen`) tells us that ANSI C requires that
a file positioning command (e.g. `seek`) must intervene
between input and output operations. Your example above violates
this condition. Therefore, weird behavior is to be expected.


If this isn't sufficiently described, someone should raise an issue 
against the Python docs.  I know that many concepts are "inherited from" 
environments generally in the POSIX space and the C language, because 
that's where Python was hatched (all of which makes perfect sense to me, 
who's been working in those spaces for...ever), but a Python programmer 
shouldn't have to read the ISO C standard (which is not free, although 
you can find copies on-line), or the POSIX standard (which also is not 
free, though manpages for systems like Linux cover the same material), 
in order to figure out how Python is going to work.


The Python docs say that text file behavior is done by Python, not C, 
and so its behavior will be consistent across all platforms.  I didn't 
find any words about this case, though.

--
https://mail.python.org/mailman/listinfo/python-list

[Python-announce] ANN: SciPy 1.10.1

[Tyler Reddy]

Hi all,

On behalf of the SciPy development team, I'm pleased to announce the
release of SciPy 1.10.1.

Sources and binary wheels can be found at:
https://pypi.org/project/scipy/
and at: https://github.com/scipy/scipy/releases/tag/v1.10.1

One of a few ways to install this release with pip:

pip install scipy==1.10.1

==
SciPy 1.10.1 Release Notes
==

SciPy 1.10.1 is a bug-fix release with no new features
compared to 1.10.0.

Authors
===
* Name (commits)
* alice (1) +
* Matt Borland (2) +
* Evgeni Burovski (2)
* CJ Carey (1)
* Ralf Gommers (9)
* Brett Graham (1) +
* Matt Haberland (5)
* Alex Herbert (1) +
* Ganesh Kathiresan (2) +
* Rishi Kulkarni (1) +
* Loïc Estève (1)
* Michał Górny (1) +
* Jarrod Millman (1)
* Andrew Nelson (4)
* Tyler Reddy (50)
* Pamphile Roy (2)
* Eli Schwartz (2)
* Tomer Sery (1) +
* Kai Striega (1)
* Jacopo Tissino (1) +
* windows-server-2003 (1)

A total of 21 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully
complete.

Issues closed for 1.10.1


* `#14980 `__: BUG: Johnson's
algorithm fails without negative cycles
* `#17670 `__: Failed to
install on Raspberry Pi (ARM) 32bit in 3.11.1
* `#17715 `__:
scipy.stats.bootstrap broke with statistic returning multiple...
* `#17716 `__: BUG:
interpolate.interpn fails with read only input
* `#17718 `__: BUG:
RegularGridInterpolator 2D mixed precision crashes
* `#17727 `__: BUG:
RegularGridInterpolator does not work on non-native byteorder...
* `#17736 `__: BUG: SciPy
requires OpenBLAS even when building against a different...
* `#17775 `__: BUG: Asymptotic
computation of ksone.sf has intermediate overflow
* `#17782 `__: BUG: Segfault
in scipy.sparse.csgraph.shortest_path() with v1.10.0
* `#17795 `__: BUG:
stats.pearsonr one-sided hypothesis yields incorrect p-value...
* `#17801 `__: BUG:
stats.powerlaw.fit: raises OverflowError
* `#17808 `__: BUG: name of
cython executable is hardcoded in _build_utils/cythoner.py
* `#17811 `__: CI job with
numpy nightly build failing on missing \`_ArrayFunctionDispatcher.__code__\`
* `#17839 `__: BUG: 1.10.0
tests fail on i386 and other less common arches
* `#17896 `__: DOC: publicly
expose \`multivariate_normal\` attributes \`mean\`...
* `#17934 `__: BUG: meson
\`__config__\` generation - truncated unicode characters
* `#17938 `__: BUG:
\`scipy.stats.qmc.LatinHypercube\` with \`optimization="random-cd"\`...


Pull requests for 1.10.1
---

* `#17712 `__: REL, MAINT:
prepare for 1.10.1
* `#17717 `__: BUG: allow
readonly input to interpolate.interpn
* `#17721 `__: MAINT: update
\`meson-python\` upper bound to <0.13.0
* `#17726 `__: BUG:
interpolate/RGI: upcast float32 to float64
* `#17735 `__: MAINT:
stats.bootstrap: fix BCa with vector-valued statistics
* `#17743 `__: DOC: improve the
docs on using BLAS/LAPACK libraries with Meson
* `#1 `__: BLD: link to
libatomic if necessary
* `#17783 `__: BUG: Correct
intermediate overflow in KS one asymptotic in SciPy.stats
* `#17790 `__: BUG: signal: fix
check_malloc extern declaration type
* `#17797 `__: MAINT:
stats.pearsonr: correct p-value with negative correlation...
* `#17800 `__: [sparse.csgraph]
Fix a bug in dijkstra and johnson algorithm
* `#17803 `__: MAINT: add
missing \`__init__.py\` in test folder
* `#17806 `__: MAINT:
stats.powerlaw.fit: fix overflow when np.min(data)==0
* `#17810 `__: BLD: use Meson's
found cython instead of a wrapper script
* `#17831 

Re: File write, weird behaviour

[Mats Wichmann]

On 2/19/23 14:06, Dieter Maurer wrote:

Azizbek Khamdamov wrote at 2023-2-19 19:03 +0500:

...
Example 2 (weird behaviour)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code DOES NOT add new record TO THE BEGINNING of the
file IF FOLLOWED BY readline() and readlines()# Expected behaviour:
new content should be added to the beginning of the file (as in
Example 1)
file.write("new city\n")

file.readlines()
file.close()

I could not find anything in documentation to explain this strange
behaviour. Why is this happening?


The effect of "r+" (and friends) is specified by the C standard.

The Linux doc (of `fopen`) tells us that ANSI C requires that
a file positioning command (e.g. `seek`) must intervene
between input and output operations. Your example above violates
this condition. Therefore, weird behavior is to be expected.


If this isn't sufficiently described, someone should raise an issue 
against the Python docs.  I know that many concepts are "inherited from" 
environments generally in the POSIX space and the C language, because 
that's where Python was hatched (all of which makes perfect sense to me, 
who's been working in those spaces for...ever), but a Python programmer 
shouldn't have to read the ISO C standard (which is not free, although 
you can find copies on-line), or the POSIX standard (which also is not 
free, though manpages for systems like Linux cover the same material), 
in order to figure out how Python is going to work.

--
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Dieter Maurer]

Azizbek Khamdamov wrote at 2023-2-19 19:03 +0500:
> ...
>Example 2 (weird behaviour)
>
>file = open("D:\Programming\Python\working_with_files\cities.txt",
>'r+') ## contains list cities
># the following code DOES NOT add new record TO THE BEGINNING of the
>file IF FOLLOWED BY readline() and readlines()# Expected behaviour:
>new content should be added to the beginning of the file (as in
>Example 1)
>file.write("new city\n")
>
>file.readlines()
>file.close()
>
>I could not find anything in documentation to explain this strange
>behaviour. Why is this happening?

The effect of "r+" (and friends) is specified by the C standard.

The Linux doc (of `fopen`) tells us that ANSI C requires that
a file positioning command (e.g. `seek`) must intervene
between input and output operations. Your example above violates
this condition. Therefore, weird behavior is to be expected.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Thomas Passin]

On 2/19/2023 2:31 PM, Chris Angelico wrote:

On Mon, 20 Feb 2023 at 06:24, Thomas Passin  wrote:


On 2/19/2023 1:53 PM, Chris Angelico wrote:

On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov
 wrote:


Example 1 (works as expected)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities


Side note: You happened to get lucky with P, w, and c, but for the
future, I recommend using forward slashes for your paths:

open("D:/Programming/Python/working_with_files/cities.txt", "r+")

Otherwise, you may run into annoying and hard-to-solve problems. Or
alternatively, you'll upgrade to a newer Python and start getting
warnings, which would at least tell you that there's a problem.


Or use r'...' strings.  If you are copying a path to clipboard from
Windows Explorer - a fairly common operation - it's much easier to
prepend the "r" than to change all the backslashes to forward slashes.



Yep, either way. I personally prefer using forward slashes since
there's no way to end an r-string with a single backslash, which is
often useful when building a path:

# won't work
path = r"c:\path\to\some\"
open(path + "file")

# will work
path = "c:/path/to/some/"
open(path + "file")


Never hit that one before.  To be classified as "Learn something new 
every day"!


I've been using pathlib more lately.  It does clever things with "/" -

>>> from pathlib import PurePath
>>> p1 = PurePath('c:/this') / 'is' / 'a' /'test'
>>> p1
PureWindowsPath('c:/this/is/a/test')
# on Linux, would be a PurePosixPath

and also

>>> p2 = PurePath('c:/this/') /'is' /'a' /'test'
>>> p2
PureWindowsPath('c:/this/is/a/test')

Despite the apparent forward slashes, the right separators get used for 
the OS. And the Paths can be used with open(), etc.



--
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[MRAB]

On 2023-02-19 19:31, Chris Angelico wrote:

On Mon, 20 Feb 2023 at 06:24, Thomas Passin  wrote:


On 2/19/2023 1:53 PM, Chris Angelico wrote:
> On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov
>  wrote:
>>
>> Example 1 (works as expected)
>>
>> file = open("D:\Programming\Python\working_with_files\cities.txt",
>> 'r+') ## contains list cities
>
> Side note: You happened to get lucky with P, w, and c, but for the
> future, I recommend using forward slashes for your paths:
>
> open("D:/Programming/Python/working_with_files/cities.txt", "r+")
>
> Otherwise, you may run into annoying and hard-to-solve problems. Or
> alternatively, you'll upgrade to a newer Python and start getting
> warnings, which would at least tell you that there's a problem.

Or use r'...' strings.  If you are copying a path to clipboard from
Windows Explorer - a fairly common operation - it's much easier to
prepend the "r" than to change all the backslashes to forward slashes.



Yep, either way. I personally prefer using forward slashes since
there's no way to end an r-string with a single backslash, which is
often useful when building a path:

# won't work
path = r"c:\path\to\some\"
open(path + "file")

# will work
path = "c:/path/to/some/"
open(path + "file")

When I build a path, I use os.path.join, so it's only a problem if one 
of the strings refers to the root of a drive, e.g. "C:\\".

--
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Chris Angelico]

On Mon, 20 Feb 2023 at 06:24, Thomas Passin  wrote:
>
> On 2/19/2023 1:53 PM, Chris Angelico wrote:
> > On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov
> >  wrote:
> >>
> >> Example 1 (works as expected)
> >>
> >> file = open("D:\Programming\Python\working_with_files\cities.txt",
> >> 'r+') ## contains list cities
> >
> > Side note: You happened to get lucky with P, w, and c, but for the
> > future, I recommend using forward slashes for your paths:
> >
> > open("D:/Programming/Python/working_with_files/cities.txt", "r+")
> >
> > Otherwise, you may run into annoying and hard-to-solve problems. Or
> > alternatively, you'll upgrade to a newer Python and start getting
> > warnings, which would at least tell you that there's a problem.
>
> Or use r'...' strings.  If you are copying a path to clipboard from
> Windows Explorer - a fairly common operation - it's much easier to
> prepend the "r" than to change all the backslashes to forward slashes.
>

Yep, either way. I personally prefer using forward slashes since
there's no way to end an r-string with a single backslash, which is
often useful when building a path:

# won't work
path = r"c:\path\to\some\"
open(path + "file")

# will work
path = "c:/path/to/some/"
open(path + "file")

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Peter J. Holzer]

On 2023-02-19 12:59:43 -0500, Thomas Passin wrote:
> On 2/19/2023 11:57 AM, Axy via Python-list wrote:
> > Looks like the data to be written is buffered, so actual write takes
> > place after readlines(), when close() flushes buffers.
> > 
> > See io package documentation, BufferedIOBase.
> > 
> > The solution is file.flush() after file.write()
> 
> Another possibility, from the Python docs:
> 
> "...TextIOWrapper (i.e., files opened with mode='r+') ... To disable
> buffering in TextIOWrapper, consider using the write_through flag for
> io.TextIOWrapper.reconfigure()"

That actually doesn't help (I tried it before writing my answer). The
binary layer below the text layer also buffers ...

> Also from the docs:
> 
> "Warning: Calling f.write() without using the with keyword or calling
> f.close() might result in the arguments of f.write() not being completely
> written to the disk, even if the program exits successfully."

He does call file.close():

> > > file.close()

so that doesn't seem relevant.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Thomas Passin]

On 2/19/2023 1:53 PM, Chris Angelico wrote:

On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov
 wrote:


Example 1 (works as expected)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities


Side note: You happened to get lucky with P, w, and c, but for the
future, I recommend using forward slashes for your paths:

open("D:/Programming/Python/working_with_files/cities.txt", "r+")

Otherwise, you may run into annoying and hard-to-solve problems. Or
alternatively, you'll upgrade to a newer Python and start getting
warnings, which would at least tell you that there's a problem.


Or use r'...' strings.  If you are copying a path to clipboard from 
Windows Explorer - a fairly common operation - it's much easier to 
prepend the "r" than to change all the backslashes to forward slashes.


--
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Chris Angelico]

On Mon, 20 Feb 2023 at 03:41, Azizbek Khamdamov
 wrote:
>
> Example 1 (works as expected)
>
> file = open("D:\Programming\Python\working_with_files\cities.txt",
> 'r+') ## contains list cities

Side note: You happened to get lucky with P, w, and c, but for the
future, I recommend using forward slashes for your paths:

open("D:/Programming/Python/working_with_files/cities.txt", "r+")

Otherwise, you may run into annoying and hard-to-solve problems. Or
alternatively, you'll upgrade to a newer Python and start getting
warnings, which would at least tell you that there's a problem.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Thomas Passin]

On 2/19/2023 11:57 AM, Axy via Python-list wrote:
Looks like the data to be written is buffered, so actual write takes 
place after readlines(), when close() flushes buffers.


See io package documentation, BufferedIOBase.

The solution is file.flush() after file.write()


Another possibility, from the Python docs:

"...TextIOWrapper (i.e., files opened with mode='r+') ... To disable 
buffering in TextIOWrapper, consider using the write_through flag for 
io.TextIOWrapper.reconfigure()"



Also from the docs:

"Warning: Calling f.write() without using the with keyword or calling 
f.close() might result in the arguments of f.write() not being 
completely written to the disk, even if the program exits successfully."


I realize that in the example, close() was called ... but not 
immediately after the write().


Can't deny, such a behaviour looks utterly weird. Try to avoid designing 
your software this way.


Axy.

On 19/02/2023 14:03, Azizbek Khamdamov wrote:

Example 1 (works as expected)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code adds new record to the beginning of the file,
expected behaviour
file.write("new city\n")

file.close()


Example 2 (weird behaviour)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code DOES NOT add new record TO THE BEGINNING of the
file IF FOLLOWED BY readline() and readlines()# Expected behaviour:
new content should be added to the beginning of the file (as in
Example 1)
file.write("new city\n")

file.readlines()
file.close()

I could not find anything in documentation to explain this strange
behaviour. Why is this happening?


--
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[MRAB]

On 2023-02-19 14:03, Azizbek Khamdamov wrote:

Example 1 (works as expected)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code adds new record to the beginning of the file,
expected behaviour
file.write("new city\n")

file.close()


Example 2 (weird behaviour)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code DOES NOT add new record TO THE BEGINNING of the
file IF FOLLOWED BY readline() and readlines()# Expected behaviour:
new content should be added to the beginning of the file (as in
Example 1)
file.write("new city\n")

file.readlines()
file.close()

I could not find anything in documentation to explain this strange
behaviour. Why is this happening?


It works correctly if you use file.flush() or file.tell() before 
switching from writing to reading.

--
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Peter J. Holzer]

On 2023-02-19 16:57:02 +, Axy via Python-list wrote:
> Looks like the data to be written is buffered, so actual write takes place
> after readlines(), when close() flushes buffers.
> 
> See io package documentation, BufferedIOBase.
> 
> The solution is file.flush() after file.write()

Or alternatively, file.seek() to the intended position when switching
between reading and writing. (The C standard says you have to do this. I
can't find it in the Python docs, but apparently Python behaves the
same.)

> On 19/02/2023 14:03, Azizbek Khamdamov wrote:
> > Example 2 (weird behaviour)
> > 
> > file = open("D:\Programming\Python\working_with_files\cities.txt",
> > 'r+') ## contains list cities
> > # the following code DOES NOT add new record TO THE BEGINNING of the
> > file IF FOLLOWED BY readline() and readlines()# Expected behaviour:
> > new content should be added to the beginning of the file (as in
> > Example 1)
> > file.write("new city\n")

Also note that you can't ADD anything at the beginning (or in the
middle) of a file. You will overwrite existing content if you try this.
You can only add at the end of the file. If you want to insert
something, you have to rewrite everything from that position.

(So typically, for small files you wouldn't update a file in place, you
would just replace it completely. For large data sets which need to be
updated you would generally use some kind of database.)

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: File write, weird behaviour

[Axy via Python-list]

Looks like the data to be written is buffered, so actual write takes 
place after readlines(), when close() flushes buffers.


See io package documentation, BufferedIOBase.

The solution is file.flush() after file.write()

Can't deny, such a behaviour looks utterly weird. Try to avoid designing 
your software this way.


Axy.

On 19/02/2023 14:03, Azizbek Khamdamov wrote:

Example 1 (works as expected)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code adds new record to the beginning of the file,
expected behaviour
file.write("new city\n")

file.close()


Example 2 (weird behaviour)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code DOES NOT add new record TO THE BEGINNING of the
file IF FOLLOWED BY readline() and readlines()# Expected behaviour:
new content should be added to the beginning of the file (as in
Example 1)
file.write("new city\n")

file.readlines()
file.close()

I could not find anything in documentation to explain this strange
behaviour. Why is this happening?

--
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] Python 3.11.2, 3.10.10

[Pablo Galindo Salgado]

   Apologies!
   It seems that I added python-comitters and python-announce but forgot to
   add python-dev. Here is the email to python-announce:

   [1]Mailman 3 [RELEASE]
   Python 3.11.2, Python
   3.10.10 and 3.12.0 alpha 5
   are available -  [2]favicon.ico
   Python-announce-list -
   python.org
   mail.python.org

   Apologies for the confusion!
   Regards from cloudy London,
   Pablo Galindo Salgado 
   Pablo Galindo Salgado

 On 18 Feb 2023, at 11:14, אורי  wrote:

 
 Hi,
 I was surprised that Python 3.11.2 and 3.10.10 have been released
 without a notice to this mailing list. What happened?
 Thanks,
 Uri.
 אורי
 [3]u...@speedy.net
 On Wed, Dec 7, 2022 at 1:03 AM Łukasz Langa <[4]luk...@langa.pl> wrote:

   Greetings! We bring you a slew of releases this fine Saint Nicholas /
   Sinterklaas day. Six simultaneous releases has got to be some record.
   There’s one more record we broke this time, you’ll see below.

   In any case, updating is recommended due to security content:

   3.7 - 3.12: gh-98739
   <[5]https://github.com/python/cpython/issues/98739>: Updated bundled
   libexpat to 2.5.0 to fix CVE-2022-43680
   <[6]https://nvd.nist.gov/vuln/detail/CVE-2022-43680> (heap
   use-after-free).
   3.7 - 3.12: gh-98433
   <[7]https://github.com/python/cpython/issues/98433>: The IDNA codec
   decoder used on DNS hostnames by socket or asyncio related name
   resolution functions no longer involves a quadratic algorithm to fix
   CVE-2022-45061 <[8]https://nvd.nist.gov/vuln/detail/CVE-2022-45061>.
   This prevents a potential CPU denial of service if an out-of-spec
   excessive length hostname involving bidirectional characters were
   decoded. Some protocols such as urllib http 3xx redirects potentially
   allow for an attacker to supply such a name.
   3.7 - 3.12: gh-11
   <[9]https://github.com/python/cpython/issues/11>: python -m
   http.server no longer allows terminal control characters sent within a
   garbage request to be printed to the stderr server log.
   3.8 - 3.12: gh-87604
   <[10]https://github.com/python/cpython/issues/87604>: Avoid publishing
   list of active per-interpreter audit hooks via the gc module.
   3.9 - 3.10 (already released in 3.11+ before): gh-97514
   <[11]https://github.com/python/cpython/issues/97514>: On Linux the
   multiprocessing module returns to using filesystem backed unix domain
   sockets for communication with the forkserver process instead of the
   Linux abstract socket namespace. Only code that chooses to use the
   “forkserver” start method is affected. This prevents Linux
   CVE-2022-42919 <[12]https://nvd.nist.gov/vuln/detail/CVE-2022-42919>
   (potential privilege escalation) as abstract sockets have no
   permissions and could allow any user on the system in the same network
   namespace (often the whole system) to inject code into the
   multiprocessing forkserver process. This was a potential privilege
   escalation. Filesystem based socket permissions restrict this to the
   forkserver process user as was the default in Python 3.8 and earlier.
   3.7 - 3.10: gh-98517
   <[13]https://github.com/python/cpython/issues/98517>: Port XKCP’s fix
   for the buffer overflows in SHA-3 to fix CVE-2022-37454
   <[14]https://nvd.nist.gov/vuln/detail/CVE-2022-37454>.
   3.7 - 3.9 (already released in 3.10+ before): gh-68966
   <[15]https://github.com/python/cpython/issues/68966>: The deprecated
   mailcap module now refuses to inject unsafe text (filenames, MIME
   types, parameters) into shell commands to address CVE-2015-20107
   <[16]https://nvd.nist.gov/vuln/detail/CVE-2015-20107>. Instead of
   using such text, it will warn and act as if a match was not found (or
   for test commands, as if the test failed).
    
<[17]https://discuss.python.org/t/python-3-11-1-3-10-9-3-9-16-3-8-16-3-7-16-and-3-12-0-alpha-3-are-now-available/21724#python-3120-alpha-3-1>Python
   3.12.0 alpha 3

   Get it here, read the change log, sing a GPT-3-generated Sinterklaas
   song:

   [18]https://www.python.org/downloads/release/python-3120a3/
   <[19]https://www.python.org/downloads/release/python-3120a3/>

   216 new commits since 3.12.0 alpha 2 last month.

    
<[20]https://discuss.python.org/t/python-3-11-1-3-10-9-3-9-16-3-8-16-3-7-16-and-3-12-0-alpha-3-are-now-available/21724#python-3111-2>Python
   3.11.1

   Get it here, see the change log, read the recipe for quark soup:

   [21]https://www.python.org/downloads/release/python-3111/
   <[22]https://www.python.org/downloads/release/python-3111/>

   A whopping 495 new commits since 3.11.0. This is a massive increase of
   changes comparing to 3.10 at the same stage in the release cycle:
   there were “only” 

File write, weird behaviour

[Azizbek Khamdamov]

Example 1 (works as expected)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code adds new record to the beginning of the file,
expected behaviour
file.write("new city\n")

file.close()


Example 2 (weird behaviour)

file = open("D:\Programming\Python\working_with_files\cities.txt",
'r+') ## contains list cities
# the following code DOES NOT add new record TO THE BEGINNING of the
file IF FOLLOWED BY readline() and readlines()# Expected behaviour:
new content should be added to the beginning of the file (as in
Example 1)
file.write("new city\n")

file.readlines()
file.close()

I could not find anything in documentation to explain this strange
behaviour. Why is this happening?
-- 
https://mail.python.org/mailman/listinfo/python-list