Re: File write, weird behaviour

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

Re: File write, weird behaviour

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 o

Re: File write, weird behaviour

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 &

Re: File write, weird behaviour

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 =

Re: File write, weird behaviour

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 =

Re: File write, weird behaviour

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+') ##

Re: File write, weird behaviour

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

Re: File write, weird behaviour

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

Re: File write, weird behaviour

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

Re: File write, weird behaviour

f 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 r

Re: File write, weird behaviour

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 behaviou

Re: File write, weird behaviour

) 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: > >

Re: File write, weird behaviour

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 readli

File write, weird behaviour

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 behavi

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Erlend E. Aasland added the comment: > What about closing this as third party? (Tcl/Tk is a dependency but still > it's a third party right?) Sure. I'll leave that for Terry or any of the other IDLE devs. We can adjust the resolution after close if needed. > Also what's up with this

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Shreyan Avigyan added the comment: Also what's up with this open-pending issue? -- status: open -> pending ___ Python tracker ___

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Shreyan Avigyan added the comment: What about closing this as third party? (Tcl/Tk is a dependency but still it's a third party right?) -- status: pending -> open ___ Python tracker

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Change by Erlend E. Aasland : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44217] [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters

Change by Erlend E. Aasland : -- status: pending -> open title: [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters -> [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters ___ Python tracker

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

Erlend E. Aasland added the comment: > The smiley emoji  is U+1F600 which is outside of the Unicode Basic > Multilingual Plane (BMP). Correct, and this is documented: https://docs.python.org/3/library/idle.html#user-output-in-shell Suggesting to close this as not-a-bug. -- nosy:

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

Shreyan Avigyan added the comment: It's not a Python problem at all. This was occurring in IDLE only. And yeah I know how it print the character. It's just that I was confused that why IDLE is behaving like that. I am happy to learn that it has a fix coming soon. --

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

Steven D'Aprano added the comment: The smiley emoji  is U+1F600 which is outside of the Unicode Basic Multilingual Plane (BMP). IDLE's underlying graphical toolkit, Tcl/Tk, has problems with Unicode characters outside of the BMP, so this may not be fixable by us. If all you want is to

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

Change by Shreyan Avigyan : -- versions: +Python 3.10, Python 3.11, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue44217] [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters

tle: [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters type: behavior ___ Python tracker <https://bugs.python.org/issue44217> ___ ___ Python-bugs-l

Pythoncom IEnum weird behaviour

I have a COM server implemented in Python. I've created the following object implementing IEnum to automatically wrap the sequence elements in PyIDispatch objects: from win32com.server.util import ListEnumerator class Iterator(ListEnumerator): def Next(self, count):

Re: Simple recursive sum function | what's the cause of the weird behaviour?

I read through all of the posts and thanks for helping. What was supposed to be simple a (recursively) straightforward, turned out to be quite tricky. I've set up a small testing bench and tried all of the proposed solutions including my own but none pass. I'll post it below. I've also

Re: Simple recursive sum function | what's the cause of the weird behaviour?

I got it! One of the testcases was wrong, ([[1], [1]],[1],[1, 1]), should be ([[1], [1]],[1],[1, 1, 1]), And the working solution. def supersum(sequence, start=0): result = start start = type(start)() for item in sequence: try:

Simple recursive sum function | what's the cause of the weird behaviour?

I know this is simple but I've been starring at it for half an hour and trying all sorts of things in the interpreter but I just can't see where it's wrong. def supersum(sequence, start=0): result = start for item in sequence: try: result += supersum(item, start)

Re: Simple recursive sum function | what's the cause of the weird behaviour?

Nevermind! Stupid of me to forget that lists or mutable so result and start both point to the same list. -- http://mail.python.org/mailman/listinfo/python-list

Re: Simple recursive sum function | what's the cause of the weird behaviour?

Since I've already wasted a thread I might as well... Does this serve as an acceptable solution? def supersum(sequence, start=0): result = type(start)() for item in sequence: try: result += supersum(item, start) except: result += item return

Re: Simple recursive sum function | what's the cause of the weird behaviour?

Russel Walker wrote: Since I've already wasted a thread I might as well... Does this serve as an acceptable solution? def supersum(sequence, start=0): result = type(start)() for item in sequence: try: result += supersum(item, start) except:

Re: Simple recursive sum function | what's the cause of the weird behaviour?

On Sat, Jul 6, 2013 at 10:37 PM, Russel Walker russ.po...@gmail.com wrote: This works: - - - - - - x = [[1], [2], [3]] supersum(x) 6 supersum(x, []) [1, 2, 3] This does not: - - - - - - - x = [[[1], [2]], [3]] supersum(x, []) [1, 2, 1, 2, 3] You have a problem of specification

Re: Simple recursive sum function | what's the cause of the weird behaviour?

On 6 July 2013 13:59, Russel Walker russ.po...@gmail.com wrote: Since I've already wasted a thread I might as well... Does this serve as an acceptable solution? def supersum(sequence, start=0): result = type(start)() for item in sequence: try: result +=

Re: Simple recursive sum function | what's the cause of the weird behaviour?

On 7/6/2013 8:37 AM, Russel Walker wrote: I know this is simple but I've been starring at it for half an hour and trying all sorts of things in the interpreter but I just can't see where it's wrong. def supersum(sequence, start=0): result = start for item in sequence: try:

Re: Simple recursive sum function | what's the cause of the weird behaviour?

On 06/07/2013 19:43, Joshua Landau wrote: On 6 July 2013 13:59, Russel Walker russ.po...@gmail.com wrote: Since I've already wasted a thread I might as well... Does this serve as an acceptable solution? def supersum(sequence, start=0): result = type(start)() for item in sequence:

Re: Simple recursive sum function | what's the cause of the weird behaviour?

On 06/07/2013 21:10, Rotwang wrote: [...] It's not quite clear to me what the OP's intentions are in the general case, but calling supersum(item, start) seems odd - for example, is the following desirable? supersum([[1], [2], [3]], 4) 22 I would have thought that the correct answer would be

Re: Weird behaviour?

On Apr 21, 9:19 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote: You're running this under Windows. The convention on Windows is for end-of-line to be signalled with \r\n, but the convention inside Python is to use

Re: Weird behaviour?

On Tuesday, April 23, 2013 12:29:57 AM UTC+10, nn wrote: Maybe it is related to this bug? http://bugs.python.org/issue11272 I'm running Python 2.7.2 (on Windows) and that version doesn't appear to have that bug: Python 2.7.2 (default, Apr 23 2013, 11:49:52) [MSC v.1500 32 bit (Intel)] on

Re: Weird behaviour?

On Tue, Apr 23, 2013 at 9:06 AM, jus...@zeusedit.com wrote: On Tuesday, April 23, 2013 12:29:57 AM UTC+10, nn wrote: Maybe it is related to this bug? http://bugs.python.org/issue11272 I'm running Python 2.7.2 (on Windows) and that version doesn't appear to have that bug: Python 2.7.2

Re: Weird behaviour?

On Mon, 22 Apr 2013 07:29:57 -0700, nn wrote: On Apr 21, 9:19 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote: You're running this under Windows. The convention on Windows is for end-of-line to be signalled with

Weird behaviour?

Can someone please explain the following behaviour? I downloaded and compiled the Python 2.7.2 code base. I then created this simple c:\temp\test.py macro: import sys def main(): print(Please Input 120: ) input = raw_input() print(Value Inputed: +

Re: Weird behaviour?

On Mon, Apr 22, 2013 at 10:37 AM, jus...@zeusedit.com wrote: Can someone please explain the following behaviour? If I run the macro using the -u (flush buffers) option the if statement always fails: C:\Temppython.exe -u c:\temp\test.py Please Input 120: 120 Value

Re: Weird behaviour?

On Sun, 21 Apr 2013 17:37:18 -0700, jussij wrote: Can someone please explain the following behaviour? I downloaded and compiled the Python 2.7.2 code base. I then created this simple c:\temp\test.py macro: import sys def main(): print(Please Input 120: )

Re: Weird behaviour?

On Monday, April 22, 2013 10:56:11 AM UTC+10, Chris Angelico wrote: so your string actually contains '120\r', as will be revealed by its repr(). Thanks Chris. That makes sense. Cheers Jussi -- http://mail.python.org/mailman/listinfo/python-list

Re: Weird behaviour?

On Mon, Apr 22, 2013 at 11:05 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I cannot confirm that behaviour. It works fine for me. I should mention: Under Linux, there's no \r, so -u or no -u, the program will work fine. ChrisA --

Re: Weird behaviour?

On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote: You're running this under Windows. The convention on Windows is for end-of-line to be signalled with \r\n, but the convention inside Python is to use just \n. With the normal use of buffered and parsed input, this is all handled for

Re: Weird behaviour?

On Monday, April 22, 2013 11:05:11 AM UTC+10, Steven D'Aprano wrote: I cannot confirm that behaviour. It works fine for me. As Chris pointed out there is a \r character at the end of the string and that is causing the if to fail. I can now see the \r :) So this is *Windows only* behaviour.

Re: weird behaviour: pygame plays in shell but not in script

On Thu, Mar 29, 2012 at 11:41 PM, Mik mikp...@gmail.com wrote: I can't believe I am so dumb! after sound.play() the script was terminating I didn't notice that 'play()' actually returns... What a nice way to introduce myself to the group!!! :-) sorry for bothering you guys :-) You've

Re: weird behaviour: pygame plays in shell but not in script

Mik wrote: Oh thanks alex! that's kind! PS: It looks like a party indeed: plenty of interesting discussions :-) On Mar 30, 4:33 am, alex23 wuwe...@gmail.com wrote: On Mar 29, 10:41 pm, Mik mikp...@gmail.com wrote: What a nice way to introduce myself to the group!!! :-) Hey,

Re: weird behaviour: pygame plays in shell but not in script

I can't believe I am so dumb! after sound.play() the script was terminating I didn't notice that 'play()' actually returns... What a nice way to introduce myself to the group!!! :-) sorry for bothering you guys :-) -- http://mail.python.org/mailman/listinfo/python-list

weird behaviour: pygame plays in shell but not in script

Dear all, I am a bit frustrated by the following as I believe it is something silly that I am not able to see. I am using python 2.7.1+ under ubuntu. When I run the following script as in $python script.py I do not get any sound out of it BUT if I run every line in the python shell it works

Re: weird behaviour: pygame plays in shell but not in script

On Mar 29, 10:41 pm, Mik mikp...@gmail.com wrote: What a nice way to introduce myself to the group!!! :-) Hey, don't beat yourself up, you: - summarised the problem in the subject heading - included actual code showing the problem - reported back on the problem you found That puts you ahead

Re: weird behaviour: pygame plays in shell but not in script

Oh thanks alex! that's kind! PS: It looks like a party indeed: plenty of interesting discussions :-) On Mar 30, 4:33 am, alex23 wuwe...@gmail.com wrote: On Mar 29, 10:41 pm, Mik mikp...@gmail.com wrote: What a nice way to introduce myself to the group!!! :-) Hey, don't beat yourself up,

Re: weird behaviour: pygame plays in shell but not in script

On Mar 30, 8:33 am, alex23 wuwe...@gmail.com wrote: On Mar 29, 10:41 pm, Mik mikp...@gmail.com wrote: What a nice way to introduce myself to the group!!! :-) Hey, don't beat yourself up, you:  - summarised the problem in the subject heading  - included actual code showing the problem  -

RE: Weird behaviour re: Python on Windows

@python.org] On Behalf Of Jerry Hill Sent: Tuesday, January 13, 2009 11:43 PM To: python-list (General) Subject: Re: Weird behaviour re: Python on Windows On Tue, Jan 13, 2009 at 5:29 PM, Kevin Jing Qiu kevin.jing...@caseware.com wrote: I've been experiencing weird behavior of Python's os module

Weird behaviour re: Python on Windows

I've been experiencing weird behavior of Python's os module on Windows: Here's the environment: Box1: Running Windows 2003 Server with Apache+mod_python Box2: Running Windows 2003 Server with Zope/Plone and Z:\ mapped to D:\ on Box1 It appears any os calls that deals with file/dir on the mapped

Re: Weird behaviour re: Python on Windows

On Tue, Jan 13, 2009 at 5:29 PM, Kevin Jing Qiu kevin.jing...@caseware.com wrote: I've been experiencing weird behavior of Python's os module on Windows: Here's the environment: Box1: Running Windows 2003 Server with Apache+mod_python Box2: Running Windows 2003 Server with Zope/Plone and Z:\

Re: pydev and psycopg2 - weird behaviour

psycopg2 in a non-Django program, I'm seeing some weird behaviour My import psycopg2 is tagged in pyDev (eclipse) as Unresolved Import: psycopg2 But when I run my code anyway, I seem to connect to the postgresql DB okay. If I remove the import, and try it, it fails. So it seems to use

pydev and psycopg2 - weird behaviour

I've been using pydev for a short while successfully, and Django with postgresql as well. psycopg2 is part of that behind the scenes I would imagine, to make django work. Now I'm trying to use psycopg2 in a non-Django program, I'm seeing some weird behaviour My import psycopg2 is tagged

PyOpenGL, wxPython weird behaviour

Hi everyone, I'm doing a project using wxPython and pyopengl, and I seem to have a problem rendering textures. This is code that worked before my hard drive had a meltdown, but not since I re-installed everything. I've determined the problem is in the OpenGL part of my program. I do some

Re: PyOpenGL, wxPython weird behaviour

On Jan 3, 11:50 am, Adeola Bannis [EMAIL PROTECTED] wrote: Hi everyone, I'm doing a project using wxPython and pyopengl, and I seem to have a problem rendering textures. This is code that worked before my hard drive had a meltdown, but not since I re-installed everything. I've determined

Re: PyOpenGL, wxPython weird behaviour

Thanks, will do... On Jan 3, 2:07 pm, [EMAIL PROTECTED] wrote: On Jan 3, 11:50 am, Adeola Bannis [EMAIL PROTECTED] wrote: Hi everyone, I'm doing a project using wxPython and pyopengl, and I seem to have a problem rendering textures. This is code that worked before my hard drive had a

Re: weird behaviour of 0 in [] is False

Sylvain Thenault wrote: Hi there ! Can someone explain me the following behaviour ? l = [] 0 in (l is False) Traceback (most recent call last): File stdin, line 1, in ? TypeError: iterable argument required (0 in l) is False True 0 in l is False False This is really obscur to me... A

Re: weird behaviour of 0 in [] is False

Paul Robson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Sylvain Thenault wrote: l = [] 0 in (l is False) (l is False) is not a tuple or list, it's a boolean value. Traceback (most recent call last): File stdin, line 1, in ? TypeError: iterable argument required (0 in l) is False