On Jan 6, 6:35 am, chaouche yacine wrote:
> Hi. In the standard pytohon interpreter and in ipython, __builtins__ is a
> module, but in bpython it's a dictionnary. Was it redefined ?
I'd say it's a result of however bpython works and this:
"By default, when in the __m
On Sun, Oct 14, 2012 at 9:36 PM, Juergen Bartholomae
wrote:
> Unfortunately, replacing __builtins__ at import time won't do, because
> external modules (that is, .py) get imported only once when they are
> accessed by the first thread, which includes (of course) setting up of
>> One possible solution is to somehow redirect every __builtins__ to a
>> function that returns a different __builtins__ dictionary for each thread
>> (such a function already exists).
>How exactly does the code reference it? If they're simply referring to
>the name
ng this in an earlier release
> (!stupid!)) this meant that, in several cases, there are modules which use
> __builtins__ as a kind of global dictionary, where various variables are
> inserted, changed and read.
>
> Now, currently we are updating our program from a single-thread
On Fri, Oct 12, 2012 at 1:16 AM, Juergen Bartholomae
wrote:
> One possible solution is to somehow redirect every __builtins__ to a
> function that returns a different __builtins__ dictionary for each thread
> (such a function already exists).
How exactly does the code reference it? I
modules which use
__builtins__ as a kind of global dictionary, where various variables are
inserted, changed and read.
Now, currently we are updating our program from a single-threaded to a
multithreaded architecture.
-> Of course, this means that the same module can now run in several
threads
En Thu, 12 May 2011 22:59:24 -0300, Gabriel Genellina
escribió:
En Thu, 12 May 2011 20:29:57 -0300, Aman Nijhawan
escribió:
I was trying to call the builtin function min by using
getattr(__builtins__,'min')
This works at the interpretter prompt
However when I called it insid
En Thu, 12 May 2011 20:29:57 -0300, Aman Nijhawan
escribió:
I was trying to call the builtin function min by using
getattr(__builtins__,'min')
This works at the interpretter prompt
However when I called it inside a module that was imported by another
module
it fails an
I was trying to call the builtin function min by using
getattr(__builtins__,'min')
This works at the interpretter prompt
However when I called it inside a module that was imported by another module
it fails and gives an attribute error
print getattr(__builtins__,'min')(range
On Mar 27, 8:29 pm, John Ladasky wrote:
> Simple question. I use these functions much more frequently than many
> others which are included in __builtins__. I don't know if my
> programming needs are atypical, but my experience has led me to wonder
> why I have to import th
On Mon, 28 Mar 2011 10:30:03 -0700, John Ladasky wrote:
> On Mar 28, 2:25 am, Andrea Crotti wrote:
>> John Ladasky writes: I almost never use them
>> either, maybe also in many cases you could avoid using them...
>> When for example you use them?
>
> To take one example: neural network programm
John Ladasky wrote:
On Mar 28, 2:25 am, Andrea Crotti wrote:
I noticed some time ago in a program that needed speed that deepcopy in
particular is incredibly slow, but I guess is normal since it has to
copy every bit of the data structure.
That may be, but when it already takes several second
On Mon, Mar 28, 2011 at 4:55 AM, Dave Angel wrote:
> I'd expect it to be very slow. I presume it not only has to visit and
> duplicate every bit of the data structure, but also has to detect loops, and
> avoid infinite loops recreating them.
>
> This loop detection is probably an n-squared algori
On Mar 28, 2:25 am, Andrea Crotti wrote:
> John Ladasky writes:
> I almost never use them either, maybe also in many cases you could avoid
> using them...
> When for example you use them?
To take one example: neural network programming. I construct a
network object (which is quite complex), tes
On 01/-10/-28163 02:59 PM, Andrea Crotti wrote:
John Ladasky writes:
Simple question. I use these functions much more frequently than many
others which are included in __builtins__. I don't know if my
programming needs are atypical, but my experience has led me to wonder
why I ha
John Ladasky writes:
> Simple question. I use these functions much more frequently than many
> others which are included in __builtins__. I don't know if my
> programming needs are atypical, but my experience has led me to wonder
> why I have to import these functions.
I almo
On Mar 27, 8:29 pm, John Ladasky wrote:
> Simple question. I use these functions much more frequently than many
> others which are included in __builtins__. I don't know if my
> programming needs are atypical, but my experience has led me to wonder
> why I have to import th
Simple question. I use these functions much more frequently than many
others which are included in __builtins__. I don't know if my
programming needs are atypical, but my experience has led me to wonder
why I have to import these functions.
--
http://mail.python.org/mailman/listinfo/python-list
Lie Ryan wrote:
On Tue, 30 Sep 2008 16:04:34 -0500, William Purcell wrote:
You could remove the builtin if you don't think it is necessary for you.
Or you could do "dictionary comprehension" that collects only names you
require (actually use generator comprehension then do a dict()
conversio
On Tue, 30 Sep 2008 16:04:34 -0500, William Purcell wrote:
> I want to use eval to evaluate wx.TextCtrl inputs. How can I keep python
> from adding the __builtins__ key to mydict when I use it with eval?
> Other wise I have to __delitem__('__builtins__') everytime I use eval?
&
I want to use eval to evaluate wx.TextCtrl inputs. How can I keep python
from adding the __builtins__ key to mydict when I use it with eval? Other
wise I have to __delitem__('__builtins__') everytime I use eval?
>>> mydict = {'a':2,'b':3}
>>> eval(&
En Sun, 07 Sep 2008 19:30:07 -0300, Steven D'Aprano
<[EMAIL PROTECTED]> escribió:
Gabriel, could I please ask you to configure your news-reader software or
editor to limit the length of each line of your posts to 70 characters
wide, as per the common standard for email and Usenet? Your lines a
Gabriel, could I please ask you to configure your news-reader software or
editor to limit the length of each line of your posts to 70 characters
wide, as per the common standard for email and Usenet? Your lines are
significantly longer than that, including one single line which is 325
character
tins are searched in globals. From frameobject.c:
> /* If we share the globals, we share the builtins. Save a
> lookup and a call. */
That was exactly my problem. Thank you for the cogent explanation.
> If you want to execute some code with modified builtins, do not
> change __buil
En Sun, 07 Sep 2008 14:00:48 -0300, Patrick Maupin <[EMAIL PROTECTED]> escribió:
> __builtins__ in 2.5.2 doesn't seem to behave like I remember it did
> the last time I did some custom stuff with it, a very long time ago.
>
> This isn't surprising, because of ongoing
__builtins__ in 2.5.2 doesn't seem to behave like I remember it did
the last time I did some custom stuff with it, a very long time ago.
This isn't surprising, because of ongoing optimization, but it's hard
to google for '__builtins__' so I didn't really find an
LHB <[EMAIL PROTECTED]> writes:
> Marc 'BlackJack' Rintsch a écrit :
> > `__builtins__` is an implementation detail, and `__builtin__` is a name
> > of a module you can import. You should not use `__builtins__` but import
> > `__builtin__` and inspect that in
ave seen the differences between them and the one in
>> dir(__builtins__).
>> Why are some modules in __builtins__ and others don't ? (UserDict for
>> example)
>
> `__builtins__` doesn't contain modules::
You are right... I don't know why I thought there wa
On Fri, 08 Feb 2008 00:25:14 -0800, loquehumaine wrote:
> I have seen that if I type help() at a prompt, and then 'modules',
> I'll be given a list of all modules available, thanks to this group..
> But I have seen the differences between them and the one in
> dir(__
s group..
But I have seen the differences between them and the one in
dir(__builtins__).
Why are some modules in __builtins__ and others don't ? (UserDict for
example)
Why dir(__builtins__) gives me "math" but not help(__builtins__) ?
What are the differences between __builtins__ an
On Dec 22, 1:59 pm, James Stroud <[EMAIL PROTECTED]> wrote:
> Dustan wrote:
> > On Dec 21, 8:11 pm, James Stroud <[EMAIL PROTECTED]> wrote:
> >> I swear there is another thread going on here of which I am not aware.
>
> > You just keep on telling yourself that.
>
> Is there a cricket here?
No, but
Dustan wrote:
> On Dec 21, 8:11 pm, James Stroud <[EMAIL PROTECTED]> wrote:
>> I swear there is another thread going on here of which I am not aware.
>
> You just keep on telling yourself that.
Is there a cricket here?
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Lo
On Dec 21, 8:11 pm, James Stroud <[EMAIL PROTECTED]> wrote:
> I swear there is another thread going on here of which I am not aware.
You just keep on telling yourself that.
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
> James Stroud wrote:
>> Erik Max Francis wrote:
>>> randomly dropping letters in
>>> names is going to result in bad behavior, so be more careful about it.
Implying I've randomly dropped a letter? Where did I randomly drop a letter?
> From what I can tell, the message Eri
James Stroud wrote:
>>> Butwhat the heck? You mean if I drop an s I get predictable
>>> behavior and if I don't, I get unpredictable behavior?
>>
>> You don't get unpredictable behavior, you just get different behavior
>> you didn't expect, which is not the same thing. Python is a programm
Erik Max Francis wrote:
> James Stroud wrote:
>
>> Thank you for your help. I will import the __builtin__ module as you
>> have suggested--it is what I need.
>>
>> Butwhat the heck? You mean if I drop an s I get predictable
>> behavior and if I don't, I get unpredictable behavior?
>
> You d
James Stroud wrote:
> Thank you for your help. I will import the __builtin__ module as you
> have suggested--it is what I need.
>
> Butwhat the heck? You mean if I drop an s I get predictable behavior
> and if I don't, I get unpredictable behavior?
You don't get unpredictable behavior, you
"James Stroud" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Butwhat the heck? You mean if I drop an s I get predictable behavior
| and if I don't, I get unpredictable behavior?
In 3.0, the __builtin__ module will be renamed 'builtins'. The
Jean-Paul Calderone wrote:
> On Thu, 20 Dec 2007 14:29:35 -0800, James Stroud <[EMAIL PROTECTED]>
> wrote:
>> Hello all,
>>
>> Say I have the following module
>>
>> # amodule.py
>> print __builtins__
>> # end of module
>>
>>
On Thu, 20 Dec 2007 14:29:35 -0800, James Stroud <[EMAIL PROTECTED]> wrote:
>Hello all,
>
>Say I have the following module
>
># amodule.py
>print __builtins__
># end of module
>
>Then I have the following little helper script:
>
># helper.py
>import am
Hello all,
Say I have the following module
# amodule.py
print __builtins__
# end of module
Then I have the following little helper script:
# helper.py
import amodule
# end of helper script
Now, I do this at the command line:
python amodule.py
And I get the following output:
Which is good
Adam Hupp <[EMAIL PROTECTED]> wrote:
> I've noticed some unexpected behavior with __builtins__ during module
> import. It seems that during module import __builtins__ is a dict
> but at all other times it is a module.
>
> For example, if the file testmod.py has these
I've noticed some unexpected behavior with __builtins__ during module
import. It seems that during module import __builtins__ is a dict
but at all other times it is a module.
For example, if the file testmod.py has these contents:
print type(__builtins__)
print "has str attr
nd are fulfilled by a simple direct
module function as simple as:
def doLog(text,level,**kwattrs):
# in case write to file or whatever ...
and so I simply know really what will happen. Collecting all logs is
also so easy with Python, that it
On Sun, 25 Sep 2005, James Stroud wrote:
> I'm into *real* purity. I would rather begin every script:
>
> from python import list, str, dict, sys, os
>
> Oh wait. I only use dict in less than 50% of my scripts:
>
> from python import list, str, sys, os
>
> That's better.
What? How exactly is th
I'm into *real* purity. I would rather begin every script:
from python import list, str, dict, sys, os
Oh wait. I only use dict in less than 50% of my scripts:
from python import list, str, sys, os
That's better.
On Saturday 03 September 2005 02:09, tiissa wrote:
> I was just stating you
On 9/23/05, Peter Hansen <[EMAIL PROTECTED]> wrote:
> My point, which might not have been clear, is that users are *already*
> told that they shouldn't ever touch __anything__ without understanding
> what it is, which is more general advice than and therefore encompasses
>
Collin Winter wrote:
> The difference between __builtins__ and the other __*__ names is that
> while the others shouldn't be used without understanding their
> purpose, the consensus on __builtins__ seems to be that it shouldn't
> be used at all.
>
> ... at the v
nly shouldn't have found any docs telling you to use
> __builtins__ that way.
>
> http://www.google.ca/search?q=site%3Apython.org+__builtin__ is a pretty
> quick way of finding the above docs, and while doing the same search
> with __builtins__ admittedly finds lots of mailing
Collin Winter wrote:
> On 9/23/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>__builtins__ is a CPython implementation detail. why not just let it
>>be an implementation detail, and refrain from using it? it's not that
>>hard, really.
> Given, but I fail
On 9/23/05, Christopher Subich <[EMAIL PROTECTED]> wrote:
> How would this change, if made in a minimal way, impact the "provide
> alternate globals() and locals() to eval and exec" feature? Altering
> __builtins__ is a half-assed way of providing some sort of security, b
On 9/23/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
>
> > As it currently stands, the type of the global __builtins__ differs
> > depending on whether you're in the __main__ namespace (__builtins__ is
> > a module) or not (its a dict)
Collin Winter wrote:
> Hallo all,
> I'd like to propose that in Py3.0 (if not earlier), __builtins__ will
> be the same type regardless of which namespace you're in. Tim Peters
> has said [1] that the reason __builtins__ in __main__ is a module so
> that "the curious
Collin Winter wrote:
> As it currently stands, the type of the global __builtins__ differs
> depending on whether you're in the __main__ namespace (__builtins__ is
> a module) or not (its a dict). I was recently tripped up by this
> discrepancy, and googling the issue brings up h
On Fri, 23 Sep 2005, Collin Winter wrote:
> If possible, I'd like to see this go in before 3.0. The reference manual
> currently states [2] that __builtins__ can be either a dict or a module,
> so changing it to always be a module would still be in keeping with
> this. Howeve
Collin Winter wrote:
> If possible, I'd like to see this go in before 3.0.
+1
--
Michael Hoffman
--
http://mail.python.org/mailman/listinfo/python-list
Hallo all,
As it currently stands, the type of the global __builtins__ differs
depending on whether you're in the __main__ namespace (__builtins__ is
a module) or not (its a dict). I was recently tripped up by this
discrepancy, and googling the issue brings up half-a-dozen or so c.l.p
th
"Michael J. Fromberger"
<[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> In article <[EMAIL PROTECTED]>,
> Rick Wotnaz <[EMAIL PROTECTED]> wrote:
>
>> You're right that there is no necessity for such a change. I
>> was not actually talking about importing *any* module in every
>> case, bu
Sybren Stuvel wrote:
> A programming language should not be ambiguous. The choice
> between importing a module and calling a function should not
> depend on the availability of a (local) variable.
Yeah, this behavior would be as ambiguous as if we had a system-defined
search-path for modules, whe
In article <[EMAIL PROTECTED]>,
Rick Wotnaz <[EMAIL PROTECTED]> wrote:
> You're right that there is no necessity for such a change. I was
> not actually talking about importing *any* module in every case,
> but rather about importing, say, 'sys' when, for example, sys.argv
> appeared in the co
portionally) less and less.
I'm -0.9 on sys (really don't like the idea but it wouldn't be awful to
see it included in __builtins__, provided it's namespaced appropriately)
and -1 on os.
[1] Actually, it's in there three times, but they're all in the same
file -- I
:
>>
>> > What would people think about adding sys to __builtins__ so
>> > that "import sys" is no longer necessary? This is something I
>> > must add to every script I write that's not a one-liner since
>> > they have this idiom at the bottom:
>>
In article <[EMAIL PROTECTED]>,
Rick Wotnaz <[EMAIL PROTECTED]> wrote:
> Michael Hoffman <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > What would people think about adding sys to __builtins__ so that
> > "import sys" is no long
Rick Wotnaz enlightened us with:
> That is, a reference to xxx.func(), without a previous import of xxx
> *could* be resolvable automatically, at least for those modules that
> can be found in a standard location.
-1 on that one. If I want to use a module, I'll write an import
statement for it. Th
"Terry Reedy" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
>
> "Colin J. Williams" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Rick Wotnaz wrote:
>>> +1 here. As far as I'm concerned, both os and sys could be
>>> special- cased that way. That said, I would guess the
"Colin J. Williams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Rick Wotnaz wrote:
>> +1 here. As far as I'm concerned, both os and sys could be special-
>> cased that way. That said, I would guess the likelihood of that
>> happening is 0.
>>
> +1 for both.
Some people might pr
Rick Wotnaz wrote:
> Michael Hoffman <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
>
>>What would people think about adding sys to __builtins__ so that
>>"import sys" is no longer necessary? This is something I must
>>add to every sc
Paul Watson wrote:
>This sounds pretty interesting. How about a switch to invoke this
>handling for the one-liner crowd and those who wish to use it?
>
>
>
>Somehow, I never heard any C programmers suggest that the default
>processing not include the need for:
>
>#include
>
>
I think it
Michael Hoffman wrote:
> To the contrary, I agree with Larry Wall that laziness is one of the
> cardinal virtues of a programmer.
There's lazy and too lazy.
You don't want to be too lazy to even get out of bed to code in Python.
Of course, with Perl, that's entirely another mattress^Wmatter.
>
Steve Holden wrote:
> Rick Wotnaz wrote:
>
>> Michael Hoffman <[EMAIL PROTECTED]> wrote in
>> news:[EMAIL PROTECTED]:
>>
>>> What would people think about adding sys to __builtins__ so that
>>> "import sys" is no longer necessary? This
tiissa wrote:
> A developper should not be too lazy to add one small line in a complete
> script/module.
To the contrary, I agree with Larry Wall that laziness is one of the
cardinal virtues of a programmer. Although my personal desire to be lazy
is not at issue here--I always start new scripts
Michael Hoffman a écrit :
> MrJbQ7 wrote:
>
> > Besides, a better way is to use your ~/.pythonrc file for customizing
> > according to your needs.
> >
> > A simple:
> >
> > echo "import sys, os" >> ~./pythonrc
> >
> > will do the job.
>
> Until someone else tries to use your script or module.
A
MrJbQ7 wrote:
> Steve Holden wrote:
>
>>I wonder if it would be worth special-casing the AttributeError [snip]
>
> What is it that Tim Peters said? "Special cases aren't special
> enough..."
That suggestion is a little too much magic for me.
> Besides, a better way is to use your ~/.pythonrc fi
Steve Holden wrote:
> I wonder if it would be worth special-casing the AttributeError [snip]
What is it that Tim Peters said? "Special cases aren't special
enough..."
Besides, a better way is to use your ~/.pythonrc file for customizing
according to your needs.
A simple:
echo "import sys, os"
Rick Wotnaz wrote:
> Michael Hoffman <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
>
>>What would people think about adding sys to __builtins__ so that
>>"import sys" is no longer necessary? This is something I must
>>add to every sc
Michael Hoffman <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> What would people think about adding sys to __builtins__ so that
> "import sys" is no longer necessary? This is something I must
> add to every script I write that's not a one-liner since they
&
What would people think about adding sys to __builtins__ so that
"import sys" is no longer necessary? This is something I must add to
every script I write that's not a one-liner since they have this idiom
at the bottom:
if __name__ == "__main__":
sys.exit(main(sys
__builtins__ (plural form) is a CPython implementation detail.
if you want to access the __builtin__ module, import it as usual:
import __builtin__
f = __builtin__.open(...)
if you're interested in CPython implementation details, study the CPython
source code.
Ok, I agree. I w
Laszlo Zsolt Nagy wrote:
> Given this module "test.py":
>
> print type(__builtins__)
>
> I ran into a wreid thing.
>
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "cre
Given this module "test.py":
print type(__builtins__)
I ran into a wreid thing.
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>
80 matches
Mail list logo
