On Sun, Aug 21, 2011 at 6:38 AM, Johnny Venter wrote:
> Yes, I want to make my queries from a remote non-Windows computer. Here is
> the scenario:
>
> From my mac, I want to use python to access and read objects from a remote
> Windows computer joined to a Windows 2003 functional level domain.
I'm following the instructions given http://www.scipy.org/
Installing_SciPy/Mac_OS_X">here, but it isn't working.
Specifically, I'm getting:
Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/
Contents/MacOS/Python: can't open file 'setup.py': [Errno 2] No such
file or directory
Perhaps you'd be better off with something like RunDeck (Free,
Open-Source, Cross-Platform, CopyLeft) for this kind of problem.
On Sun, Aug 21, 2011 at 5:30 PM, Chris Angelico wrote:
> On Sun, Aug 21, 2011 at 6:38 AM, Johnny Venter wrote:
>> Yes, I want to make my queries from a remote non-Windo
On Sun, Aug 21, 2011 at 6:03 AM, jefflovejapan wrote:
> I'm following the instructions given http://www.scipy.org/
> Installing_SciPy/Mac_OS_X">here, but it isn't working.
> Specifically, I'm getting:
>
> Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/
> Contents/MacOS/Pytho
On 21-8-2011 1:51, Johnny Venter wrote:
> Thank you all for the replies. I would like to query various Windows' objects
> and
> resources from Mac and/or Linux such as Active Directory users, network
> shares, group
> members, etc... What module or methods can I use with python to accomplish
> t
On 8/18/2011 5:02 AM Makiavelik said...
Hi,
Here is a sample code that reproduces the issue :
Not really 'sample' enough to allow others to investigate...
ImportError: No module named gobject
ImportError: No module named dbus
ImportError: No module named dbus.mainloop.glib
Try to eliminate th
Hi Folks,
I was arguing with a guy who was sure that incrementing a variable i with "i +=
1" is faster than "i = i + 1". I couldn't tell if he was right or wrong so I
did a little benchmark with the very useful timeit module.
Here are the results on my little Linux Eeepc Netbook (using Python 3.
as the += notation seems to be a syntaxic sugar layer that has to be
converted to i = i + 1 anyway.
That has always been my understanding. The faster way is to append to
a list as concatenating usually, requires the original string,
accessing an intermediate block of memory, and the memory for th
Well I agree with you about string concatenation, but here I'm talking about
integers incrementation...
--
http://mail.python.org/mailman/listinfo/python-list
On 21-08-11 19:03, Laurent wrote:
Well I agree with you about string concatenation, but here I'm talking about
integers incrementation...
Seems the two forms are not 100% identical:
>>> import dis
>>> def f1(x):
... x=x+1
...
>>> def f2(x):
... x+=1
...
>>>
>>> dis.dis(f1)
2 0 L
On Aug 20, 1:40 pm, Steven D'Aprano wrote:
> Pardon me for breaking threading, but I don't have Max's original post.
Not sure why; I also can't see it! I'll copy it at the end just in
case.
> On Sat, Aug 20, 2011 at 7:20 PM, Max Moroz wrote:
> > Would it be a good idea to change Python definiti
> What the precise difference (semantics and speed) is between the
> BINARY_ADD and INPLACE_ADD opcodes, I dunno. Look in the Python source
> code or maybe someone knows it from memory :-)
>
> Irmen
>
from Python/ceval.c:
1316case BINARY_ADD:
1317w = POP();
1318
Thanks for these explanations. So 2% speed difference just between "B..." and
"I..." entries in a huge alphabetically-ordered switch case? Wow. Maybe there
is some material for speed enhancement here...
--
http://mail.python.org/mailman/listinfo/python-list
On 21/08/11 19:14:19, Irmen de Jong wrote:
What the precise difference (semantics and speed) is between the
BINARY_ADD and INPLACE_ADD opcodes, I dunno. Look in the Python source
code or maybe someone knows it from memory :-)
There is a clear difference in semantics: BINARY_ADD always produces
Well 2% more time after 1 million iterations so you're right I won't consider
it.
--
http://mail.python.org/mailman/listinfo/python-list
Am 21.08.2011 19:27, schrieb Andreas Löscher:
> As for using Integers, the first case (line 1319 and 1535) are true and
> there is no difference in Code. However, Python uses a huge switch-case
> construct to execute it's opcodes and INPLACE_ADD cames after
> BINARY_ADD, hence the difference in spe
Steven D'Aprano writes:
>> But there's no way to know what that minimum is. Python libraries throw
>> all sorts of exceptions that their documentation doesn't mention.
>
> Yes, you're absolutely correct. But it's also irrelevant. Most of those
> exceptions should not be caught, even if you know w
In article ,
Christian Heimes wrote:
> Am 21.08.2011 19:27, schrieb Andreas Löscher:
> > As for using Integers, the first case (line 1319 and 1535) are true and
> > there is no difference in Code. However, Python uses a huge switch-case
> > construct to execute it's opcodes and INPLACE_ADD cames
On Sun, Aug 21, 2011 at 7:26 PM, Paul Rubin wrote:
> I'm not sure what to do instead. The exceptions I'm currently dealing
> with happen when certain network operations go wrong (e.g. network or
> remote host is down, connection fails, etc.) The remedy in each case is
> to catch the exception, l
Paul Rubin wrote:
Steven D'Aprano writes:
But there's no way to know what that minimum is. Python libraries throw
all sorts of exceptions that their documentation doesn't mention.
Yes, you're absolutely correct. But it's also irrelevant. Most of those
exceptions should not be caught, even if
On 8/21/2011 1:27 PM, Andreas Löscher wrote:
What the precise difference (semantics and speed) is between the
BINARY_ADD and INPLACE_ADD opcodes, I dunno. Look in the Python source
code or maybe someone knows it from memory :-)
Irmen
from Python/ceval.c:
1316case BINARY_ADD:
1317
On 8/21/2011 2:26 PM, Paul Rubin wrote:
Steven D'Aprano writes:
But there's no way to know what that minimum is. Python libraries throw
all sorts of exceptions that their documentation doesn't mention.
Yes, you're absolutely correct. But it's also irrelevant. Most of those
exceptions should
Actually 6% between float themselves is just as not-understandable.
--
http://mail.python.org/mailman/listinfo/python-list
> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with
> floats (0.0 and 1.0), 6%
For floats it is understandable. But for integers, seriously, 4% is a lot. I
would never have thought an interpreter would have differences like this in
syntax for something as fundamental as add
I did the test several times with floats on my machine and the difference is
not as big as for integers:
==> "i = i + 1.0" is 0.732% faster than "i += 1.0".
It seems normal as the float addition is supposed to be slower than integer
addition, thus the syntaxic difference is comparatively less
On Sun, 21 Aug 2011 09:52:23 -0700, Laurent wrote:
> I did many tests and "i = i + 1" always seems to be around 2% faster
> than "i += 1". This is no surprise as the += notation seems to be a
> syntaxic sugar layer that has to be converted to i = i + 1 anyway. Am I
> wrong in my interpretation?
In article <7xty9ahb84@ruckus.brouhaha.com>,
Paul Rubin wrote:
> It's a retail application that would cause some business disruption and
> a pissed off customer if the program went down. Also it's in an
> embedded box on a customer site. It's not in Antarctica or anything
> like that, but
On Sun, Aug 21, 2011 at 10:27 AM, Max wrote:
> On Aug 20, 1:40 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Sat, Aug 20, 2011 at 7:20 PM, Max Moroz wrote:
>> > Would it be a good idea to change Python definition so that a[10, -1, -1]
>>
>> I presume you mean slice notation a
Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
> In article ,
> Christian Heimes wrote:
>
> > Am 21.08.2011 19:27, schrieb Andreas Lscher:
> > > As for using Integers, the first case (line 1319 and 1535) are true and
> > > there is no difference in Code. However, Python uses a huge s
Am Sonntag, den 21.08.2011, 12:53 -0700 schrieb Laurent:
> > With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with
> > floats (0.0 and 1.0), 6%
>
> For floats it is understandable. But for integers, seriously, 4% is a lot. I
> would never have thought an interpreter would have di
2011/8/22 Andreas Löscher :
> How would such an jump table work to behave the same liek a
> switch-case-statement?
If your switch statement uses a simple integer enum with sequential
values, then it can be done quite easily. Take this as an example:
switch (argc)
{
cas
On 8/21/2011 7:17 PM, Andreas Löscher wrote:
Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
In article,
Christian Heimes wrote:
Am 21.08.2011 19:27, schrieb Andreas Lscher:
As for using Integers, the first case (line 1319 and 1535) are true and
there is no difference in Code. H
2011/8/22 Andreas Löscher :
> But every improvement on your algorithm will easily result in a
> significant shorter execution time than replaceing a+=1 with a=a+1 will
> ever do. :-)
>
Agreed. If Python needed a faster alternative to "a=a+1", then I would
recommend an "a.inc()" call or something;
I made Python my language of choice because of its readability and simpleness,
and not because of its speed. But it's always good to know what is the fastest
sometimes when you don't want to write a module in C. So I was just wondering
if there was a difference. There is, of a few percent. Anywa
Am Sonntag, den 21.08.2011, 19:38 -0400 schrieb Terry Reedy:
> On 8/21/2011 7:17 PM, Andreas Löscher wrote:
> > Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
> >> In article,
> >> Christian Heimes wrote:
> >>
> >>> Am 21.08.2011 19:27, schrieb Andreas Lscher:
> As for using Int
Paul Rubin wrote:
> Steven D'Aprano writes:
>>> But there's no way to know what that minimum is. Python libraries throw
>>> all sorts of exceptions that their documentation doesn't mention.
>>
>> Yes, you're absolutely correct. But it's also irrelevant. Most of those
>> exceptions should not be
Chris Angelico wrote:
> A new and surprising mode of network failure would be indicated by a
> new subclass of IOError or EnvironmentError.
/s/would/should/
I don't see why you expect this, when *existing* network-related failures
aren't:
>>> import socket
>>> issubclass(socket.error, Environ
On Mon, Aug 22, 2011 at 1:30 AM, Steven D'Aprano
wrote:
> /s/would/should/
>
> I don't see why you expect this, when *existing* network-related failures
> aren't
Ehh, granted. Definitely a case of "should". But certainly, there
won't be an infinite number of new exceptions invented; most of the
r
On 8/21/2011 5:07 PM, Nobody wrote:
If the value on the left has an __iadd__ method, that will be called;
Correct
the value will be updated in-place,
Not necessarily correct. The target is rebound to the return from the
__iadd__ method. Augmented *assignment* is always assignment. This tr
Laurent wrote:
>
>> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with
>> floats (0.0 and 1.0), 6%
>
> For floats it is understandable. But for integers, seriously, 4% is a lot.
> I would never have thought an interpreter would have differences like this
> in syntax for someth
Chris Angelico wrote:
> 2011/8/22 Andreas Löscher :
>> But every improvement on your algorithm will easily result in a
>> significant shorter execution time than replaceing a+=1 with a=a+1 will
>> ever do. :-)
>>
>
> Agreed. If Python needed a faster alternative to "a=a+1", then I would
> recomme
On Aug 21, 10:39 pm, Benjamin Kaplan wrote:
> On Sun, Aug 21, 2011 at 6:03 AM, jefflovejapan
> wrote:
> > I'm following the instructions given http://www.scipy.org/
> > Installing_SciPy/Mac_OS_X">here, but it isn't working.
> > Specifically, I'm getting:
>
> > Library/Frameworks/Python.framework
Am 22.08.2011 01:25, schrieb Andreas Löscher:
> It's not as bad as you think. The addition of two integers is a cheap
> task (in terms of computation power). If you have two way's to to it,
> every little think (jumps in the code etc. ) will have a larger impact
> on the execution time than on an e
John Doe wrote:
>
>Tim Roberts wrote:
>
>> That exact code works perfectly for me. The function returns as
>> soon as I press the escape key. You are running this from a
>> console process, and not a GUI process, right?
>
>No. I am running this from within Windows, all sorts of Windows.
>
>S
On 8/21/11 12:53 PM, Laurent wrote:
>
>> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with
>> floats (0.0 and 1.0), 6%
>
> For floats it is understandable. But for integers, seriously, 4% is a lot. I
> would never have thought an interpreter would have differences like this
On 8/21/2011 7:41 PM, Chris Angelico wrote:
Agreed. If Python needed a faster alternative to "a=a+1", then I would
recommend an "a.inc()" call or something
But looking up the method name, creating a bound method wrapper, and
making the call would probably be slower than the syntax;-).
--
Te
In article <4e51a205$0$29974$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html
I *love* being the Chaos Monkey!
A few jobs ago, I had already turned in my resignation and was a
short-timer, counting down t
On 8/21/2011 7:49 PM, Laurent Payot wrote:
I made Python my language of choice because of its readability and
simpleness, and not because of its speed. But it's always good to
know what is the fastest sometimes when you don't want to write a
module in C. So I was just wondering if there was a dif
On Mon, 22 Aug 2011 10:41 am Chris Angelico wrote:
> On Mon, Aug 22, 2011 at 1:30 AM, Steven D'Aprano
> wrote:
>> /s/would/should/
>>
>> I don't see why you expect this, when *existing* network-related failures
>> aren't
>
> Ehh, granted. Definitely a case of "should". But certainly, there
> won
On Mon, 22 Aug 2011 12:08 pm Stephen Hansen wrote:
> Picking "i += 1" over "i = i + 1" based on one being 4% slower is sorta
> kinda crazy. The difference in speed is probably related to churn and
> cache as much as anything else (its not as consistent on my machine, for
> example): or the ceval l
On Aug 21, 10:27 am, Andreas Löscher wrote:
>
> from Python/ceval.c:
>
> 1316 case BINARY_ADD:
> 1317 w = POP();
> 1318 v = TOP();
> 1319 if (PyInt_CheckExact(v) && PyInt_CheckExact(w)) {
> 1320 /* INLINE: int + int */
> 13
On 8/21/11 9:14 PM, Steven D'Aprano wrote:
>> That said: my advice is always to avoid += like a plague. It is magic
>> and impossible to predict without intimate knowledge of exactly what's
>> on the left-side.
>>
>>i += 1
>>n += x
>>
>> Those two things look very similar, but they may do -
On 8/21/11 9:37 PM, Stephen Hansen wrote:
> But, += is Python itself adding an unpredictable behavior into the core
> language, with its own base types behaving
... very differently to fundamental, basic appearing operators.
Editing fail on my part.
Similarly:
> But for Python, all by itself, w
I have a class like this:
class MySeq():
def __init__(self, *seq, c=12):
self.__c = c
self.__pc = sorted(set([i % __c for i in seq]))
self.order = ([[self.__pc.index(i % __c), i // __c] for i in seq])
#other calculated attributes
@property
def pitches(s
On Mon, 22 Aug 2011 03:04 pm John O'Hagan wrote:
> The "pitches" attribute represents the instances and as such I found
> myself adding a lot of methods like:
>
> def __getitem__(self, index):
> return self.pitches[index]
>
> def __len__(self):
> return len(self.pitches)
Looks like a c
On 2011-08-21, Andreas L?scher wrote:
> Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
>> In article ,
>> Christian Heimes wrote:
>> > I don't think that's the reason. Modern compiles turn a switch statement
>> > into a jump or branch table rather than a linear search like chained
>>
In what order are the addresses returned by socket.gethostbyname_ex()?
We know that gethostbyname() is indeterministic but hope that
gethostbyname_ex() has a specified order.
Best regards,
Tomas
--
http://mail.python.org/mailman/listinfo/python-list
57 matches
Mail list logo
