Re: from __future__ import annotations bug?

[Inada Naoki via Python-list]

> but does this mean that even with PEP 649 that forward references will
> still be needed?

Yes. Both of PEP 563 and PEP 649 solves not all forward reference issues.

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

Re: from __future__ import annotations bug?

[Joseph Garvin via Python-list]

Should mention this also affects Protocol[Buzz]

On Fri, Jun 30, 2023, 5:35 PM Joseph Garvin  wrote:

> ```
> from __future__ import annotations
> from typing import Generic, TypeVar
>
> T = TypeVar("T")
> class Foo(Generic[T]): ...
> class Bar(Foo[Buzz]): ... # NameError here
> class Buzz: ...
> ```
>
> This will error, despite the __future__ import, because cpython is trying
> to look up Buzz before it's defined, even though we have supposedly
> prevented annotations from being processed. I realize that Class[Args] is
> allowed in that area in general and isn't always type annotation related,
> but does this mean that even with PEP 649 that forward references will
> still be needed?
>
-- 
https://mail.python.org/mailman/listinfo/python-list

from __future__ import annotations bug?

[Joseph Garvin via Python-list]

```
from __future__ import annotations
from typing import Generic, TypeVar

T = TypeVar("T")
class Foo(Generic[T]): ...
class Bar(Foo[Buzz]): ... # NameError here
class Buzz: ...
```

This will error, despite the __future__ import, because cpython is trying
to look up Buzz before it's defined, even though we have supposedly
prevented annotations from being processed. I realize that Class[Args] is
allowed in that area in general and isn't always type annotation related,
but does this mean that even with PEP 649 that forward references will
still be needed?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in io.TextIOWrapper?

[Jon Ribbens via Python-list]

On 2023-06-19, Inada Naoki  wrote:
> I checked TextIOWrapper source code and confirmed that it doesn't call
> encoder.write(text, finish=True) on close.
> Since TextIOWrapper allows random access, it is difficult to call it
> automatically. So please think it as just limitation rather than bug.
> Please use codec and binary file manually for now.

It could call it on seek() or flush(). It seems like a definite bug to
me, in that its behaviour appears clearly incorrect - it's just that
there isn't an entirely obvious "100% correct" behaviour to choose.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in io.TextIOWrapper?

[Inada Naoki via Python-list]

I checked TextIOWrapper source code and confirmed that it doesn't call
encoder.write(text, finish=True) on close.
Since TextIOWrapper allows random access, it is difficult to call it
automatically. So please think it as just limitation rather than bug.
Please use codec and binary file manually for now.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in io.TextIOWrapper?

[Inada Naoki via Python-list]

You can use file instead of BytesIO

2023年6月20日(火) 3:05 Peter J. Holzer via Python-list :

> On 2023-06-20 02:15:00 +0900, Inada Naoki via Python-list wrote:
> > stream.flush() doesn't mean final output.
> > Try stream.close()
>
> After close() the value isn't available any more:
>
> Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import io
> >>> buffer = io.BytesIO()
> >>> stream = io.TextIOWrapper(buffer, encoding='idna')
> >>> stream.write('abc.example.com')
> 15
> >>> stream.close()
> >>> buffer.getvalue()
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: I/O operation on closed file.
>
> hp
>
> --
>_  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |   challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in io.TextIOWrapper?

[Peter J. Holzer via Python-list]

On 2023-06-20 02:15:00 +0900, Inada Naoki via Python-list wrote:
> stream.flush() doesn't mean final output.
> Try stream.close()

After close() the value isn't available any more:

Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> buffer = io.BytesIO()
>>> stream = io.TextIOWrapper(buffer, encoding='idna')
>>> stream.write('abc.example.com')
15
>>> stream.close()
>>> buffer.getvalue()
Traceback (most recent call last):
  File "", line 1, in 
ValueError: I/O operation on closed file.

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: Bug in io.TextIOWrapper?

[Inada Naoki via Python-list]

stream.flush() doesn't mean final output.
Try stream.close()

2023年6月20日(火) 1:40 Jon Ribbens via Python-list :

> io.TextIOWrapper() wraps a binary stream so you can write text to it.
> It takes an 'encoding' parameter, which it uses to look up the codec
> in the codecs registry, and then it uses the IncrementalEncoder and
> IncrementalDecoder classes for the appropriate codec.
>
> The IncrementalEncoder.encode() function is given the object to encode
> of course, and also an optional second parameter which indicates if
> this is the final output.
>
> The bug is that TextIOWrapper() never sets the second parameter to
> indicate that the output is complete - not even if you call close().
>
> Example:
>
> >>> import io
> >>> buffer = io.BytesIO()
> >>> stream = io.TextIOWrapper(buffer, encoding='idna')
> >>> stream.write('abc.example.com')
> 15
> >>> stream.flush()
> >>> buffer.getvalue()
> b'abc.example.'
>
> Obviously using the 'idna' wrapper as an encoding on a stream is a bit
> unlikely, but nevertheless any other codec which cares about the 'final'
> parameter will also have this problem.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Bug in io.TextIOWrapper?

[Jon Ribbens via Python-list]

io.TextIOWrapper() wraps a binary stream so you can write text to it.
It takes an 'encoding' parameter, which it uses to look up the codec
in the codecs registry, and then it uses the IncrementalEncoder and
IncrementalDecoder classes for the appropriate codec.

The IncrementalEncoder.encode() function is given the object to encode
of course, and also an optional second parameter which indicates if
this is the final output.

The bug is that TextIOWrapper() never sets the second parameter to
indicate that the output is complete - not even if you call close().

Example:

>>> import io
>>> buffer = io.BytesIO()
>>> stream = io.TextIOWrapper(buffer, encoding='idna')
>>> stream.write('abc.example.com')
15
>>> stream.flush()
>>> buffer.getvalue()
b'abc.example.'

Obviously using the 'idna' wrapper as an encoding on a stream is a bit
unlikely, but nevertheless any other codec which cares about the 'final'
parameter will also have this problem.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Dieter Maurer]

aapost wrote at 2023-3-5 09:35 -0500:
> ...
>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: the buffer is flushed if one of the following conditions
are met:
1. you call `flush`
2. the buffer overflows
3. the file is closed.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[aapost]

On 3/5/23 19:02, Cameron Simpson wrote:

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 of a transaction and at other critical points.


However, once you've `flush()`ed the file the data are then in the hands 
of the OS, to get to disc in a timely but efficient fashion. Calling 
fsync(), like calling flush(), affects writing _efficiency_ by depriving 
the OS (or for flush(), the Python I/O buffering system) the opportunity 
to bundle further data efficiency. It will degrade the overall performance.


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. I practice it probably does expedite things slightly, but the real 
world effect is that your pogramme will gratuitously block anyway, when 
it could just get on with its work, secure in the knowledge that the OS 
has its back.


flush() is for causality - ensuring the data are on their way so that 
some external party _will_ see them rather than waiting forever for data 
with are lurking in the buffer.  If that external party, for you, is an 
end user tailing a log file, then you might want to flush(0 at the end 
of every line.  Note that there is a presupplied line-buffering mode you 
can choose which will cause a file to flush like that for you 
automatically.


So when you flush is a policy decision which you can make either during 
the programme flow or to a less flexible degree when you open the file.


As an example of choosing-to-flush, here's a little bit of code in a 
module I use for writing packet data to a stream (eg a TCP connection):

https://github.com/cameron-simpson/css/blob/00ab1a8a64453dc8a39578b901cfa8d1c75c3de2/lib/python/cs/packetstream.py#L624

Starting at line 640: `if Q.empty():` it optionally pauses briefly to 
see if more packets are coming on the source queue. If another arrives, 
the flush() is _skipped_, and the decision to flush made again after the 
next packet is transcribed. In this way a busy source of packets can 
write maximally efficient data (full buffers) as long as there's new 
data coming from the queue, but if the queue is empty and stays empty 
for more that `grace` seconds we flush anyway so that the receiver 
_will_ still see the latest packet.


Cheers,
Cameron Simpson 


Thanks for the details. And yes, that above quote was from a 
non-official doc without a version reference that several forum posts 
were referencing, with no further reasoning as to why they make the 
suggestion or to what importance it was (for the uninformed trying to 
parse it, the suggestion could be because of anything, like python 
lacking something that maybe was fixed, or who knows.) Thanks.



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

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

[aapost]

On 3/5/23 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 testing, in case the 
reasoning lingers somewhere else.


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.


2 methods to recreate - 1st run from interpreter directly:

f = open("abc", "w")
for i in range(5):
   f.write(str(i) + "\n")

you can cat the file and see it stops at 49626 until you issue an f.close()

a script to recreate:

f = open("abc", "w")
for i in range(5):
   f.write(str(i) + "\n")
while(1):
   pass

cat out the file and same thing, stops at 49626. a ctrl-c exit closes 
the files cleanly, but if the file exits uncleanly, i.e. a kill command 
or something else catastrophic. the remaining buffer is lost.


Of course one SHOULD manage the closing of their files and this is 
partially on the user, but if by design something is hanging on to a 
file while it is waiting for something, then a crash occurs, they lose a 
portion of what was assumed already complete...


>Cameron
>Eryk

Yeah, I later noticed open() has the buffering option in the docs, and 
the warning on a subsequent page:


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 will have to set the buffer arg to 1. I just hadn't thought about 
buffering in quite a while since python just handles most of the things 
lower level languages don't. I guess my (of course incorrect) 
assumptions would have leaned toward some sort of auto handling of the 
flush, or a non-buffer default (not saying it should).


And I understand why it is the way it is from a developer standpoint, 
it's sort of a mental thing in the moment, I was in a sysadmin way of 
thinking, switching around from doing things in bash with multiple 
terminals, forgetting the fundamentals of what the python interpreter is 
vs a sequence of terminal commands.


That being said, while "with" is great for many use cases, I think its 
overuse causes concepts like flush and the underlying "whys" to atrophy 
(especially since it is obviously a concept that is still important). It 
also doesn't work well when doing quick and dirty work in the 
interpreter to build a file on the fly with a sequence of commands you 
haven't completely thought through yet, in addition to the not wanting 
to close yet, the subsequent indention requirement is annoying. f = 
open("fn", "w", 1) will be the go to for that type of work since now I 
know. Again, just nitpicking, lol.


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

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

[Weatherby,Gerard]

Add f.reconfigure it you want line buffering in your example:

f = open("abc", "w")
f.reconfigure(line_buffering=True)
for i in range(5):
   f.write(str(i) + "\n")

More Pythonic would be:

with open("abc", "w") as f:
   for i in range(5000):
  print(i,file=f)

From: Python-list  on 
behalf of aapost 
Date: Sunday, March 5, 2023 at 6:33 PM
To: python-list@python.org 
Subject: Bug 3.11.x behavioral, open file buffers not flushed til file closed.
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

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 somewhere else.

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.

2 methods to recreate - 1st run from interpreter directly:

f = open("abc", "w")
for i in range(5):
   f.write(str(i) + "\n")

you can cat the file and see it stops at 49626 until you issue an f.close()

a script to recreate:

f = open("abc", "w")
for i in range(5):
   f.write(str(i) + "\n")
while(1):
   pass

cat out the file and same thing, stops at 49626. a ctrl-c exit closes
the files cleanly, but if the file exits uncleanly, i.e. a kill command
or something else catastrophic. the remaining buffer is lost.

Of course one SHOULD manage the closing of their files and this is
partially on the user, but if by design something is hanging on to a
file while it is waiting for something, then a crash occurs, they lose a
portion of what was assumed already complete...
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!kBYMol9JmMVwZD0iSoeeR1fYTiX8DEG-V4LBm4aAw4IJQ6Am4Ql_HYRZOeO8XK3kZvq2_adnid-FeoHr37Tw2I7k$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!kBYMol9JmMVwZD0iSoeeR1fYTiX8DEG-V4LBm4aAw4IJQ6Am4Ql_HYRZOeO8XK3kZvq2_adnid-FeoHr37Tw2I7k$>
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Barry]

> On 6 Mar 2023, at 01:42, 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* the data has gone to the disk. Some drives
> do buffering of their own, which may impose additional delays
> before the data actually gets written.

This used to be an issue until Microsoft refused to certify and drive that lied 
about when data was persisted to the medium. WHQL?

That had the effect of stooping driver manufactures having firmware to win 
benchmarking.

Now the OS will use the commands to the drive that allow the OS to know the 
data is safe.

Barry

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

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

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

[Chris Angelico]

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* the data has gone to the disk. Some drives
> do buffering of their own, which may impose additional delays
> before the data actually gets written.
>

Sadly true. Usually with SSDs. Unfortunately, at that point, there's
nothing ANYONE can do about it, since the OS is deceived as much as
anyone else.

But Cameron is completely right in that fsync's primary job is "block
until" rather than "do this sooner". Adding fsync calls might possibly
cause a flush when one otherwise wouldn't have happened, but generally
they'll slow things down in the interests of reliability.

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

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

[Greg Ewing via Python-list]

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 impose additional delays
before the data actually gets written.

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

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

[Cameron Simpson]

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 of a transaction and at other critical points.


However, once you've `flush()`ed the file the data are then in the hands 
of the OS, to get to disc in a timely but efficient fashion. Calling 
fsync(), like calling flush(), affects writing _efficiency_ by depriving 
the OS (or for flush(), the Python I/O buffering system) the opportunity 
to bundle further data efficiency. It will degrade the overall 
performance.


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. I practice it probably does expedite things slightly, but the real 
world effect is that your pogramme will gratuitously block anyway, when 
it could just get on with its work, secure in the knowledge that the OS 
has its back.


flush() is for causality - ensuring the data are on their way so that 
some external party _will_ see them rather than waiting forever for data 
with are lurking in the buffer.  If that external party, for you, is an 
end user tailing a log file, then you might want to flush(0 at the end 
of every line.  Note that there is a presupplied line-buffering mode you 
can choose which will cause a file to flush like that for you 
automatically.


So when you flush is a policy decision which you can make either during 
the programme flow or to a less flexible degree when you open the file.


As an example of choosing-to-flush, here's a little bit of code in a 
module I use for writing packet data to a stream (eg a TCP connection):

https://github.com/cameron-simpson/css/blob/00ab1a8a64453dc8a39578b901cfa8d1c75c3de2/lib/python/cs/packetstream.py#L624

Starting at line 640: `if Q.empty():` it optionally pauses briefly to 
see if more packets are coming on the source queue. If another arrives, 
the flush() is _skipped_, and the decision to flush made again after the 
next packet is transcribed. In this way a busy source of packets can 
write maximally efficient data (full buffers) as long as there's new 
data coming from the queue, but if the queue is empty and stays empty 
for more that `grace` seconds we flush anyway so that the receiver 
_will_ still see the latest packet.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

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

[Eryk Sun]

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's no timer set to
flush the buffer after operations have "ceased for a time". It
automatically flushes only when the buffer is full or, for line
buffering, when a newline is written.

The default buffer size is based on the raw file object's _blksize
attribute. If st_blksize can't be determined via fstat(), the default
_blksize is 8 KiB.

Here's an example on Linux. In this example, the buffer size is 4 KiB.

>>> f = open('abc', 'w')
>>> os.fstat(f.fileno()).st_blksize
4096
>>> f.buffer.raw._blksize
4096
>>> f.writelines(f'{i}\n' for i in range(5))
>>> with open('abc') as g: g.readlines()[-1]
...
'49626\n'

>>> pre_flush_size = os.path.getsize('abc')
>>> f.flush()
>>> post_flush_size = os.path.getsize('abc')
>>> post_flush_size - pre_flush_size
2238

Verify that this makes sense, based on what was left in the buffer
prior to flushing:

>>> remaining_lines = 5 - 49626 - 1
>>> bytes_per_line = 6
>>> remaining_lines * bytes_per_line
2238
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Cameron Simpson]

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 testing, in case the 
reasoning lingers somewhere else.


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.


Yes, because files are _buffered_ by default. See the `buffering` 
parameter to the open() function in the docs.



2 methods to recreate - 1st run from interpreter directly:

f = open("abc", "w")
for i in range(5):
 f.write(str(i) + "\n")

you can cat the file and see it stops at 49626 until you issue an f.close()


Or until you issue an `f.flush()`. hich is what flush is for.
cat out the file and same thing, stops at 49626. a ctrl-c exit closes 
the files cleanly, but if the file exits uncleanly, i.e. a kill command 
or something else catastrophic. the remaining buffer is lost.


Yes, because of bfufering. This is normal and IMO correct. You can turn 
it off, or catch-and-flush these circumstances (SIGKILL excepted, 
because SIGKILL's entire purpose it to be uncatchable).


Of course one SHOULD manage the closing of their files and this is 
partially on the user, but if by design something is hanging on to a 
file while it is waiting for something, then a crash occurs, they lose 
a portion of what was assumed already complete...


f.flush()

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

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

[Frank B]

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 testing, in case the 
reasoning lingers somewhere else.


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.


2 methods to recreate - 1st run from interpreter directly:

f = open("abc", "w")
for i in range(5):
   f.write(str(i) + "\n")


use

with open("abc", "w") as f:
for i in range(5):
f.write(str(i) + "\n")

and all is well

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

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

[aapost]

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. Use flush() 
followed by os.fsync() to ensure this behavior.

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

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

[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 testing, in case the 
reasoning lingers somewhere else.


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.


2 methods to recreate - 1st run from interpreter directly:

f = open("abc", "w")
for i in range(5):
  f.write(str(i) + "\n")

you can cat the file and see it stops at 49626 until you issue an f.close()

a script to recreate:

f = open("abc", "w")
for i in range(5):
  f.write(str(i) + "\n")
while(1):
  pass

cat out the file and same thing, stops at 49626. a ctrl-c exit closes 
the files cleanly, but if the file exits uncleanly, i.e. a kill command 
or something else catastrophic. the remaining buffer is lost.


Of course one SHOULD manage the closing of their files and this is 
partially on the user, but if by design something is hanging on to a 
file while it is waiting for something, then a crash occurs, they lose a 
portion of what was assumed already complete...

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

Re: Regular Expression bug?

[jose isaias cabrera]

On Thu, Mar 2, 2023 at 9:56 PM Alan Bawden  wrote:
>
> jose isaias cabrera  writes:
>
>On Thu, Mar 2, 2023 at 2:38 PM Mats Wichmann  wrote:
>
>This re is a bit different than the one I am used. So, I am trying to match
>everything after 'pn=':
>
>import re
>s = "pm=jose pn=2017"
>m0 = r"pn=(.+)"
>r0 = re.compile(m0)
>s0 = r0.match(s)
>>>> print(s0)
>None
>
> Assuming that you were expecting to match "pn=2017", then you probably
> don't want the 'match' method.  Read its documentation.  Then read the
> documentation for the _other_ methods that a Pattern supports.  Then you
> will be enlightened.

Yes. I need search. Thanks.

-- 

What if eternity is real?  Where will you spend it?  H...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Regular Expression bug?

[jose isaias cabrera]

On Thu, Mar 2, 2023 at 8:35 PM  wrote:
>
> It is a well-known fact, Jose, that GIGO.
>
> The letters "n" and "m" are not interchangeable. Your pattern fails because 
> you have "pn" in one place and "pm" in the other.

It is not GIGO. pm=project manager. pn=project name. I needed search()
rather than match().

>
> >>> s = "pn=jose pn=2017"
> ...
> >>> s0 = r0.match(s)
> >>> s0
> 
>
>
>
> -Original Message-
> From: Python-list  On 
> Behalf Of jose isaias cabrera
> Sent: Thursday, March 2, 2023 8:07 PM
> To: Mats Wichmann 
> Cc: python-list@python.org
> Subject: Re: Regular Expression bug?
>
> On Thu, Mar 2, 2023 at 2:38 PM Mats Wichmann  wrote:
> >
> > On 3/2/23 12:28, Chris Angelico wrote:
> > > On Fri, 3 Mar 2023 at 06:24, jose isaias cabrera 
> wrote:
> > >>
> > >> Greetings.
> > >>
> > >> For the RegExp Gurus, consider the following python3 code:
> > >> 
> > >> import re
> > >> s = "pn=align upgrade sd=2023-02-"
> > >> ro = re.compile(r"pn=(.+) ")
> > >> r0=ro.match(s)
> > >>>>> print(r0.group(1))
> > >> align upgrade
> > >> 
> > >>
> > >> This is wrong. It should be 'align' because the group only goes up-to
> > >> the space. Thoughts? Thanks.
> > >>
> > >
> > > Not a bug. Find the longest possible match that fits this; as long as
> > > you can find a space immediately after it, everything in between goes
> > > into the .+ part.
> > >
> > > If you want to exclude spaces, either use [^ ]+ or .+?.
> >
> > https://docs.python.org/3/howto/regex.html#greedy-versus-non-greedy
>
> This re is a bit different than the one I am used. So, I am trying to match
> everything after 'pn=':
>
> import re
> s = "pm=jose pn=2017"
> m0 = r"pn=(.+)"
> r0 = re.compile(m0)
> s0 = r0.match(s)
> >>> print(s0)
> None
>
> Any help is appreciated.
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 

What if eternity is real?  Where will you spend it?  H...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Regular Expression bug?

[jose isaias cabrera]

On Thu, Mar 2, 2023 at 8:30 PM Cameron Simpson  wrote:
>
> On 02Mar2023 20:06, jose isaias cabrera  wrote:
> >This re is a bit different than the one I am used. So, I am trying to
> >match
> >everything after 'pn=':
> >
> >import re
> >s = "pm=jose pn=2017"
> >m0 = r"pn=(.+)"
> >r0 = re.compile(m0)
> >s0 = r0.match(s)
>
> `match()` matches at the start of the string. You want r0.search(s).
> - Cameron Simpson 

Thanks. Darn it! I knew it was something simple.


-- 

What if eternity is real?  Where will you spend it?  H...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Regular Expression bug?

[Alan Bawden]

jose isaias cabrera  writes:

   On Thu, Mar 2, 2023 at 2:38 PM Mats Wichmann  wrote:

   This re is a bit different than the one I am used. So, I am trying to match
   everything after 'pn=':

   import re
   s = "pm=jose pn=2017"
   m0 = r"pn=(.+)"
   r0 = re.compile(m0)
   s0 = r0.match(s)
   >>> print(s0)
   None

Assuming that you were expecting to match "pn=2017", then you probably
don't want the 'match' method.  Read its documentation.  Then read the
documentation for the _other_ methods that a Pattern supports.  Then you
will be enlightened.

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

Re: Regular Expression bug?

[Cameron Simpson]

On 02Mar2023 20:06, jose isaias cabrera  wrote:
This re is a bit different than the one I am used. So, I am trying to 
match

everything after 'pn=':

import re
s = "pm=jose pn=2017"
m0 = r"pn=(.+)"
r0 = re.compile(m0)
s0 = r0.match(s)


`match()` matches at the start of the string. You want r0.search(s).
- Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

RE: Regular Expression bug?

[avi.e.gross]

It is a well-known fact, Jose, that GIGO.

The letters "n" and "m" are not interchangeable. Your pattern fails because you 
have "pn" in one place and "pm" in the other.


>>> s = "pn=jose pn=2017"
...
>>> s0 = r0.match(s)
>>> s0




-Original Message-
From: Python-list  On 
Behalf Of jose isaias cabrera
Sent: Thursday, March 2, 2023 8:07 PM
To: Mats Wichmann 
Cc: python-list@python.org
Subject: Re: Regular Expression bug?

On Thu, Mar 2, 2023 at 2:38 PM Mats Wichmann  wrote:
>
> On 3/2/23 12:28, Chris Angelico wrote:
> > On Fri, 3 Mar 2023 at 06:24, jose isaias cabrera 
wrote:
> >>
> >> Greetings.
> >>
> >> For the RegExp Gurus, consider the following python3 code:
> >> 
> >> import re
> >> s = "pn=align upgrade sd=2023-02-"
> >> ro = re.compile(r"pn=(.+) ")
> >> r0=ro.match(s)
> >>>>> print(r0.group(1))
> >> align upgrade
> >> 
> >>
> >> This is wrong. It should be 'align' because the group only goes up-to
> >> the space. Thoughts? Thanks.
> >>
> >
> > Not a bug. Find the longest possible match that fits this; as long as
> > you can find a space immediately after it, everything in between goes
> > into the .+ part.
> >
> > If you want to exclude spaces, either use [^ ]+ or .+?.
>
> https://docs.python.org/3/howto/regex.html#greedy-versus-non-greedy

This re is a bit different than the one I am used. So, I am trying to match
everything after 'pn=':

import re
s = "pm=jose pn=2017"
m0 = r"pn=(.+)"
r0 = re.compile(m0)
s0 = r0.match(s)
>>> print(s0)
None

Any help is appreciated.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

Re: Regular Expression bug?

[jose isaias cabrera]

On Thu, Mar 2, 2023 at 2:38 PM Mats Wichmann  wrote:
>
> On 3/2/23 12:28, Chris Angelico wrote:
> > On Fri, 3 Mar 2023 at 06:24, jose isaias cabrera 
wrote:
> >>
> >> Greetings.
> >>
> >> For the RegExp Gurus, consider the following python3 code:
> >> 
> >> import re
> >> s = "pn=align upgrade sd=2023-02-"
> >> ro = re.compile(r"pn=(.+) ")
> >> r0=ro.match(s)
> >>>>> print(r0.group(1))
> >> align upgrade
> >> 
> >>
> >> This is wrong. It should be 'align' because the group only goes up-to
> >> the space. Thoughts? Thanks.
> >>
> >
> > Not a bug. Find the longest possible match that fits this; as long as
> > you can find a space immediately after it, everything in between goes
> > into the .+ part.
> >
> > If you want to exclude spaces, either use [^ ]+ or .+?.
>
> https://docs.python.org/3/howto/regex.html#greedy-versus-non-greedy

This re is a bit different than the one I am used. So, I am trying to match
everything after 'pn=':

import re
s = "pm=jose pn=2017"
m0 = r"pn=(.+)"
r0 = re.compile(m0)
s0 = r0.match(s)
>>> print(s0)
None

Any help is appreciated.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Regular Expression bug?

[avi.e.gross]

José,

Matching can be greedy. Did it match to the last space?

What you want is a pattern that matches anything except a space (or whitespace) 
followed b matching a space or something similar.

Or use a construct that makes matching non-greedy.

Avi

-Original Message-
From: Python-list  On 
Behalf Of jose isaias cabrera
Sent: Thursday, March 2, 2023 2:23 PM
To: python-list@python.org
Subject: Regular Expression bug?

Greetings.

For the RegExp Gurus, consider the following python3 code:

import re
s = "pn=align upgrade sd=2023-02-"
ro = re.compile(r"pn=(.+) ")
r0=ro.match(s)
>>> print(r0.group(1))
align upgrade


This is wrong. It should be 'align' because the group only goes up-to the 
space. Thoughts? Thanks.

josé

-- 

What if eternity is real?  Where will you spend it?  H...
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: Regular Expression bug?

[jose isaias cabrera]

On Thu, Mar 2, 2023 at 2:32 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2023-03-02 at 14:22:41 -0500,
> jose isaias cabrera  wrote:
>
> > For the RegExp Gurus, consider the following python3 code:
> > 
> > import re
> > s = "pn=align upgrade sd=2023-02-"
> > ro = re.compile(r"pn=(.+) ")
> > r0=ro.match(s)
> > >>> print(r0.group(1))
> > align upgrade
> > 
> >
> > This is wrong. It should be 'align' because the group only goes up-to
> > the space. Thoughts? Thanks.
>
> The bug is in your regular expression; the plus modifier is greedy.
>
> If you want to match up to the first space, then you'll need something
> like [^ ] (i.e., everything that isn't a space) instead of that dot.

Thanks. I appreciate your wisdom.

josé
-- 

What if eternity is real?  Where will you spend it?  H...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Regular Expression bug?

[Mats Wichmann]

On 3/2/23 12:28, Chris Angelico wrote:

On Fri, 3 Mar 2023 at 06:24, jose isaias cabrera  wrote:


Greetings.

For the RegExp Gurus, consider the following python3 code:

import re
s = "pn=align upgrade sd=2023-02-"
ro = re.compile(r"pn=(.+) ")
r0=ro.match(s)

print(r0.group(1))

align upgrade


This is wrong. It should be 'align' because the group only goes up-to
the space. Thoughts? Thanks.



Not a bug. Find the longest possible match that fits this; as long as
you can find a space immediately after it, everything in between goes
into the .+ part.

If you want to exclude spaces, either use [^ ]+ or .+?.



https://docs.python.org/3/howto/regex.html#greedy-versus-non-greedy

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

Re: Regular Expression bug?

[2QdxY4RzWzUUiLuE]

On 2023-03-02 at 14:22:41 -0500,
jose isaias cabrera  wrote:

> For the RegExp Gurus, consider the following python3 code:
> 
> import re
> s = "pn=align upgrade sd=2023-02-"
> ro = re.compile(r"pn=(.+) ")
> r0=ro.match(s)
> >>> print(r0.group(1))
> align upgrade
> 
> 
> This is wrong. It should be 'align' because the group only goes up-to
> the space. Thoughts? Thanks.

The bug is in your regular expression; the plus modifier is greedy.

If you want to match up to the first space, then you'll need something
like [^ ] (i.e., everything that isn't a space) instead of that dot.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Regular Expression bug?

[Chris Angelico]

On Fri, 3 Mar 2023 at 06:24, jose isaias cabrera  wrote:
>
> Greetings.
>
> For the RegExp Gurus, consider the following python3 code:
> 
> import re
> s = "pn=align upgrade sd=2023-02-"
> ro = re.compile(r"pn=(.+) ")
> r0=ro.match(s)
> >>> print(r0.group(1))
> align upgrade
> 
>
> This is wrong. It should be 'align' because the group only goes up-to
> the space. Thoughts? Thanks.
>

Not a bug. Find the longest possible match that fits this; as long as
you can find a space immediately after it, everything in between goes
into the .+ part.

If you want to exclude spaces, either use [^ ]+ or .+?.

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

Regular Expression bug?

[jose isaias cabrera]

Greetings.

For the RegExp Gurus, consider the following python3 code:

import re
s = "pn=align upgrade sd=2023-02-"
ro = re.compile(r"pn=(.+) ")
r0=ro.match(s)
>>> print(r0.group(1))
align upgrade


This is wrong. It should be 'align' because the group only goes up-to
the space. Thoughts? Thanks.

josé

-- 

What if eternity is real?  Where will you spend it?  H...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Possible re bug when using ".*"

[Peter J. Holzer]

On 2022-12-28 19:07:06 +, MRAB wrote:
> On 2022-12-28 18:42, Alexander Richert - NOAA Affiliate via Python-list
> wrote:
> > print(re.sub(".*", "replacement", "pattern"))
> > yields the output "replacementreplacement".
[...]
> It's not a bug, it's a change in behaviour to bring it more into line with
> other regex implementations in other languages.

Interesting. Perl does indeed behave that way, too. Never noticed that
in 28 years of using it.

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: Possible re bug

[Barry Scott]

Please please fix you email client so that your replies stay with the
emails you are replying to.

Barry


On 28/12/2022 19:09, Stefan Ram wrote:

Alexander Richert writes:
|print(re.findall(".*","pattern"))
|yields ['pattern',''] which is not what I was expecting.

   The asterisk is "greedy", so I agree that it should consume
   /everything/ including all the empty strings at the end.
   To work around this, one can use '^.*' (no smiley intended).



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

Re: Possible re bug when using ".*"

[Ethan Furman]

On 12/28/22 11:07, MRAB wrote:

On 2022-12-28 18:42, Alexander Richert - NOAA Affiliate via Python-list wrote:

  In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".

This behavior does not occur in 3.6.

Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.


It's not a bug, it's a change in behaviour to bring it more into line with 
other regex implementations in other languages.


The new behavior makes no sense to me, but better to be consistent with the other regex engines than not -- I still get 
thrown off by vim's regex.


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

Re: Possible re bug when using ".*"

[MRAB]

On 2022-12-28 18:42, Alexander Richert - NOAA Affiliate via Python-list 
wrote:

  In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".

This behavior does not occur in 3.6.

Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.

It's not a bug, it's a change in behaviour to bring it more into line 
with other regex implementations in other languages.

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

Re: Possible re bug when using ".*"

[Roel Schroeven]

Roel Schroeven schreef op 28/12/2022 om 19:59:
Alexander Richert - NOAA Affiliate via Python-list schreef op 
28/12/2022 om 19:42:

  In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".

This behavior does not occur in 3.6.

Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
The documentation for re.sub() and re.findall() has these notes: 
"Changed in version 3.7: Empty matches for the pattern are replaced 
when adjacent to a previous non-empty match." and "Changed in version 
3.7: Non-empty matches can now start just after a previous empty match."
That's probably describes the behavior you're seeing. ".*" first 
matches "pattern", which is a non-empty match; then it matches the 
empty string at the end, which is an empty match but is replaced 
because it is adjacent to a non-empty match.


Seems somewhat counter-intuitive to me, but AFAICS it's the intended 
behavior.
For what it's worth, there's some discussion about this in this Github 
issue: https://github.com/python/cpython/issues/76489


--
"Je ne suis pas d’accord avec ce que vous dites, mais je me battrai jusqu’à
la mort pour que vous ayez le droit de le dire."
-- Attribué à Voltaire
"I disapprove of what you say, but I will defend to the death your right to
say it."
-- Attributed to Voltaire
"Ik ben het niet eens met wat je zegt, maar ik zal je recht om het te zeggen
tot de dood toe verdedigen"
-- Toegeschreven aan Voltaire
--
https://mail.python.org/mailman/listinfo/python-list

Re: Possible re bug when using ".*"

[Roel Schroeven]

Alexander Richert - NOAA Affiliate via Python-list schreef op 28/12/2022 
om 19:42:

  In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".

This behavior does not occur in 3.6.

Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.
The documentation for re.sub() and re.findall() has these notes: 
"Changed in version 3.7: Empty matches for the pattern are replaced when 
adjacent to a previous non-empty match." and "Changed in version 3.7: 
Non-empty matches can now start just after a previous empty match."
That's probably describes the behavior you're seeing. ".*" first matches 
"pattern", which is a non-empty match; then it matches the empty string 
at the end, which is an empty match but is replaced because it is 
adjacent to a non-empty match.


Seems somewhat counter-intuitive to me, but AFAICS it's the intended 
behavior.


--
"Programming today is a race between software engineers striving to build bigger
and better idiot-proof programs, and the Universe trying to produce bigger and
better idiots. So far, the Universe is winning."
-- Douglas Adams
--
https://mail.python.org/mailman/listinfo/python-list

Possible re bug when using ".*"

[Alexander Richert - NOAA Affiliate via Python-list]

 In a couple recent versions of Python (including 3.8 and 3.10), the
following code:
import re
print(re.sub(".*", "replacement", "pattern"))
yields the output "replacementreplacement".

This behavior does not occur in 3.6.

Which behavior is the desired one? Perhaps relatedly, I noticed that even
in 3.6, the code
print(re.findall(".*","pattern"))
yields ['pattern',''] which is not what I was expecting.

Thanks,
Alex Richert

-- 
Alexander Richert, PhD
*RedLine Performance Systems*
-- 
https://mail.python.org/mailman/listinfo/python-list

Bug report - Python 3.10 from Microsoft Store - IDLE won't start

[Johan Gunnarsson via Python-list]

Hello, IDLE won't start if ver. 3.10 is installed from Microsoft Store.
3.9 works just fine.

Thanks in advance!


Johan Gunnarsson
Lunds universitet
Medicinska fakulteten
Bibliotek & IKT
Box 118, 221 00 Lund
Besöksadress: Sölvegatan 19, 221 84 Lund
Telefon: +46 46 222 18 23
www.medicin.lu.se
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?

[Eryk Sun]

On 11/13/22, Jessica Smith <12jessicasmit...@gmail.com> wrote:
> Consider the following code ran in Powershell or cmd.exe:
>
> $ python -c "print('└')"
> └
>
> $ python -c "print('└')" > test_file.txt
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in
> encode
> return codecs.charmap_encode(input,self.errors,encoding_table)[0]
> UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
> position 0: character maps to 

If your applications and existing data files are compatible with using
UTF-8, then in Windows 10+ you can modify the administrative regional
settings in the control panel to force using UTF-8. In this case,
GetACP() and GetOEMCP() will return CP_UTF8 (65001), and the reserved
code page constants CP_ACP (0),  CP_OEMCP (1), CP_MACCP (2), and
CP_THREAD_ACP (3) will use CP_UTF8.

You can override this on a per-application basis via the
ActiveCodePage setting in the manifest:

https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#activecodepage

In Windows 10, this setting only supports "UTF-8". In Windows 11, it
also supports "legacy" to allow old applications to run on a system
that's configured to use UTF-8.  Setting an explicit locale is also
supported in Windows 11, such as "en-US", with fallback to UTF-8 if
the given locale has no legacy code page.

Note that setting the system to use UTF-8 also affects the host
process for console sessions (i.e. conhost.exe or openconsole.exe),
since it defaults to using the OEM code page (UTF-8 in this case).
Unfortunately, a legacy read from the console host does not support
reading non-ASCII text as UTF-8. For example:

>>> os.read(0, 6)
SPĀM
b'SP\x00M\r\n'

This is a trivial bug in the console host, which stems from the fact
that UTF-8 is a multibyte encoding (1-4 bytes per code), but for some
reason the console team at Microsoft still hasn't fixed it. You can
use chcp.com to set the console's input and output code pages to
something other than UTF-8 if you have to read non-ASCII input in a
legacy console app. By default, this problem doesn't affect Python's
sys.stdin, which internally uses wide-character ReadConsoleW() with
the system's native text encoding, UTF-16LE.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?

[Thomas Passin]

On 11/13/2022 9:49 AM, Jessica Smith wrote:

Consider the following code ran in Powershell or cmd.exe:

$ python -c "print('└')"
└

$ python -c "print('└')" > test_file.txt
Traceback (most recent call last):
   File "", line 1, in 
   File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in encode
 return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
position 0: character maps to 

Is this a known limitation of Windows + Unicode? I understand that
using -x utf8 would fix this, or modifying various environment
variables. But is this expected for a standard Python installation on
Windows?

Jessica



This also fails with the same error:

$ python -c "print('└')" |clip
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?

[Barry]

> On 13 Nov 2022, at 14:52, Jessica Smith <12jessicasmit...@gmail.com> wrote:
> 
> Consider the following code ran in Powershell or cmd.exe:
> 
> $ python -c "print('└')"
> └
> 
> $ python -c "print('└')" > test_file.txt
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in encode
>return codecs.charmap_encode(input,self.errors,encoding_table)[0]
> UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
> position 0: character maps to 
> 
> Is this a known limitation of Windows + Unicode? I understand that
> using -x utf8 would fix this, or modifying various environment
> variables. But is this expected for a standard Python installation on
> Windows?

Your other thread has a reply that explained this.
It is a problem with windows and character sets.
You have to set things up to allow Unicode to work.

Barry

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

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

Python 3.7+ cannot print unicode characters when output is redirected to file - is this a bug?

[Jessica Smith]

Consider the following code ran in Powershell or cmd.exe:

$ python -c "print('└')"
└

$ python -c "print('└')" > test_file.txt
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program Files\Python38\lib\encodings\cp1252.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2514' in
position 0: character maps to 

Is this a known limitation of Windows + Unicode? I understand that
using -x utf8 would fix this, or modifying various environment
variables. But is this expected for a standard Python installation on
Windows?

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

Re: Python3.6 tkinter bug?

[Peter Smith]

On Wednesday, February 1, 2017 at 11:55:35 AM UTC, Terry Reedy wrote:
> On 2/1/2017 1:37 AM, Christian Gollwitzer wrote: 
> > Am 01.02.17 um 00:02 schrieb MRAB: 
> >> On 2017-01-31 22:34, Christian Gollwitzer wrote: 
>  .!frame.!checkbutton 
>  .!frame.!checkbutton2 
>  .!frame2.!checkbutton 
>  .!frame2.!checkbutton2 
> >>> 
> >>> 
> >> Perhaps someone who knows Tcl and tk can tell me, but I notice that in 
> >> the first example, the second part of the widget names are unique, 
> >> whereas in the second example, the second part of the widget names are 
> >> the reused (both "!checkbutton" and "!checkbutton2" occur twice). 
> > 
> > It is indeed the reason, but it has some strange legacy cause: the 
> > default name for the checkbutton-linked variable is the name of the 
> > button inside the parent. Therefore creating a checkbutton has the side 
> > effect of creating a variable with the button's name. 
> > 
> > In this case, the first buttons in the frames are linked to a variable 
> > called "!checkbutton" and the other two are linked to "!checkbutton2". 
> > (a variable name in Tcl can be anything apart from the empty string). 
> > This can also be demonstrated by this Tcl script: 
> > 
> > package require Tk 
> > 
> > pack [frame .f1] 
> > pack [frame .f2] 
> > 
> > pack [checkbutton .f1.c1 -text "A" ] 
> > pack [checkbutton .f1.c2 -text "B" ] 
> > 
> > pack [checkbutton .f2.c1 -text "C" ] 
> > pack [checkbutton .f2.c2 -text "D" ] 
> > 
> > which is equivalent to the Python code above. 
> > 
> > Note that this surprising behaviour was corrected for the (modern) ttk 
> > widgets, so if "checkbutton" is replaced by "ttk::checkbutton", they are 
> > not any longer linked. In Python, that would be 
> > 
> > from tkinter import ttk 
> > ... 
> > w = ttk.Checkbutton() 
> > 
> > (Personally, I'm not using the legacy widgets any longer)
> Christian, could you repeat any relevant parts of your comments on the 
> tracker, especially any ideas on how we might fix tkinter? 
> https://bugs.python.org/issue29402
> >> Do the names need to be: 
> >> 
> >> .!frame.!checkbutton 
> >> .!frame.!checkbutton2 
> >> .!frame2.!checkbutton3 
> >> .!frame2.!checkbutton4
> Serhiy considered that but, not knowing that this would cause a 
> regression, we both liked numbering within parent better. 
> 
> There is a similar issue with radiobuttons on ttk.OptionMenus that 
> existed *before* the 3.6 name changes. 
> https://bugs.python.org/issue25684 
> So there seems to be a systematic issue with tk or how we are (mis)using it.
> > Good question. Maybe there should be unique variable names? I.e., if the 
> > script is changed into package require Tk 
> > 
> > pack [frame .f1] 
> > pack [frame .f2] 
> > 
> > pack [checkbutton .f1.c1 -text "A" -variable v1] 
> > pack [checkbutton .f1.c2 -text "B" -variable v2] 
> > 
> > pack [checkbutton .f2.c1 -text "C" -variable v3] 
> > pack [checkbutton .f2.c2 -text "D" -variable v4] 
> > 
> > then they are also not linked.
> -- 
> Terry Jan Reedy

It looks as if the issue is indeed that the expression to the right of 
CheckButton(... variable= must be an expression.

This works for me
   global checkbix, checkbuttons
   checkbix += 1
   b = tk.Checkbutton(frame, text=text, variable=checkbuttons[checkbix], ...)

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

Re: Python3.6 tkinter bug?

[Peter Smith]

On Wednesday, February 1, 2017 at 11:55:35 AM UTC, Terry Reedy wrote:
> On 2/1/2017 1:37 AM, Christian Gollwitzer wrote: 
> > Am 01.02.17 um 00:02 schrieb MRAB: 
> >> On 2017-01-31 22:34, Christian Gollwitzer wrote: 
>  .!frame.!checkbutton 
>  .!frame.!checkbutton2 
>  .!frame2.!checkbutton 
>  .!frame2.!checkbutton2 
> >>> 
> >>> 
> >> Perhaps someone who knows Tcl and tk can tell me, but I notice that in 
> >> the first example, the second part of the widget names are unique, 
> >> whereas in the second example, the second part of the widget names are 
> >> the reused (both "!checkbutton" and "!checkbutton2" occur twice). 
> > 
> > It is indeed the reason, but it has some strange legacy cause: the 
> > default name for the checkbutton-linked variable is the name of the 
> > button inside the parent. Therefore creating a checkbutton has the side 
> > effect of creating a variable with the button's name. 
> > 
> > In this case, the first buttons in the frames are linked to a variable 
> > called "!checkbutton" and the other two are linked to "!checkbutton2". 
> > (a variable name in Tcl can be anything apart from the empty string). 
> > This can also be demonstrated by this Tcl script: 
> > 
> > package require Tk 
> > 
> > pack [frame .f1] 
> > pack [frame .f2] 
> > 
> > pack [checkbutton .f1.c1 -text "A" ] 
> > pack [checkbutton .f1.c2 -text "B" ] 
> > 
> > pack [checkbutton .f2.c1 -text "C" ] 
> > pack [checkbutton .f2.c2 -text "D" ] 
> > 
> > which is equivalent to the Python code above. 
> > 
> > Note that this surprising behaviour was corrected for the (modern) ttk 
> > widgets, so if "checkbutton" is replaced by "ttk::checkbutton", they are 
> > not any longer linked. In Python, that would be 
> > 
> > from tkinter import ttk 
> > ... 
> > w = ttk.Checkbutton() 
> > 
> > (Personally, I'm not using the legacy widgets any longer)
> Christian, could you repeat any relevant parts of your comments on the 
> tracker, especially any ideas on how we might fix tkinter? 
> https://bugs.python.org/issue29402
> >> Do the names need to be: 
> >> 
> >> .!frame.!checkbutton 
> >> .!frame.!checkbutton2 
> >> .!frame2.!checkbutton3 
> >> .!frame2.!checkbutton4
> Serhiy considered that but, not knowing that this would cause a 
> regression, we both liked numbering within parent better. 
> 
> There is a similar issue with radiobuttons on ttk.OptionMenus that 
> existed *before* the 3.6 name changes. 
> https://bugs.python.org/issue25684 
> So there seems to be a systematic issue with tk or how we are (mis)using it.
> > Good question. Maybe there should be unique variable names? I.e., if the 
> > script is changed into package require Tk 
> > 
> > pack [frame .f1] 
> > pack [frame .f2] 
> > 
> > pack [checkbutton .f1.c1 -text "A" -variable v1] 
> > pack [checkbutton .f1.c2 -text "B" -variable v2] 
> > 
> > pack [checkbutton .f2.c1 -text "C" -variable v3] 
> > pack [checkbutton .f2.c2 -text "D" -variable v4] 
> > 
> > then they are also not linked.
> -- 
> Terry Jan Reedy
-- 
https://mail.python.org/mailman/listinfo/python-list

Fwd: [pandas-dev/pandas] BUG: I CANT TO RECIEVING OUTPUT FROM DATAFRAME (Issue #48256)

[נתי שטרן]

 הודעה שהועברה --
מאת: *נתי שטרן* 
תאריך: יום שישי, 26 באוגוסט 2022
נושא: Re: [pandas-dev/pandas] BUG: I CANT TO RECIEVING OUTPUT FROM
DATAFRAME (Issue #48256)
אל: pandas-dev/pandas <
reply+abnbjwpfil765hhzxpb3l4wbcubnzevbnhhfbdb...@reply.github.com>
עותק: pandas-dev/pandas , Author <
aut...@noreply.github.com>


I'll do it at sunday

בתאריך יום חמישי, 25 באוגוסט 2022, מאת Marco Edward Gorelli <
notificati...@github.com>:

> Hi - please make your example reproducible https://matthewrocklin.com/blo
> g/work/2018/02/28/minimal-bug-reports
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/issues/48256#issuecomment-1227686223>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABNBJWKCADVU75PEQQ42HRDV27D5ZANCNFSM57UJPL2Q>
> .
> You are receiving this because you authored the thread.Message ID:
> 
>


-- 
<https://netanel.ml>




-- 
<https://netanel.ml>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: timedelta object recursion bug

[Dieter Maurer]

Please stay on the list (such that others can help, too)

Ben Hirsig wrote at 2022-7-29 06:53 +1000:
>Thanks for the replies, I'm just trying to understand why this would be
>useful?
>
>E.g. why does max need a min/max/resolution, and why would these attributes
>themselves need a min/max/resolution, etc, etc?

`max` is a `timedelta` and as such inherits (e.g.) `resolution`
from the class (as any other `timedelta` instance).

Note that `timedelta` instances do not have a `max` (`min|resolution`)
slot. When `max` is looked up, it is first searched in the instance
(and not found), then in the class where it is found:
all `max` accesses result in the same object.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: timedelta object recursion bug

[Dieter Maurer]

Ben Hirsig wrote at 2022-7-28 19:54 +1000:
>Hi, I noticed this when using the requests library in the response.elapsed
>object (type timedelta). Tested using the standard datetime library alone
>with the example displayed on
>https://docs.python.org/3/library/datetime.html#examples-of-usage-timedelta
>
>
>
>It appears as though the timedelta object recursively adds its own
>attributes (min, max, resolution) as further timedelta objects. I’m not
>sure how deep they go, but presumably hitting the recursion limit.

If you look at the source, you will see that `min`, `max`, `resolution`
are class level attributes. Their values are `timedelta` instances.
Therefore, you can access e.g. `timedelta(days=365).min.max.resolution`.
But this is nothing to worry about.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: timedelta object recursion bug

[Jon Ribbens via Python-list]

On 2022-07-28, Ben Hirsig  wrote:
> Hi, I noticed this when using the requests library in the response.elapsed
> object (type timedelta). Tested using the standard datetime library alone
> with the example displayed on
> https://docs.python.org/3/library/datetime.html#examples-of-usage-timedelta
>
> It appears as though the timedelta object recursively adds its own
> attributes (min, max, resolution) as further timedelta objects. I’m not
> sure how deep they go, but presumably hitting the recursion limit.
>
>>from datetime import timedelta
>>year = timedelta(days=365)
>>print(year.max)
>   9 days, 23:59:59.99
>>print(year.max.min.max.resolution.max.min)
>   -9 days, 0:00:00

Why do you think this is a bug?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: timedelta object recursion bug

[MRAB]

On 28/07/2022 10:54, Ben Hirsig wrote:

Hi, I noticed this when using the requests library in the response.elapsed
object (type timedelta). Tested using the standard datetime library alone
with the example displayed on
https://docs.python.org/3/library/datetime.html#examples-of-usage-timedelta



It appears as though the timedelta object recursively adds its own
attributes (min, max, resolution) as further timedelta objects. I’m not
sure how deep they go, but presumably hitting the recursion limit.




from datetime import timedelta



year = timedelta(days=365)



print(year.max)


   9 days, 23:59:59.99


print(year.max.min.max.resolution.max.min)


   -9 days, 0:00:00



I’m using 3.10.3


It's not recursion, it's a reference cycle. In fact, more than one:

>>> from datetime import timedelta
>>> year = timedelta(days=365)
>>> type(year)

>>> type(year.max)

>>> year.max is year.max.max
True
>>> type(year.min)

>>> year.min is year.min.min
True
--
https://mail.python.org/mailman/listinfo/python-list

Fwd: timedelta object recursion bug

[Ben Hirsig]

Hi, I noticed this when using the requests library in the response.elapsed
object (type timedelta). Tested using the standard datetime library alone
with the example displayed on
https://docs.python.org/3/library/datetime.html#examples-of-usage-timedelta



It appears as though the timedelta object recursively adds its own
attributes (min, max, resolution) as further timedelta objects. I’m not
sure how deep they go, but presumably hitting the recursion limit.



>from datetime import timedelta

>year = timedelta(days=365)

>print(year.max)

  9 days, 23:59:59.99

>print(year.max.min.max.resolution.max.min)

  -9 days, 0:00:00



I’m using 3.10.3



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

Re: bug in python 3.10.4

[Dennis Lee Bieber]

On Thu, 26 May 2022 19:56:16 +1200, dn 
declaimed the following:

Commentary meant for the OP, not "dn".

>Please reply to the list. Others may be able to assist (particularly if
>they use MS-Windows!).
>
>
>> Removing the  quit does not help with the problem.
>> 
>> input 10 x 10

Cut the entire text of the console window (not a screen grab)
showing the invocation and the output, if any. NOTE: This presumes you know
how to use the Windows command line. Double-clicking a .py file seldom
produces a usable stuff as the console opened is automatically closed when
the program exits. If you need to see the output, you need to put in some
code to make the program /wait/ until you signal that you are done.

>
>What was the result, or the exception report.
>
>Once again: did MS-Windows finish the job and close the window before
>you could see the result?



>>> number_1 = input("put a number\n")

This is going to wait at the console until you enter a value.

>>> if operations == "+":
>>>
>>>     print(number_1+number_2)
>>>
>>> elifoperations.lower() == "x":

Is that REALLY what the code has? I'd expect

"elifoperations"

to produce a syntax error of some sort since there is no apparent space
between the "elif" and "operations".

{stylistic note: "operations" is misleading -- it is just ONE OPERATOR}


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bug in python 3.10.4

[MRAB]

On 2022-05-26 02:46, Shuaib Akhtar wrote:

When double clicking a .py file when have python install. It run file but
at a spot of the program it stop running. But using the built-in ide for
python this problem does not happen also any other ide it work fine

When you double-click on a .py file, Windows opens a console window and 
runs the program, and when the program finishes, Windows closes the 
console window. That's normal.

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

Re: bug in python 3.10.4

[dn]

Please reply to the list. Others may be able to assist (particularly if
they use MS-Windows!).


> Removing the  quit does not help with the problem.
> 
> input 10 x 10

What was the result, or the exception report.

Once again: did MS-Windows finish the job and close the window before
you could see the result?



On 26/05/2022 15.44, dn wrote:
>>When double clicking a .py file when have python install. It run file but
>>at a spot of the program it stop running. But using the built-in ide for
>>python this problem does not happen also any other ide it work fine
> 
> 
> The code looks good (although most IT-people think of * as the
> multiplication operator).
> 
> At present, the only way to stop the program is to enter two numbers and
> an invalid operator. This leads to the quit(). I'm not a user of
> MS-Windows, but won't that close the window without giving any
> opportunity to read the screen? Can you try commenting-out the quit()
> and replacing it with a print( "terminating" ) type of message? Does
> this help with the "stop running"?
> 
> To enable us to run the program[me] to produce the same results, what
> combination of input produces the error, what output results, and do you
> see any exception messages? Please copy-paste into your email-reply.
> 
> (the more you help us, the better we can help you!)
> 
> 
> 
> On 26/05/2022 15.12, Shuaib Akhtar wrote:
>>  
>>
>>  
>>
>> number_1 = input("put a number\n")
>>
>> print('division is /')
>>
>>  
>>
>> operations = input("put a operations\n")
>>
>> number_2 = input("put a number\n")
>>
>>  
>>
>> number_2 = float(number_2)
>>
>> number_1 = float(number_1)
>>
>>  
>>
>> if operations == "+":
>>
>>     print(number_1+number_2)
>>
>> elifoperations.lower() == "x":
>>
>>     print(number_1 * number_2)
>>
>> elifoperations == "/":
>>
>>     print(number_1/number_2)
>>
>> elifoperations == "-":
>>
>>     print(number_1 - number_2)
>>
>> else:
>>
>>     print("put a operation next time")
>>
>>     quit()
>>
>>  
>>
>>  
>>
> 
> 


-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bug in python 3.10.4

[dn]

On 26/05/2022 13.46, Shuaib Akhtar wrote:
>When double clicking a .py file when have python install. It run file but
>at a spot of the program it stop running. But using the built-in ide for
>python this problem does not happen also any other ide it work fine

Please provide (minimal) example code so that we can reproduce the
problem and, if necessary, help find a solution...
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

bug in python 3.10.4

[Shuaib Akhtar]

   When double clicking a .py file when have python install. It run file but
   at a spot of the program it stop running. But using the built-in ide for
   python this problem does not happen also any other ide it work fine

    

    

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

Re: [docs] Reporting a Bug

[anthony.flury via Python-list]

This is exactly as expected.


Strip removes any of the characters in the passed string from both the 
front and the end of the string being stripped.


The letter 'T' from the start of 'The meaning of life' does not appear 
in the word 'meaning' so nothing is removed from the start of the 
string.



The letter 'e' from the end of 'The meaning of life' does appear in the 
word 'meaning' so it is removed from the sentence; it will then look at 
the next last letter 'f', but since this doesn't appear in the word 
'meaning' nothing else is removed and the new string is returned.


The argument passed to strip(..) method is the set of characters to be 
removed - so any characters in that set are removed from the start and 
end of the string.





-- Original Message --
From: "Jeff Jeffi" 
To: d...@python.org
Cc: python-list@python.org
Sent: Wednesday, 4 May, 22 At 10:36
Subject: [docs] Reporting a Bug

Hello dears,

First of all i am not sure about this issue   please advise me if 
there is any mistake   in my report.



 for example in python 3.6.3 shell:



x= "The meaning of life" x.strip("meaning")

'The meaning of lif'


As you see the letter "e" of  the word "life"  is removed.


Sincerely yours.
J.Mohammadi




 ___
docs mailing list -- d...@python.org
To unsubscribe send an email to docs-le...@python.org
https://mail.python.org/mailman3/lists/docs.python.org/ 
<https://mail.python.org/mailman3/lists/docs.python.org/>

Member address: anthony.fl...@btinternet.com

-- Anthony Fluryanthony.fl...@btinternet.com
--
https://mail.python.org/mailman/listinfo/python-list

[issue401517] Fix for Bug 114333 (only reported bug in minidom)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue403202] fix bug parsing nested tags with htmllib

[admin]

Change by admin :


--
github: None -> 33698

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue483231] email.Utils.formatdate(): localtime bug

[admin]

Change by admin :


--
github: None -> 35546

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue212468] sre/pre bug

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue213700] widespread bug in HTML files: lots of italics

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue211725] Response to bug 110619

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401972] Fix for lookbehind bug (#117242)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue524008] pysvr portability bug on new POSIX hosts

[admin]

Change by admin :


--
github: None -> 36184

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue536578] patch for bug 462783 mmap bus error

[admin]

Change by admin :


--
github: None -> 36352

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210848] Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue527855] ftplib error (exception) handling bug

[admin]

Change by admin :


--
github: None -> 36232

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210654] bug in complex_nonzero (PR#347)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue527371] Fix for sre bug 470582

[admin]

Change by admin :


--
github: None -> 36223

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue512799] webchecker protocol bug

[admin]

Change by admin :


--
github: None -> 36027

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue528990] bug? in PyImport_ImportModule under AIX

[admin]

Change by admin :


--
github: None -> 36245

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue532180] fix xmlrpclib float marshalling bug

[admin]

Change by admin :


--
github: None -> 36287

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue529408] fix random.gammavariate bug #527139

[admin]

Change by admin :


--
github: None -> 36253

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue529273] WeakValueDictionary.setdefault() bug

[admin]

Change by admin :


--
github: None -> 36252

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue526384] Bug reports are ignored

[admin]

Change by admin :


--
github: None -> 36211

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue487784] Fixes a bug in popen3/4 handling on UNIX

[admin]

Change by admin :


--
github: None -> 35645

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue478421] cPickle bug when using imp.load_source()

[admin]

Change by admin :


--
github: None -> 35472

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue514628] bug in pydoc on python 2.2 release

[admin]

Change by admin :


--
github: None -> 36047

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue468169] fix for bug #448951 (re group handling)

[admin]

Change by admin :


--
github: None -> 35285

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue474175] file.readinto arg parsing bug

[admin]

Change by admin :


--
github: None -> 35389

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue511737] ConfigParser bug/limitation

[admin]

Change by admin :


--
github: None -> 36013

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue492386] Cascading menu bug on Linux

[admin]

Change by admin :


--
github: None -> 35731

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue490330] String format bug in test_b2

[admin]

Change by admin :


--
github: None -> 35688

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue453059] Nasty bug in HTMLParser.py

[admin]

Change by admin :


--
github: None -> 35006

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue482510] bug in slicing time.struct_time

[admin]

Change by admin :


--
github: None -> 35535

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue422463] bug in Python 1.5.2 for win2k pro

[admin]

Change by admin :


--
github: None -> 34479

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue420753] Patch for bug #420725 urllib MIME header

[admin]

Change by admin :


--
github: None -> 34450

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue418615] regular expression bug in pipes.py.

[admin]

Change by admin :


--
github: None -> 34409

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue418613] regular expression bug in pipes.py

[admin]

Change by admin :


--
github: None -> 34408

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue405358] Python2.0 re module: greedy regexp bug

[admin]

Change by admin :


--
github: None -> 34046

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue403743] [windows] Correction to bug #131273

[admin]

Change by admin :


--
github: None -> 33904

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue430160] CGIHTTPServer.py POST bug using IE

[admin]

Change by admin :


--
github: None -> 34582

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue422669] Bug with appending objects to list.

[admin]

Change by admin :


--
github: None -> 34481

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue413850] Bug in xml/__init__.py

[admin]

Change by admin :


--
github: None -> 34278

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue415597] asynchat.py - bug in terminator find

[admin]

Change by admin :


--
github: None -> 34311

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com