Re: getting rid of the recursion in __getattribute__

On 24/05/2023 15:37, A KR wrote: It is perfectly explained in the standards here [1] saying that: In order to avoid infinite recursion in this method, its implementation should always call the base class method with the same name to access any attributes it needs, for example,

getting rid of the recursion in __getattribute__

It is perfectly explained in the standards here [1] saying that: In order to avoid infinite recursion in this method, its implementation should always call the base class method with the same name to access any attributes it needs, for example, object.__getattribute__(self, name).

[issue400771] _tkinter: getting rid of two unused variables

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400771] _tkinter: getting rid of two unused variables

Change by admin : -- github: None -> 32540 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Re: Getting rid of virtual environments with a better dependency system

On Fri, Nov 13, 2020 at 9:41 AM Peter J. Holzer wrote: > > On 2020-11-12 10:56:45 +1100, Chris Angelico wrote: > > On Thu, Nov 12, 2020 at 10:44 AM Dan Stromberg wrote: > > > I do get a .../bin/backshift though, which is a bash script that > > > knows how to start up python on the main module.

Re: Getting rid of virtual environments with a better dependency system

On 2020-11-12 10:56:45 +1100, Chris Angelico wrote: > On Thu, Nov 12, 2020 at 10:44 AM Dan Stromberg wrote: > > I do get a .../bin/backshift though, which is a bash script that > > knows how to start up python on the main module. So the user need > > not source something at install time or at

Re: Getting rid of virtual environments with a better dependency system

On Thu, Nov 12, 2020 at 10:44 AM Dan Stromberg wrote: > > > On Wed, Nov 11, 2020 at 10:38 AM Chris Angelico wrote: >> >> On Thu, Nov 12, 2020 at 4:35 AM Dan Stromberg wrote: >> > >> > On Wed, Nov 11, 2020 at 3:00 AM j c wrote: >> > >> > > Hello all, >> > > >> > > I don't know if this

Re: Getting rid of virtual environments with a better dependency system

On Wednesday, 11 November 2020 at 12:22:24 UTC+1, Chris Angelico wrote: > On Wed, Nov 11, 2020 at 10:06 PM j c wrote: > > > > Hello all, > > > > I don't know if this suggestion is missing some point, or it's part of > > something already proposed. > > > > In a professional environment,

Re: Getting rid of virtual environments with a better dependency system

On Wed, Nov 11, 2020 at 10:38 AM Chris Angelico wrote: > On Thu, Nov 12, 2020 at 4:35 AM Dan Stromberg wrote: > > > > On Wed, Nov 11, 2020 at 3:00 AM j c wrote: > > > > > Hello all, > > > > > > I don't know if this suggestion is missing some point, or it's part of > > > something already

Re: Getting rid of virtual environments with a better dependency system

On Thu, Nov 12, 2020 at 4:35 AM Dan Stromberg wrote: > > On Wed, Nov 11, 2020 at 3:00 AM j c wrote: > > > Hello all, > > > > I don't know if this suggestion is missing some point, or it's part of > > something already proposed before. > > > > In a professional environment, we've came to a point

Re: Getting rid of virtual environments with a better dependency system

On Wed, Nov 11, 2020 at 3:00 AM j c wrote: > Hello all, > > I don't know if this suggestion is missing some point, or it's part of > something already proposed before. > > In a professional environment, we've came to a point in which most people > use virtual environments or code environments to

Re: Getting rid of virtual environments with a better dependency system

On Wed, Nov 11, 2020 at 10:06 PM j c wrote: > > Hello all, > > I don't know if this suggestion is missing some point, or it's part of > something already proposed. > > In a professional environment, we've came to a point in which most people use > virtual environments or conda environments to

Getting rid of virtual environments with a better dependency system

Hello all, I don't know if this suggestion is missing some point, or it's part of something already proposed. In a professional environment, we've came to a point in which most people use virtual environments or conda environments to avoid "polluting a global environment". However, I think

Getting rid of virtual environments with a better dependency system

Hello all, I don't know if this suggestion is missing some point, or it's part of something already proposed before. In a professional environment, we've came to a point in which most people use virtual environments or code environments to avoid "polluting a global environment". However, I

Re: Getting rid of

On Sun, 12 Apr 2015 21:27:30 +0200, Cecil Westerhof wrote: When you run my script you do not get warnings? I ran into too many issues trying to install the modules I needed to try and run it. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list

Getting rid of

I am playing a little bit with libturpial. I got a few warnings. Most I could get rid of, but one I still get, while I have done what is said in the reference of the warning. Example code: #!/usr/bin/env python import certifi import urllib3 import urllib3.contrib.pyopenssl

Re: Getting rid of

On Sun, 12 Apr 2015 19:48:53 +0200, Cecil Westerhof wrote: What should I do to get rid of the warnings: /usr/lib/python2.7/site-packages/requests-2.6.0-py2.7.egg/requests/ packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made.

Re: Getting rid of

Op Sunday 12 Apr 2015 20:54 CEST schreef Denis McMahon: On Sun, 12 Apr 2015 19:48:53 +0200, Cecil Westerhof wrote: What should I do to get rid of the warnings: /usr/lib/python2.7/site-packages/requests-2.6.0-py2.7.egg/requests/ packages/urllib3/connectionpool.py:769: InsecureRequestWarning:

[ANN]: newthreading - an approach to simplified thread usage, and a path to getting rid of the GIL

safethreading. The point is to come up with a set of liveable restrictions which would allow getting rid of the GIL. This is becoming essential as Unladen Swallow starts to work and the number of processors per machine keeps climbing. This may in time become a Python Enhancement Proposal. We'd like

[ANN]: newthreading - an approach to simplified thread usage, and a path to getting rid of the GIL

safethreading. The point is to come up with a set of liveable restrictions which would allow getting rid of the GIL. This is becoming essential as Unladen Swallow starts to work and the number of processors per machine keeps climbing. This may in time become a Python Enhancement Proposal. We'd like

[ANN]: newthreading - an approach to simplified thread usage, and a path to getting rid of the GIL

safethreading. The point is to come up with a set of liveable restrictions which would allow getting rid of the GIL. This is becoming essential as Unladen Swallow starts to work and the number of processors per machine keeps climbing. This may in time become a Python Enhancement Proposal. We'd like

Re: [ANN]: newthreading - an approach to simplified thread usage, and a path to getting rid of the GIL

I only had a couple minutes to look at it (maybe more during the weekend). It looks interesting. I wonder whether Python is really the right host language for it. How do you handle nested objects whose outermost layer is immutable but whose contents are potentially mutable? An obvious example

Re: [ANN]: newthreading - an approach to simplified thread usage, and a path to getting rid of the GIL

On 6/25/2010 4:14 PM, Paul Rubin wrote: I only had a couple minutes to look at it (maybe more during the weekend). It looks interesting. I wonder whether Python is really the right host language for it. How do you handle nested objects whose outermost layer is immutable but whose contents are

Re: getting rid of —

On 3 Jul., 06:40, Simon Forman sajmik...@gmail.com wrote: On Jul 2, 4:31 am, Tep petshm...@googlemail.com wrote: On 2 Jul., 10:25, Tep petshm...@googlemail.com wrote: On 2 Jul., 01:56, MRAB pyt...@mrabarnett.plus.com wrote: someone wrote: Hello, how can I replace '—'

Re: getting rid of —

Tep petshm...@googlemail.com wrote in message news:46d36544-1ea2-4391-8922-11b8127a2...@o6g2000yqj.googlegroups.com... On 3 Jul., 06:40, Simon Forman sajmik...@gmail.com wrote: On Jul 2, 4:31 am, Tep petshm...@googlemail.com wrote: [snip] how can I replace '—' sign from string? Or do

Re: getting rid of —

On 3 Jul., 16:58, Mark Tolonen metolone+gm...@gmail.com wrote: Tep petshm...@googlemail.com wrote in message news:46d36544-1ea2-4391-8922-11b8127a2...@o6g2000yqj.googlegroups.com... On 3 Jul., 06:40, Simon Forman sajmik...@gmail.com wrote: On Jul 2, 4:31 am, Tep

Re: getting rid of —

Tep wrote: On 3 Jul., 16:58, Mark Tolonen metolone+gm...@gmail.com wrote: Tep petshm...@googlemail.com wrote in message news:46d36544-1ea2-4391-8922-11b8127a2...@o6g2000yqj.googlegroups.com... On 3 Jul., 06:40, Simon Forman sajmik...@gmail.com wrote: On Jul 2, 4:31 am, Tep

Re: getting rid of —

On 3 Jul., 18:54, MRAB pyt...@mrabarnett.plus.com wrote: Tep wrote: On 3 Jul., 16:58, Mark Tolonen metolone+gm...@gmail.com wrote: Tep petshm...@googlemail.com wrote in message news:46d36544-1ea2-4391-8922-11b8127a2...@o6g2000yqj.googlegroups.com... On 3 Jul., 06:40, Simon Forman

Re: getting rid of —

On Jul 2, 4:31 am, Tep petshm...@googlemail.com wrote: On 2 Jul., 10:25, Tep petshm...@googlemail.com wrote: On 2 Jul., 01:56, MRAB pyt...@mrabarnett.plus.com wrote: someone wrote: Hello, how can I replace '—' sign from string? Or do split at that character? Getting unicode

getting rid of —

Hello, how can I replace '—' sign from string? Or do split at that character? Getting unicode error if I try to do it: UnicodeDecodeError: 'ascii' codec can't decode byte 0x97 in position 1: ordinal not in range(128) Thanks, Pet script is # -*- coding: UTF-8 -*- --

Re: getting rid of —

someone petshmidt at googlemail.com writes: Hello, how can I replace '—' sign from string? Or do split at that character? Getting unicode error if I try to do it: UnicodeDecodeError: 'ascii' codec can't decode byte 0x97 in position 1: ordinal not in range(128) Please paste your code.

Re: getting rid of —

someone wrote: Hello, how can I replace '—' sign from string? Or do split at that character? Getting unicode error if I try to do it: UnicodeDecodeError: 'ascii' codec can't decode byte 0x97 in position 1: ordinal not in range(128) Thanks, Pet script is # -*- coding: UTF-8 -*- It sounds

Understanding (and getting rid) of optparse.py:668: FutureWarning: %u/%o/%x/%X of negative int will return a

Hi, I get following warning with a python script: optparse.py:668: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up my code: from optparse import OptionParser if __name__ == '__main__': parser = OptionParser()

Re: Understanding (and getting rid) of optparse.py:668: FutureWarning: %u/%o/%x/%X of negative int will return a

hofer wrote: Hi, I get following warning with a python script: optparse.py:668: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up my code: from optparse import OptionParser if __name__ == '__main__': parser = OptionParser()

Re: Understanding (and getting rid) of optparse.py:668: FutureWarning: %u/%o/%x/%X of negative int will return a

On Sep 26, 6:21 pm, Peter Otten [EMAIL PROTECTED] wrote: hofer wrote: Hi, I get following warning with a python script: optparse.py:668: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up You can print options.__dict__ instead of options with

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 8:44 am, Carl Banks [EMAIL PROTECTED] wrote: Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) Not many people are bit-fiddling these days. One of the main uses of bit fields is flags, but that's not often done in Python because of keyword

Re: Getting rid of bitwise operators in Python 3?

: arguments and dicts, which are lot more versatile. Another major use, : talking to hardware, is not something oft done in Python either. Are you sure? I've been doing lots of exactly that for 4 years, and I'm not the only one round here... Python makes an excellent language for talking to

Re: Getting rid of bitwise operators in Python 3?

[EMAIL PROTECTED] wrote: On Sep 22, 7:04 pm, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Sat, 22 Sep 2007 21:17:38 +, Bryan Olson wrote: The operator module offers pow(). Is there any good reason for pow() as a built-in? The `operator.pow()` is just the function for ``**``, it

Re: Getting rid of bitwise operators in Python 3?

On Sat, 22 Sep 2007 05:06:42 +, Stargaming wrote: On Fri, 21 Sep 2007 23:44:00 -0400, Carl Banks wrote: Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) Not many people are bit-fiddling these days. Why did we invent the `binary literals`_

Re: Getting rid of bitwise operators in Python 3?

On 22/09/2007 1:44 PM, Carl Banks wrote: Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) Not many people are bit-fiddling these days. One of the main uses of bit fields is flags, but that's not often done in Python because of keyword arguments and

Re: Getting rid of bitwise operators in Python 3?

Carl Banks wrote: Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) I'm not. :-) We use them in numpy. The bitwise operations on int and float arrays aren't all that useful, but they are very useful for bool arrays. We can't use the and/or/not keywords

Re: Getting rid of bitwise operators in Python 3?

On Sat, 22 Sep 2007 05:19:42 +, Grant Edwards wrote: On 2007-09-22, Carl Banks [EMAIL PROTECTED] wrote: Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) Not me. Not many people are bit-fiddling these days. I do. Your anecdotal evidence is

Re: Getting rid of bitwise operators in Python 3?

Carl Banks wrote: On Sat, 22 Sep 2007 05:19:42 +, Grant Edwards wrote: I do. Your anecdotal evidence is noted and given all the consideration it's due. Being funny, or being arrogant? Many today's network protocols work with bit flags. It is /not/ anecdotal. I do it all the time.

Re: Getting rid of bitwise operators in Python 3?

On 2007-09-22, Carl Banks [EMAIL PROTECTED] wrote: If you don't want to use the bitwise operations, then ignore them. Presto! Simpler syntax. Until people no longer need to read code written by others, this argument is utter bull. It's completely besides the point, anyways. The point

Re: Getting rid of bitwise operators in Python 3?

Sorry Carl, I think *you* may not have much need for bitwise operators but others, including myself do. No matter what the usage found, I would think replacing bitwise operators by function calls a retrograde step. - Paddy. -- http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of bitwise operators in Python 3?

Carl Banks wrote: Not many people are bit-fiddling these days. One of the main uses of bit fields is flags, but that's not often done in Python because of keyword arguments and dicts, which are lot more versatile. Another major use, talking to hardware, is not something oft done in Python

Re: Getting rid of bitwise operators in Python 3?

On Sep 21, 10:44?pm, Carl Banks [EMAIL PROTECTED] wrote: Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) Are you a loony? Python doesn't have enough bit operations. I'm always using the gmpy module's bit functions: digits(...)

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 11:13 am, Bryan Olson [EMAIL PROTECTED] wrote: One surprising result was that more of the Python programmers surveyed use bitwise operators than are aware of the exponentiation operator, which C does not offer. On that subject, I'd suggest that the pow() builtin (not the ** operator

Re: Getting rid of bitwise operators in Python 3?

Carl Banks [EMAIL PROTECTED] writes: If anyone says, But that takes away an easy test for oddness (x1)!, or, But you can multiply powers of two using left shift! Isn't that cool?, I'm not buying it. Those are gimmicks. Arithmetic operations should be done with arithmetic operators. The

Re: Getting rid of bitwise operators in Python 3?

On Sat, 22 Sep 2007 12:57:35 +, Grant Edwards wrote: On 2007-09-22, Carl Banks [EMAIL PROTECTED] wrote: Of course it would be. The reason I mention it is that automatic convertibility is a key factor in whether a change can make it into Python 3. It matters not whether fugly code is

Re: Getting rid of bitwise operators in Python 3?

On Sat, 22 Sep 2007 14:50:12 +, Paddy wrote: Sorry Carl, I think *you* may not have much need for bitwise operators but others, including myself do. No matter what the usage found, I would think replacing bitwise operators by function calls a retrograde step. Well, if people are going to

Re: Getting rid of bitwise operators in Python 3?

Carl Banks [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | | Is it worth it to make such a change? It would remove a lot of operators | (11 by my count), vastly simplifying syntax, Which, IMHO, is no small | thing. New numerical types would have fewer operations to support. Py3

Re: Getting rid of bitwise operators in Python 3?

[EMAIL PROTECTED] wrote: Bryan Olson wrote: One surprising result was that more of the Python programmers surveyed use bitwise operators than are aware of the exponentiation operator, which C does not offer. On that subject, I'd suggest that the pow() builtin (not the ** operator - just

Re: Getting rid of bitwise operators in Python 3?

On 2007-09-22, Carl Banks [EMAIL PROTECTED] wrote: On Sat, 22 Sep 2007 12:57:35 +, Grant Edwards wrote: On 2007-09-22, Carl Banks [EMAIL PROTECTED] wrote: Of course it would be. The reason I mention it is that automatic convertibility is a key factor in whether a change can make it into

Re: Getting rid of bitwise operators in Python 3?

On Sat, 22 Sep 2007 21:17:38 +, Bryan Olson wrote: The operator module offers pow(). Is there any good reason for pow() as a built-in? The `operator.pow()` is just the function for ``**``, it lacks the optional third argument of the built in `pow()`. Ciao, Marc 'BlackJack'

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 7:04 pm, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Sat, 22 Sep 2007 21:17:38 +, Bryan Olson wrote: The operator module offers pow(). Is there any good reason for pow() as a built-in? The `operator.pow()` is just the function for ``**``, it lacks the optional

Re: Getting rid of bitwise operators in Python 3?

On Sat, 22 Sep 2007 18:09:49 +, richyjsm wrote: On that subject, I'd suggest that the pow() builtin (not the ** operator - just the pow() function) should also be a candidate for removal... Help on built-in function pow in module __builtin__: pow(...) pow(x, y[, z]) - number With

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 7:50 pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: Everybody forgets that pow can take three arguments, except of course for those who use that functionality and would be mighty peeved if it went away. And who is it who uses this functionality? It's useful in

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 3:29 pm, Carl Banks [EMAIL PROTECTED] wrote: On Sat, 22 Sep 2007 14:50:12 +, Paddy wrote: Sorry Carl, I think *you* may not have much need for bitwise operators but others, including myself do. No matter what the usage found, I would think replacing bitwise operators by

Re: Getting rid of bitwise operators in Python 3?

[EMAIL PROTECTED] writes: And who is it who uses this functionality? I use it but I agree it's easy to implement given the underlying bignum arithmetic. It's useful in elementary number theory, sure, but I'd argue that if there are going to be number theoretical functions in the core then

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 9:10 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: Certainly xgcd should be in the math library or somewhere similar. It does feel odd to have modular exponentiation in the core but no other number-theoretic stuff in core+libraries. Perhaps a proposal on python-ideas is in order...

Re: Getting rid of bitwise operators in Python 3?

[EMAIL PROTECTED] writes: Well okay, I take that back---I wouldn't mind *writing* it; I just wouldn't expect to get much speed from *running* it. I don't see why not. It's just the basic Python long arithmetic which is coded in C. I tested it against gmpy (carefully written asm code and

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 8:29 pm, Carl Banks [EMAIL PROTECTED] wrote: On Sat, 22 Sep 2007 14:50:12 +, Paddy wrote: Sorry Carl, I think *you* may not have much need for bitwise operators but others, including myself do. No matter what the usage found, I would think replacing bitwise operators by

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 10:23?pm, [EMAIL PROTECTED] wrote: On Sep 22, 9:10 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: Certainly xgcd should be in the math library or somewhere similar. It does feel odd to have modular exponentiation in the core but no other number-theoretic stuff in core+libraries.

Getting rid of bitwise operators in Python 3?

Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) Not many people are bit-fiddling these days. One of the main uses of bit fields is flags, but that's not often done in Python because of keyword arguments and dicts, which are lot more versatile. Another

Re: Getting rid of bitwise operators in Python 3?

On Fri, 21 Sep 2007 23:44:00 -0400, Carl Banks wrote: Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) Not many people are bit-fiddling these days. Why did we invent the `binary literals`_ (0b101) then? One of the main uses of bit fields is flags,

Re: Getting rid of bitwise operators in Python 3?

On 2007-09-22, Carl Banks [EMAIL PROTECTED] wrote: Anyone with me here? (I know the deadline for P3 PEPs has passed; this is just talk.) Not me. Not many people are bit-fiddling these days. I do. One of the main uses of bit fields is flags, but that's not often done in Python because

getting rid of leading zeros in float expotential

Hi! I'm wondering whether there's an easy way to remove unnecessary leading zeros from my floating point number. realS = float(-1.25e-5) imgS = float(-7.6e4) print complex(realS, imgS) (-1.25e-005-76000j) I would like it to look like (-1.25e-5-76000j) --

Re: getting rid of leading zeros in float expotential

On 3, 11:47, [EMAIL PROTECTED] wrote: Hi! I'm wondering whether there's an easy way to remove unnecessary leading zeros from my floating point number. realS = float(-1.25e-5) imgS = float(-7.6e4) print complex(realS, imgS) (-1.25e-005-76000j) I would like it to look like

Re: getting rid of EOL character ?

hi John, In the previous language I used, when reading a line by readline, the EOL character was removed. Very interesting; how did you distinguish between EOF and an empty line? Did you need to call an isEOF() method before each read? Yes indeed, and I admit it needs some more coding ;-)

Re: getting rid of EOL character ?

John Machin wrote: On 27/04/2007 11:19 PM, Michael Hoffman wrote: stef wrote: hello, In the previous language I used, when reading a line by readline, the EOL character was removed. Very interesting; how did you distinguish between EOF and an empty line? Did you need to call an isEOF()

Re: getting rid of EOL character ?

On Apr 28, 7:25 pm, Michael Hoffman [EMAIL PROTECTED] wrote: John Machin wrote: On 27/04/2007 11:19 PM, Michael Hoffman wrote: stef wrote: hello, In the previous language I used, when reading a line by readline, the EOL character was removed. Very interesting; how did you

getting rid of EOL character ?

hello, In the previous language I used, when reading a line by readline, the EOL character was removed. Now I'm reading a text-file with CR+LF at the end of each line, Datafile = open(filename,'r') line = Datafile.readline() now this gives an extra empty line print line and what I

Re: getting rid of EOL character ?

stef wrote: hello, In the previous language I used, when reading a line by readline, the EOL character was removed. Now I'm reading a text-file with CR+LF at the end of each line, Datafile = open(filename,'r')line = Datafile.readline() now this gives an extra empty line

Re: getting rid of EOL character ?

line = line.rstrip(\r\n) should take care of it. If you leave out the parameter, it will strip out all whitespace at the end of the line, which is what I do in most cases. thanks for the solution Michael, cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list

Re: getting rid of EOL character ?

If you have a recent Python, see the documentation for open on the library page for built-in functions. http://docs.python.org/lib/built-in-funcs.html Jim -- http://mail.python.org/mailman/listinfo/python-list

Re: getting rid of EOL character ?

stef wrote: hello, In the previous language I used, when reading a line by readline, the EOL character was removed. Now I'm reading a text-file with CR+LF at the end of each line, Datafile = open(filename,'r') line = Datafile.readline() now this gives an extra empty line print

Re: getting rid of EOL character ?

On 27/04/2007 11:19 PM, Michael Hoffman wrote: stef wrote: hello, In the previous language I used, when reading a line by readline, the EOL character was removed. Very interesting; how did you distinguish between EOF and an empty line? Did you need to call an isEOF() method before each

PEP proposal : Getting rid of the extension version/compiler dependency

It's been observed a couple times recently ... distributing and compiling extensions is a pain, especially on windows, when the main supported compilers are not freely availble .. nor even commercially availble anymore. What we need is a way to break out of this dependency. A way for python

Re: getting rid of pass

David Murmann a écrit : Hi all! i just had this crazy idea: instead of while cond(): pass write while cond(). Yuck or try: import xyz except ImportError: pass compared to try: import xyz except ImportError. Yuck again i don't know whether this is

getting rid of pass

Hi all! i just had this crazy idea: instead of while cond(): pass write while cond(). or try: import xyz except ImportError: pass compared to try: import xyz except ImportError. i don't know whether this is syntactically unambiguous or replaces all uses of pass, but i

Re: getting rid of pass

the equivalent. Being explicit is Python's style. Getting rid of it would gratuitously break code for no reason other than your esthetic preference. i don't know whether this is syntactically unambiguous or replaces all uses of pass, but i find it quite nice to read. while x/3. would become

Re: getting rid of pass

On 13/05/2006 11:40 AM, David Murmann wrote: Hi all! i just had this crazy idea: You said it. late-in-the-night idea. You said it again. what do you people think? I agree with you. -- http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of close failed: [Errno 0] No Error on Win32

Ok , I tried: try: os.popen3(...) except: as someone suggested here. And on FreeBSD I don't get the error message, and it works great. However, on Win32 I do get the annoying message. Any idea why? And How I can make it go away? thanks. Yoav wrote: I am using os.popen3 to call a

Getting rid of close failed: [Errno 0] No Error on Win32

I am using os.popen3 to call a console process and get its output and stderr. However on Win32 (and not OS X) I also get the Errno message. It's printed to the screen, which I wish to keep clean. How can disable this notification? Thanks. -- http://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] Getting rid of unbound methods: patch available

Guido van Rossum wrote: What do people think? (My main motivation for this, as stated before, is that it adds complexity without much benefit.) Something important that came up in my response to Marc-Andre: What about C method implementations which are relying on this typecheck and assuming that

Re: Getting rid of self.

BJörn Lindqvist [EMAIL PROTECTED] wrote: ... http://starship.python.net/crew/mwh/hacks/selfless.py That's excellent! There is one small problem with the code though: It shows the fundamentals of how to rewrite the bytecode, yes. .class Hi(Selfless): .__attrs__ = [x] .def

Re: Getting rid of self.

BJörn Lindqvist [EMAIL PROTECTED] wrote: I think it would be cool if you could refer to instance variables without prefixing with self. I know noone else thinks like me so Python will never be changed, but maybe you can already do it with Python today? .import sys . .def magic(): .s = .

Re: Getting rid of self.

Alex Martelli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] BJörn Lindqvist [EMAIL PROTECTED] wrote: I think it would be cool if you could refer to instance variables without prefixing with self. I know noone else thinks like me so Some do -- Kent Beck's excellent book on

Re: Getting rid of self.

Thank you for your replies. It is very nice to see that a thread you started is generating so much discussion, but please, I have read the previous debates so I know all about what people think about self. Spare the you shouldn't do that and self is here to stay replies to the threads in which

Re: Getting rid of self.

, I prefer the explicit self and getting rid of self now leaves you with the need to declare member variables *somehow*, which I don't consider progress. But no matter what other magic Alex works, you're only going to get one or the other; it's impossible for the compiler to divine what you mean

Re: Getting rid of self.

BJörn Lindqvist [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think it would be cool if you could refer to instance variables without prefixing with self. Others have expressed such a wish -- this comes up perhaps once a year. The bottom line is that as long as Python has

Getting rid of self.

I think it would be cool if you could refer to instance variables without prefixing with self. I know noone else thinks like me so Python will never be changed, but maybe you can already do it with Python today? .import sys . .def magic(): .s = .for var in

Re: Getting rid of self.

BJörn Lindqvist a écrit : I think it would be cool if you could refer to instance variables without prefixing with self. I know noone else thinks like me so Python will never be changed, but maybe you can already do it with Python today? (snip code) It works! exec(magic()) does the needed hi =

Re: Getting rid of self.

You can do it easier now without any black magic: class c: def __init__(s): s.x = 1 s.y = 2 s.hi = Hi there! The word self is not mandatory. You can type anything you want instead of self, as long as you supply a keyword in its place (it can be self, s or whatever you want). --

Re: Getting rid of self.

On 7 Jan 2005 08:10:14 -0800, Luis M. Gonzalez [EMAIL PROTECTED] wrote: The word self is not mandatory. You can type anything you want instead of self, as long as you supply a keyword in its place (it can be self, s or whatever you want). You *can*, yes, but please don't, not if there's any

Re: Getting rid of self.

Simon Brunning [EMAIL PROTECTED] wrote: On 7 Jan 2005 08:10:14 -0800, Luis M. Gonzalez [EMAIL PROTECTED] wrote: The word self is not mandatory. You can type anything you want instead of self, as long as you supply a keyword in its place (it can be self, s or whatever you want). You *can*,

Re: Getting rid of self.

BJörn Lindqvist [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think it would be cool if you could refer to instance variables without prefixing with self. I know noone else thinks like me so Python will never be changed, but maybe you can already do it with Python today? ... It

Re: Getting rid of self.

Nick Coghlan [EMAIL PROTECTED] wrote: Wait for Python 3k when this will work: class c: def __init__(self): with self: .x = 1 .y = 2 .hi = Hi there! Python is looking more like JavaScript every day... -- http://mail.python.org/mailman/listinfo/python-list

Re: Getting rid of self.

Thank you for your replies. But they don't deal with my original question. :) I have read the thousands of posts all saying self is good and they are right. But this time I want to be different m-kay? I figure that there might be some way to solve my problem by doing this: .def

  1   2   >