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, object.__getatt

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). Therefore,

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

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 run

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 suggestion

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, we've

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 propos

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 i

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 av

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 th

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 th

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

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

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

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: [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: [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 is

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

Some of the ideas are borrowed from Java, and some are from "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

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

Some of the ideas are borrowed from Java, and some are from "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

Re: getting rid of —

On 3 Jul., 18:54, MRAB wrote: > Tep wrote: > > On 3 Jul., 16:58, "Mark Tolonen" wrote: > >> "Tep" wrote in message > > >>news:46d36544-1ea2-4391-8922-11b8127a2...@o6g2000yqj.googlegroups.com... > > >>> On 3 Jul., 06:40, Simon Forman wrote: > On Jul 2, 4:31 am, Tep wrote: > >> [snip] > >>>

Re: getting rid of —

Tep wrote: On 3 Jul., 16:58, "Mark Tolonen" wrote: "Tep" wrote in message news:46d36544-1ea2-4391-8922-11b8127a2...@o6g2000yqj.googlegroups.com... On 3 Jul., 06:40, Simon Forman wrote: On Jul 2, 4:31 am, Tep wrote: [snip] how can I replace '—' sign from string? Or do split at that

Re: getting rid of —

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

Re: getting rid of —

"Tep" wrote in message news:46d36544-1ea2-4391-8922-11b8127a2...@o6g2000yqj.googlegroups.com... On 3 Jul., 06:40, Simon Forman wrote: > On Jul 2, 4:31 am, Tep wrote: [snip] > > > > > how can I replace '—' sign from string? Or do split at that > > > > > character? > > > > > Getting unicode

Re: getting rid of —

On 3 Jul., 06:40, Simon Forman wrote: > On Jul 2, 4:31 am, Tep wrote: > > > > > > > On 2 Jul., 10:25, Tep wrote: > > > > On 2 Jul., 01:56, MRAB wrote: > > > > > someone wrote: > > > > > Hello, > > > > > > how can I replace '—' sign from string? Or do split at that character? > > > > > Getting u

Re: getting rid of —

On Jul 2, 4:31 am, Tep wrote: > On 2 Jul., 10:25, Tep wrote: > > > > > On 2 Jul., 01:56, MRAB wrote: > > > > 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: > > > > > UnicodeDecodeErro

Re: getting rid of —

On 2 Jul., 10:25, Tep wrote: > On 2 Jul., 01:56, MRAB wrote: > > > 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

Re: getting rid of —

On 2 Jul., 01:56, MRAB wrote: > 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) > > > Than

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 li

Re: getting rid of —

someone 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. I s

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 -*- -- http://mail.python.org/mail

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

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 = OptionPar

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() parser.add_option('-G','--green'

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 keywor

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

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?

On Sep 22, 10:23?pm, [EMAIL PROTECTED] wrote: > On Sep 22, 9:10 pm, Paul Rubin 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+lib

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 operat

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 tu

Re: Getting rid of bitwise operators in Python 3?

On Sep 22, 9:10 pm, Paul Rubin 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: > 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, 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 operat

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

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

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' Rints

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 ma

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

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

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

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

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 (x&1)!", > 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 operat

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 ** oper

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(...) digits(x[,b

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 Pyt

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?

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

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 t

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

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" keyw

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

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 litera

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 bec

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 fl

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 ma

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 li

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) -- http://mail.python.org/mailman/lis

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;

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

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 cod

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 e

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 li

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 ?

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

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

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

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 ext

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

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 pass

unction/statement. Many languages have 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, bu

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 find

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 co

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

Re: Getting rid of "self."

var is local to the function or an instance member. For me, 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 g

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

"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 TDD-b

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 Some do -- Kent Beck's excellent book on TDD-by-example has a specific grouse against that in the chapter where he de

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

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

Re: Getting rid of "self."

Roy Smith wrote: It's actually kind of neat, but boy does it play headgames with me when I switch back and forth between that and Python. Switching back and forth betwen C++ and Python plays headgames *anyway* }:> Cheers, Nick. Hardware control with Python is nice. . . -- Nick Coghlan | [EMAIL

Re: Getting rid of "self."

Jeremy Bowers <[EMAIL PROTECTED]> wrote: > were I programming in C++ routinely now I'd prefix "this" and > dispense with that ugly "m_" garbage. (One of the things I ***hate*** > about C++ culture is its acceptance of hideously ugly variable names, > but now I'm two parentheticals deep so I prob

Re: Getting rid of "self."

On Fri, 07 Jan 2005 14:39:09 +0100, BJÃrn Lindqvist wrote: > It works! exec(magic()) does the needed hi = self.hi. No it doesn't. Try "hi = 'newValue'" and see what happens. So the next step is to write an "unmagic" function. So now how do you add instance variables? There is no way to avoid "se

Re: Getting rid of "self."

"BJörn Lindqvist" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] 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 ther

Re: Getting rid of "self."

In article <[EMAIL PROTECTED]>, John Roth <[EMAIL PROTECTED]> wrote: > >"Roy Smith" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> Simon Brunning <[EMAIL PROTECTED]> wrote: >>>On 7 Jan 2005 08:10:14 -0800, Luis M. Gonzalez <[EMAIL PROTECTED]> wrote: The word "self" is not ma

Re: Getting rid of "self."

"Roy Smith" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] 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 key

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 instancevar2local

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/pytho

  1   2   >