Re: The pythonic way equal to "whoami"

Christopher Head wrote: > It is. Until Linux capabilities, EUID==0 used to be special-cased in the > kernel Thank you all, I got a good learning *and* something to rememeber. -- goto /dev/null -- http://mail.python.org/mailman/listinfo/python-list

Re: The pythonic way equal to "whoami"

On 07Jun2011 20:22, Nitin Pawar wrote: | import getpass | user = getpass.getuser() | | On Tue, Jun 7, 2011 at 7:54 PM, TheSaint wrote: | > I was trying to find out whose the program launcher, but os.environ['USER'] | > returns the user whom owns the desktop environment, regardless the program |

Re: The pythonic way equal to "whoami"

On Wed, 08 Jun 2011 21:58:17 +0800, TheSaint wrote: >> os.geteuid > This return 0 for *root* . I don't know if it's a standard for all distro. UID 0 is the "superuser". The name "root" is conventional, but it's the EUID (effective UID) which is used in permission checks; the kernel doesn't care a

Re: The pythonic way equal to "whoami"

On Wed, 08 Jun 2011 21:58:17 +0800 TheSaint wrote: > Kushal Kumaran wrote: > > > os.geteuid > This return 0 for *root* . I don't know if it's a standard for all > distro. Mine is Archlinux. > I'd just like to avoid error caused by wrong access by user > It is. Until Linux capabilities, EUID==0

Re: The pythonic way equal to "whoami"

Kushal Kumaran wrote: > os.geteuid This return 0 for *root* . I don't know if it's a standard for all distro. Mine is Archlinux. I'd just like to avoid error caused by wrong access by user -- goto /dev/null -- http://mail.python.org/mailman/listinfo/python-list

Re: The pythonic way equal to "whoami"

On Tue, Jun 7, 2011 at 7:54 PM, TheSaint wrote: > Hello, > I was trying to find out whose the program launcher, but os.environ['USER'] > returns the user whom owns the desktop environment, regardless the program > is called by root. > I'd like to know it, so the program will run with the right pri

Re: The pythonic way equal to "whoami"

import getpass user = getpass.getuser() On Tue, Jun 7, 2011 at 7:54 PM, TheSaint wrote: > Hello, > I was trying to find out whose the program launcher, but os.environ['USER'] > returns the user whom owns the desktop environment, regardless the program > is called by root. > I'd like to know it,

The pythonic way equal to "whoami"

Hello, I was trying to find out whose the program launcher, but os.environ['USER'] returns the user whom owns the desktop environment, regardless the program is called by root. I'd like to know it, so the program will run with the right privileges. Is there any standard function on python, that

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On 5 сент, 19:23, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > Ivan Illarionov schrieb: > > > > > On 4 сент, 21:49, Bruno Desthuilliers > > <[EMAIL PROTECTED]> wrote: > >> Ivan Illarionov a écrit : > > >>> On 4 сент, 22:59, Carl Banks <[EMAIL PROTECTED]> wrote: > You can write code to guard

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Ivan Illarionov schrieb: > On 4 сент, 21:49, Bruno Desthuilliers > <[EMAIL PROTECTED]> wrote: >> Ivan Illarionov a écrit : >> >> >> >>> On 4 сент, 22:59, Carl Banks <[EMAIL PROTECTED]> wrote: You can write code to guard against this if you want: class A: legal = set(["x"])

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Thu, Sep 4, 2008 at 7:15 PM, Timothy Grant <[EMAIL PROTECTED]> wrote: > > I think the most obvious solution to the problem is effective unit > tests. If you type "a.y =1" and have a test that asserts a.x == 1 then > you would quite quickly discover that you made a typo. > > > -- > Stand Fast, >

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Marco Bizzarri wrote: I understand that Python is a balance between different forces (like any software object around the world) and I'm simply asking some pointers to the discussion leading to this balance. The original decisions by Guido were nearly 20 years ago and other discussions are

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Thu, Sep 4, 2008 at 8:59 PM, Carl Banks <[EMAIL PROTECTED]> wrote: > > > You can write code to guard against this if you want: > > class A: >legal = set(["x"]) >def __setattr__(self,attr,val): >if attr not in self.legal: >raise AttributeError("A object has no attribut

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Sep 4, 3:15 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote: > On 4 ÓÅÎÔ, 22:59, Carl Banks <[EMAIL PROTECTED]> wrote: > > You can write code to guard against this if you want: > > > class A: > > legal = set(["x"]) > > def __setattr__(self,attr,val): > > if attr not in self.legal: > >

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Ivan Illarionov a écrit : On 4 сент, 21:49, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: Ivan Illarionov a écrit : On 4 сент, 22:59, Carl Banks <[EMAIL PROTECTED]> wrote: You can write code to guard against this if you want: class A: legal = set(["x"]) def __setattr__(self,attr,va

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On 4 сент, 21:49, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Ivan Illarionov a écrit : > > > > > On 4 сент, 22:59, Carl Banks <[EMAIL PROTECTED]> wrote: > >> You can write code to guard against this if you want: > > >> class A: > >> legal = set(["x"]) > >> def __setattr__(self,attr,va

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Ivan Illarionov a écrit : On 4 сент, 22:59, Carl Banks <[EMAIL PROTECTED]> wrote: You can write code to guard against this if you want: class A: legal = set(["x"]) def __setattr__(self,attr,val): if attr not in self.legal: raise AttributeError("A object has no attrib

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On 4 сент, 22:59, Carl Banks <[EMAIL PROTECTED]> wrote: > You can write code to guard against this if you want: > > class A: >     legal = set(["x"]) >     def __setattr__(self,attr,val): >         if attr not in self.legal: >             raise AttributeError("A object has no attribute '%s'" % > at

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Sep 4, 7:09 am, "Marco Bizzarri" <[EMAIL PROTECTED]> wrote: > Sorry... pressed enter but really didn't want to. > > As I said, let's say I have a class > > class A: > def __init__(self): > self.x = None > > Python makes the decision to allow the developers to directly access > the a

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Thu, Sep 4, 2008 at 4:09 AM, Marco Bizzarri <[EMAIL PROTECTED]> wrote: > Sorry... pressed enter but really didn't want to. > > As I said, let's say I have a class > > class A: >def __init__(self): > self.x = None > > > > Python makes the decision to allow the developers to directly a

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Sep 4, 7:09 am, "Marco Bizzarri" <[EMAIL PROTECTED]> wrote: > Sorry... pressed enter but really didn't want to. > > As I said, let's say I have a class > > class A: >     def __init__(self): >          self.x = None > > Python makes the decision to allow the developers to directly access > the a

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Thu, Sep 4, 2008 at 2:43 PM, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: Well, Bruno, it looks like I've to wider my search in order to read something about it. Thanks for your suggestions, in any case. Regards Marco -- Marco Bizzarri http://notenotturne.blogspot.com/ http://iliveinpi

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Thu, Sep 4, 2008 at 4:39 PM, Marco Bizzarri <[EMAIL PROTECTED]> wrote: > > Most probably you're right. Maybe I will make a trip back to my > university books and take a look at them again :-) > Meant: you *are* right. Sorry. Saluti Marco -- Marco Bizzarri http://notenotturne.blogspot.com/ ht

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Thu, Sep 4, 2008 at 1:19 PM, Diez B. Roggisch <[EMAIL PROTECTED]> wrote: > > What you are essentially asking is: why is python dynamic instead of static? > Most probably you're right. Maybe I will make a trip back to my university books and take a look at them again :-) Thanks Marco -- Marc

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Marco Bizzarri a écrit : Sorry... pressed enter but really didn't want to. As I said, let's say I have a class class A: def __init__(self): self.x = None Python makes the decision to allow the developers to directly access the attribute "x", So do Java, if you make your attrib

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

> Of course, I know that while I'm fresh, I've a good knowledge of the > code, and anything else, I will be able to avoid such stupid errors; > however, I'm afraid of the times when I'm tired, when I have to put my > hands on the code of someone else, and so on. > > Please, understand that I'm not

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Sorry... pressed enter but really didn't want to. As I said, let's say I have a class class A: def __init__(self): self.x = None Python makes the decision to allow the developers to directly access the attribute "x", so that they can directly write: "a.x = 1", or whatever; this h

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

On Thu, Sep 4, 2008 at 1:00 PM, Diez B. Roggisch <[EMAIL PROTECTED]> wrote: > Marco Bizzarri wrote: > >> Let's say I've a class a, where I can write: > > Anticipating this obviously premature posting: > > http://dirtsimple.org/2004/12/python-is-not-java.html > > Diez > -- > http://mail.python.org/m

Re: Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Marco Bizzarri wrote: > Let's say I've a class a, where I can write: Anticipating this obviously premature posting: http://dirtsimple.org/2004/12/python-is-not-java.html Diez -- http://mail.python.org/mailman/listinfo/python-list

Understanding the pythonic way: why a.x = 1 is better than a.setX(1) ?

Let's say I've a class a, where I can write: -- Marco Bizzarri http://notenotturne.blogspot.com/ http://iliveinpisa.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list

The pythonic way

Hi, I have started reWriting the stuffs under header 'The Pythonic way !', the small code segments are kept at http://guruvision.in/ , pl let me know more topics ideas to write, work. is there anyone who has worked with python in geometry/maths domain ? - somesh -- http://mail.

RE: Controlling a generator the pythonic way

FWIW, PEP 342 is now titled "Coroutines via Enhanced Iterators" :) Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > I'm trying to figure out what is the most pythonic way to interact with a > generator. JFTR, so you don't think I'd suddenly lost interest: I won't be able to respond for a couple of days because I've just incurred a nice little hospital session... will be back next week. -

RE: Controlling a generator the pythonic way

Steve Holden wrote: > Sigh indeed. But if you allow next() calls to take arguments you are > effectively arguing for the introduction of full coroutines into the > language, and I suspect there would be pretty limited support for > that. You mean `PEP 342`_ which I posted earlier and is consider

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Peter Hansen wrote: > > >>Thomas Lotze wrote: >> >>>I can see two possibilities to do this: either the current file position >>>has to be read from somewhere (say, a mutable object passed to the >>>generator) after each yield, [...] >> >>The third approach, which is certain

RE: Controlling a generator the pythonic way

Thomas Lotze wrote: > call. The picture might fit better (IMO) if it didn't look so much > like working around the fact that the next() call can't take > parameters for some technical reason. You might want to take a look at PEP 342 . Doesn't help you no

Re: Controlling a generator the pythonic way

"news:[EMAIL PROTECTED] > Thomas Lotze <[EMAIL PROTECTED]> writes: >> A related problem is skipping whitespace. Sometimes you don't care about >> whitespace tokens, sometimes you do. Using generators, you can either >> set >> a state variable, say on the object the generator is an attribute of, >

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Mike Meyer wrote: > What worries me about the approach of changing state before making a > next() call instead of doing it at the same time by passing a parameter is > that the state change is meant to affect only a single call. The picture > might fit better (IMO) if it didn'

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > A related problem is skipping whitespace. Sometimes you don't care about > whitespace tokens, sometimes you do. Using generators, you can either set > a state variable, say on the object the generator is an attribute of, > before each call that requires a deviation from the d

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Does anybody here have a third way of dealing with this? Sleeping a night sometimes is an insightful exercise *g* I realized that there is a reason why fiddling with the pointer from outside the generator defeats much of the purpose of using one. The implementation using a

Re: Controlling a generator the pythonic way

Peter Hansen wrote: > Fair enough, but who cares what the generator code thinks? It's what the > programmer has to deal with that matters, and an object is going to have a > cleaner interface than a generator-plus-mutable-object. That's right, and among the choices discussed, the object is the o

Re: Controlling a generator the pythonic way

Mike Meyer wrote: > Yes, such a switch gets the desired behavior as a side effect. Then again, > a generator that returns tokens has a desired behavior (advancing to the > next token) as a side effect(*). That's certainly true. > If you think about these things as the > state of the object, rath

Re: Controlling a generator the pythonic way

Thomas Lotze <[EMAIL PROTECTED]> writes: > A related problem is skipping whitespace. Sometimes you don't care about > whitespace tokens, sometimes you do. Using generators, you can either set > a state variable, say on the object the generator is an attribute of, > before each call that requires a

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Which is, as far as the generator code is concerned, basically the same as > passing a mutable object to a (possibly standalone) generator. The object > will likely be called self, and the value is stored in an attribute of it. Fair enough, but who cares what the generator co

Re: Controlling a generator the pythonic way

Peter Hansen wrote: > Thomas Lotze wrote: >> I can see two possibilities to do this: either the current file position >> has to be read from somewhere (say, a mutable object passed to the >> generator) after each yield, [...] > > The third approach, which is certain to be cleanest for this situat

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > I can see two possibilities to do this: either the current file position > has to be read from somewhere (say, a mutable object passed to the > generator) after each yield, or a new generator needs to be instantiated > every time the tokenizer is pointed to a new file position

Controlling a generator the pythonic way

Hi, I'm trying to figure out what is the most pythonic way to interact with a generator. The task I'm trying to accomplish is writing a PDF tokenizer, and I want to implement it as a Python generator. Suppose all the ugly details of toknizing PDF can be handled (such as embedded streams of arbitr