Re: Where is win32service

[med . arriouach]

Le dimanche 2 janvier 2011 18:58:53 UTC, Alex Willmer a écrit :
> On Sunday, January 2, 2011 6:40:45 PM UTC, catalinf...@gmail.com wrote:
> > I install Python 2.7 on Windows XP.
> > I try use :
> > 
> > import win32service
> > import win32serviceutil
> > 
> > But I got that error :
> > 
> > ImportError: No module named win32service
> > Where is this module ?
> 
> It's part of the pywin32 (aka win32all) package
> 
> http://sourceforge.net/projects/pywin32/
> 
> The latest download for your Python version is
> 
> http://sourceforge.net/projects/pywin32/files/pywin32/Build%20214/pywin32-214.win32-py2.7.exe/download
> 
> Regards, Alex

that help me thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: time.monotonic() roll over

[Akira Li]

Dave Angel  writes:

...many words about sleep()...
> Since the OS has no way of knowing whether the thing being waited for
> is a thread, another process, a human being, a network operation, or
> the end of the world, the interpretation of sleep needs to be the most
> conservative one.  There are many ways of suspending a process, and
> some of them will also suspend the external event.  Since the OS
> cannot know which case is significant, it has to return control to the
> caller at the soonest of the many possible interpretations.

That is why there is API (e.g., clock_nanosleep()) that allows us to
choose whether we need a relative delay (e.g., kill a subprocess if it
hasn't finished in 10 seconds) or an absolute deadline (e.g., these
lights should be on 9pm-6am local time).

*Both* use cases are valid.


--
Akira

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The binding operator, and what gets bound to what (was: About Modifying Globals)

[Steven D'Aprano]

Ben Finney wrote:

> Steven D'Aprano  writes:
> 
>> LJ wrote:
>>
>> > def gt(l):
>> >a["1"] = a["1"] | set([l])
>>
>> The difference between this example and your second one:
>>
>> > def gt2(l):
>> >b=b+l
>>
>>
>> is that the second is a "binding operation" and the first is not.
> 
> I disagree; they're both binding operations (and they both use the
> binding operator ‘=’ to express this).

Define "operator" :-)

In Python terms, operators include + - * etc. They return a result, and are
implemented by a special __dunder__ method. (Sometimes by two dunder
methods, e.g. __add__ and method __radd__.)

By this definition, = is not an operator. And indeed, the Python docs don't
list = as an operator:

https://docs.python.org/2/reference/lexical_analysis.html#operators

but it is listed as a delimiter:

https://docs.python.org/2/reference/lexical_analysis.html#delimiters

That's why I was careful to use the term "binding operation" and
avoid "operator", although I admit that was pretty subtle :-)

As for the rest of your comments:

> The difference between the two is: what reference is being bound?

I don't think we disagree, we merely have a different emphasis. The rules
for assignments in Python are a bit complicated, and the official language
used is often different from what we say informally:

https://docs.python.org/2/reference/simple_stmts.html#assignment-statements

Of course you are right that other assignment statements bind a value to a
reference of some sort:

spam.method().attribute['key'].thingy[0] = eggs

but *not for the purpose of deciding what is a local variable*. That was the
point I was emphasising.

The docs referenced above say:

Assignment of an object to a single target is recursively 
defined as follows.

If the target is an identifier (name):

If the name does not occur in a global statement in the 
current code block: the name is bound to the object in 
the current local namespace.
Otherwise: the name is bound to the object in the current
global namespace.

which is a little less than clear, but basically it means that assignments
of the form:

name = something

force name to be a local variable unless it is explicitly declared global.

More information here:

https://docs.python.org/2/reference/simple_stmts.html#the-global-statement

Oh, I learned something new: strictly speaking, this is implementation-
dependent and not guaranteed to work in the future!

def func():
global math
import math




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The binding operator, and what gets bound to what (was: About Modifying Globals)

[Chris Angelico]

On Fri, Dec 5, 2014 at 8:53 PM, Steven D'Aprano
 wrote:
> Oh, I learned something new: strictly speaking, this is implementation-
> dependent and not guaranteed to work in the future!
>
> def func():
> global math
> import math

When would you actually *want* this, though? Given that 'import'
already caches, there's not much point caching globally, and the idea
that a function could cause a module-level import to happen is pretty
weird!

The only scheme I could concoct would be something like this:

def use_foo():
global useme
import foo as useme
# code to initialize foo for our use

def use_bar():
global useme
import bar as useme
# likewise

def do_stuff():
useme.blah(1,2,3,4)

So, for instance, if you need a JavaScript executor, you might support
several different runtimes, and allow one to be selected like this.
But this would be serious code smell.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: time.monotonic() roll over

[Steven D'Aprano]

Lele Gaifax wrote:

> Steven D'Aprano  writes:
> 
>> The most conservative approach is to assume that while you're suspended,
>> *everything else* is suspended too, so when you resume you still have to
>> sleep for the full N seconds.
> 
> That's an intriguing interpretation of what sleep() should do, but I
> fail to see *how* the function could even attempt to do that: should it
> keep its own notion of the elapsed time?

Provided that the operating system can provide a monotonic clock that only
ticks while the process calling it is running, that shouldn't be hard. The
only tricky part is if the monotonic clock rolls over.

I'm not sure how the OS would implement that, but most OSes supply a global
monotonic clock, so it's probably possible. I leave that as an exercise to
the reader :-)

Here's a discussion from the Factor programming language:

http://code-factor.blogspot.com.au/2009/11/monotonic-timers.html



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Do you like the current design of python.org?

[Steven D'Aprano]

Peter Otten wrote:

> Did you ever hit the "Socialize" button? Are you eager to see the latest
> tweets when you are reading a PEP? Do you run away screaming from a page
> where nothing moves without you hitting a button? Do you appreciate the
> choice between ten or so links to the documentation?

I dislike the new design of python.org.

The formatting of long text essays get completely mangled towards the bottom
of the page, e.g.:

https://www.python.org/download/releases/2.2/descrintro

Many links are broken. When you click on the broken link, it says that it
has been reported and will be fixed, but weeks later it remains broken,
e.g.: 

https://www.python.org/doc/essays/metaclasses/Eiffel.py


It requires Javascript or else basic functionality fails. With Javascript,
basic functionality fails too, but in a much more entertaining and exciting
way, as in "I'm trying to click a button on that menu, why does the screen
keep refreshing and hiding the menu before I can click?".

I'm not terribly impressed by the design or the colour scheme, it's way
too "web 2.0", i.e. simultaneously pretentious and dumbed down.

But most of all, I despise the menus that pop up covering what I am trying
to read the page just because I happened to move the mouse over a button. I
loathe the practice of stuffing content into menus instead of using links
to individual web pages. And I hold nothing but scorn for the fact that the
main page has a slideshow.

But none of that even gets close to the spitting fury I feel when I see
the "Socialise" links. With the possible exception of the link to
http://irc.freenode.net/ which at least has the vague excuse that there is
a #python channel, not that a visitor to the python.org website has any way
to learn this.

Oh, I've just discovered that when you click in the search box, a perfectly
serviceable search box, it automatically expands by about 20%, just
because. Urge to kill rising...

 
> You can probably guess my opinion -- konqueror just crashed on the PEP
> index and for some reason I'm more annoyed about the page than about the
> browser.
> 
> 
> PS: Is there a twitter.com something that I can block to trade black
> friday and cyber monkey sales for a box with a good old error message?

I love konquorer as a file manager, but I've come to the conclusion that
Firefox is the absolute worst web browser available, except for all the
rest. Firefox has a wonderful plugin, No Script, which lets you block
Javascript and other nonsense on a per-site basis.

I love me my No Script. Browsing the web is so painful without it.




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

How to display a database table on my widget using tkinter

[brice DORA]

Hi i created a widget that i connected my sql server database. my goal is to 
put and display data into my database from my widget. i can put data into my 
database table but my problem is how to display these data on my widget like a 
table...thanks you at all
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Do you like the current design of python.org?

[Fetchinson .]

>> Did you ever hit the "Socialize" button?

No, but it doesn't bother me.

>> Are you eager to see the latest
>> tweets when you are reading a PEP?

No, but it doesn't bother me either. You can easily block twitter
related things by a number of ways, firewalls, /etc/hosts, etc.

>> Do you run away screaming from a page
>> where nothing moves without you hitting a button? Do you appreciate the
>> choice between ten or so links to the documentation?

No, but it doesn't bother me at all.

> I dislike the new design of python.org.

I actually love it a lot! Big improvement over the previous site I think.

> The formatting of long text essays get completely mangled towards the
> bottom
> of the page, e.g.:
>
> https://www.python.org/download/releases/2.2/descrintro

It doesn't look mangled to me (firefox 22).

> Many links are broken. When you click on the broken link, it says that it
> has been reported and will be fixed, but weeks later it remains broken,
> e.g.:
>
> https://www.python.org/doc/essays/metaclasses/Eiffel.py

What makes you think that this page is ought to return actual content?

> It requires Javascript or else basic functionality fails. With Javascript,
> basic functionality fails too, but in a much more entertaining and exciting
> way, as in "I'm trying to click a button on that menu, why does the screen
> keep refreshing and hiding the menu before I can click?".

I never encountered screen refreshings that I did not trigger myself.

> I'm not terribly impressed by the design or the colour scheme, it's way
> too "web 2.0", i.e. simultaneously pretentious and dumbed down.

I think it looks great! We agree to disagree I guess; see more below.

> But most of all, I despise the menus that pop up covering what I am trying
> to read the page just because I happened to move the mouse over a button. I
> loathe the practice of stuffing content into menus instead of using links
> to individual web pages. And I hold nothing but scorn for the fact that the
> main page has a slideshow.

And what would you estimate, how many standard deviations are you away
from the average viewer of python.org in terms of these metrics (where
the metrics are like/dislike of menus, like/dislike of mouse moving,
like/dislike of unexpected browser behavior, like/dislike of links,
like/dislike of slide shows, etc.)?

> But none of that even gets close to the spitting fury I feel when I see
> the "Socialise" links. With the possible exception of the link to
> http://irc.freenode.net/ which at least has the vague excuse that there is
> a #python channel, not that a visitor to the python.org website has any way
> to learn this.

And what would you estimate, how many standard deviations are you away
from the average viewer of python.org in terms of these metrics (where
now the metrics are like/dislike of social links, social websites,
etc.)?

> Oh, I've just discovered that when you click in the search box, a perfectly
> serviceable search box, it automatically expands by about 20%, just
> because.

And that is a problem because?

> Urge to kill rising...

I didn't see the disclaimer "No living thing was harmed while typing
this email." below your message so I'm kinda worried!

Cheers,
Daniel


>> You can probably guess my opinion -- konqueror just crashed on the PEP
>> index and for some reason I'm more annoyed about the page than about the
>> browser.
>>
>>
>> PS: Is there a twitter.com something that I can block to trade black
>> friday and cyber monkey sales for a box with a good old error message?
>
> I love konquorer as a file manager, but I've come to the conclusion that
> Firefox is the absolute worst web browser available, except for all the
> rest. Firefox has a wonderful plugin, No Script, which lets you block
> Javascript and other nonsense on a per-site basis.
>
> I love me my No Script. Browsing the web is so painful without it.
>
>
>
>
> --
> Steven
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The binding operator, and what gets bound to what

[Ned Batchelder]

On 12/5/14 4:53 AM, Steven D'Aprano wrote:

Oh, I learned something new: strictly speaking, this is implementation-
dependent and not guaranteed to work in the future!

def func():
 global math
 import math


I don't think this is implementation-dependent.  The import statement is 
an assignment to a name (as are class, def, for, with-as and except-as). 
 Where that name is scoped is the same for all of them, and does not 
depend on the implementation.  The usual behavior of locals and globals 
happens for all of them:


>>> import math
>>> math

>>> def f():
...   print math
...   import math
...
>>> f()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in f
UnboundLocalError: local variable 'math' referenced before assignment


>>> a
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'a' is not defined
>>> def f():
...   global a
...   for a in range(10):
... pass
...
>>> f()
>>> a
9

This also means that you can do odd things like:

   for self.foo in range(10):

or:

   for my_list[17] in range(10):

(but please don't!)


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: The binding operator, and what gets bound to what (was: About Modifying Globals)

[Steven D'Aprano]

Chris Angelico wrote:

> On Fri, Dec 5, 2014 at 8:53 PM, Steven D'Aprano
>  wrote:
>> Oh, I learned something new: strictly speaking, this is implementation-
>> dependent and not guaranteed to work in the future!
>>
>> def func():
>> global math
>> import math
> 
> When would you actually *want* this, though? Given that 'import'
> already caches, there's not much point caching globally, and the idea
> that a function could cause a module-level import to happen is pretty
> weird!

That's one way of dealing with circular imports. That way the problematic
import is deferred until the function is called, which hopefully is after
both modules have finished initialising their global names. And by making
the imported name a global, you don't have to bother writing "import math"
in every single function. You just need to ensure your initialisation
function is called before doing any real work.

I'm not saying that this is an ideal solution, but there are no ideal
solutions to circular imports. 


> The only scheme I could concoct would be something like this:
> 
> def use_foo():
> global useme
> import foo as useme
> # code to initialize foo for our use
> 
> def use_bar():
> global useme
> import bar as useme
> # likewise
> 
> def do_stuff():
> useme.blah(1,2,3,4)

Oooh! That's nice too!


> So, for instance, if you need a JavaScript executor, you might support
> several different runtimes, and allow one to be selected like this.
> But this would be serious code smell.

No more than any other global variable. Just because something is unusual
doesn't make it harmful. If you have globals (constants, or variables), you
might put their initialisation code into a function:

def init():
global x, y, z
x = some_calculation(arg1)
y = another_calculation(arg2)
z = yet_a_third_calculation(arg3)


import is just a special case of a particular calculation.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The binding operator, and what gets bound to what

[Steven D'Aprano]

Ned Batchelder wrote:

> On 12/5/14 4:53 AM, Steven D'Aprano wrote:
>> Oh, I learned something new: strictly speaking, this is implementation-
>> dependent and not guaranteed to work in the future!
>>
>> def func():
>>  global math
>>  import math
> 
> I don't think this is implementation-dependent.

The docs say that it is:

https://docs.python.org/3/reference/simple_stmts.html#the-global-statement

Names listed in a global statement MUST NOT [emphasis added] be 
defined as formal parameters or in a for loop control target, 
class definition, function definition, or import statement.

CPython implementation detail: The current implementation does not
enforce the two restrictions, but programs should not abuse this
freedom, as future implementations may enforce them or silently 
change the meaning of the program.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The binding operator, and what gets bound to what (was: About Modifying Globals)

[Chris Angelico]

On Fri, Dec 5, 2014 at 11:26 PM, Steven D'Aprano
 wrote:
> Chris Angelico wrote:
>
>>> def func():
>>> global math
>>> import math
>>
>> When would you actually *want* this, though? Given that 'import'
>> already caches, there's not much point caching globally, and the idea
>> that a function could cause a module-level import to happen is pretty
>> weird!
>
> That's one way of dealing with circular imports. That way the problematic
> import is deferred until the function is called, which hopefully is after
> both modules have finished initialising their global names. And by making
> the imported name a global, you don't have to bother writing "import math"
> in every single function. You just need to ensure your initialisation
> function is called before doing any real work.

Ah. I've never liked circular imports at all, so I've never actually
looked into ways of dealing with them. So basically, func() is a sort
of "second phase initialization" routine, to be called before any of
the module's real work gets called.

> Oooh! That's nice too!
>
>
>> So, for instance, if you need a JavaScript executor, you might support
>> several different runtimes, and allow one to be selected like this.
>> But this would be serious code smell.
>
> No more than any other global variable. Just because something is unusual
> doesn't make it harmful. If you have globals (constants, or variables), you
> might put their initialisation code into a function:

That's why I said "code smell". Imagine the usage of a module like that:

import module
module.use_foo() # What happens if you omit this line?
module.do_stuff()

This is true of your circular imports example, too. Anything that
requires a two-step initialization runs the risk of someone either
forgetting, or having two imports in different modules and having them
out of sync. (With the code example I gave, whichever one is imported
second will "stick", because the use_* functions overwrite each
other.) So it's going to be a bit confusing to people using the
module. It might be better to have a deliberately-instantiated object:

import module
stuff_doer = module.use_foo()
stuff_doer.do_stuff()

It also might not, of course, which is the point of code smell - it
*is* sometimes correct - but I'd want to see some justifying comments
(or docstring) if anyone does this in production code.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The binding operator, and what gets bound to what

[Chris Angelico]

On Fri, Dec 5, 2014 at 11:34 PM, Steven D'Aprano
 wrote:
>> I don't think this is implementation-dependent.
>
> The docs say that it is:
>
> https://docs.python.org/3/reference/simple_stmts.html#the-global-statement
>
> Names listed in a global statement MUST NOT [emphasis added] be
> defined as formal parameters or in a for loop control target,
> class definition, function definition, or import statement.
>
> CPython implementation detail: The current implementation does not
> enforce the two restrictions, but programs should not abuse this
> freedom, as future implementations may enforce them or silently
> change the meaning of the program.

Interesting, I didn't know that either.

But the first restriction _is_ enforced:

rosuav@sikorsky:~$ python3
Python 3.5.0a0 (default:23ab1197df0b, Nov 20 2014, 12:57:44)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def x(y):
... global y
...
  File "", line 2
SyntaxError: name 'y' is parameter and global

Likewise in CPython 2.7:

rosuav@sikorsky:~$ python
Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def x(y):
... global y
...
  File "", line 1
SyntaxError: name 'y' is local and global

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The binding operator, and what gets bound to what

[Ned Batchelder]

On 12/5/14 7:34 AM, Steven D'Aprano wrote:

Ned Batchelder wrote:


On 12/5/14 4:53 AM, Steven D'Aprano wrote:

Oh, I learned something new: strictly speaking, this is implementation-
dependent and not guaranteed to work in the future!

def func():
  global math
  import math


I don't think this is implementation-dependent.


The docs say that it is:

https://docs.python.org/3/reference/simple_stmts.html#the-global-statement

 Names listed in a global statement MUST NOT [emphasis added] be
 defined as formal parameters or in a for loop control target,
 class definition, function definition, or import statement.

 CPython implementation detail: The current implementation does not
 enforce the two restrictions, but programs should not abuse this
 freedom, as future implementations may enforce them or silently
 change the meaning of the program.


Ah, good.  TIL! :)

--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: Do you like the current design of python.org?

[William Ray Wing]

> On Dec 5, 2014, at 5:43 AM, Steven D'Aprano 
>  wrote:
> 
> Peter Otten wrote:
> 
>> Did you ever hit the "Socialize" button? Are you eager to see the latest
>> tweets when you are reading a PEP? Do you run away screaming from a page
>> where nothing moves without you hitting a button? Do you appreciate the
>> choice between ten or so links to the documentation?
> 
> I dislike the new design of python.org.
> 
> The formatting of long text essays get completely mangled towards the bottom
> of the page, e.g.:
> 
> https://www.python.org/download/releases/2.2/descrintro

I’m not sure what you are referring to here.  That page looks fine all the way 
to the bottom of the footer on my system, looking at it with either Firefox or 
Safari.

-Bill

-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: 'tsshbatch' Server Automation Tool Version 1.204 Released

[Tim Daneliuk]

'tsshbatch' Version 1.204 is now released and available for download at:

 http://www.tundraware.com/Software/tsshbatch

This is a major update with many bug fixes and improvements.  Existing
users will want to update sooner rather than later.

The last public release was 1.177.
-

What Is 'tsshbatch'?


'tsshbatch' is a server automation tool to enable you to issue commands
to many servers without having to log into each one separately.  When
writing scripts, this overcomes the 'ssh' limitation of not being able to
specify the password on the command line.

'tsshbatch' also understands basic 'sudo' syntax and can be used
to access a server, 'sudo' a command, and then exit.

'tsshbatch' thus allows you to write complex, hands-off scripts that
issue commands to many servers without the tedium of manual login and
'sudo' promotion.  System administrators, especially, will find this
helpful when working in large server farms.

'tsshbatch' is written in Python and requires the 'paramiko library.
It has been tested on various Linux and FreeBSD variants.



WHATSNEW For 'tsshbatch' 1.204(Thu Dec  4 17:49:30 CST 2014)
--

[NEW FEATURES]

- Added the following builtin variables:

  __DATE__   # Date in MMDD format
  __DATETIME__   # Date and time in MMDDHHMMSS format
  __HOSTNAME__   # Full name of current host as passed to program
  __HOSTNUM__# Count of host being processed, starting at 1
  __HOSTSHORT__  # Leftmost component of hostname as passed to program
  __TIME__   # Time in HHMMSS format

- Added an "execution variable".  This runs a command of your
  choosing (on the local machine) and assigns the results to
  a user-defined variable.

- Added -E to redirect all stderr output to stdout instead,

- Added -T timeout option (default is 15 sec).

- Added -a to allow program to continue after file transfer error.

- Added -l logging option. Defaults to /dev/null.  This fixes the error
  that was previously being reported:

"No handlers could be found for logger "paramiko.transport"

- Added -q for "quieter" output.


[CHANGES]

- File transfers now properly preserve the file's permissions.

- Changed hostname separator from ':' to '-' when using the -G command.

- The  and  builtins have been replaced
  with the new builtins described above.

- Error messages now more consistent and clear.

- Test mode now expands variable references to their values for
  all variables except the builtins above (which are only
  evaluated at runtime).

- Documentation has been rewritten and improved considerably.


[BUG FIXES]

- Fixed bug that prevented the proper dereferencing of
  __HOSTNAME|SHORT__ (formerly ) in file transfer
  specifications.

- Fixed bug that prevented variable substitution in hostnames.

- Fixed bug that prevented '.define' variables from being substituted
  in file transfer specifications.

- Fixed bug that only recognized sudo invocations if they were the
  first statement on a command line.  All instances of the string
  "sudo " will now force sudo password prompting and processing.
  That string is ignored if it appears inside single- or double quotes.

- Fixed a bug that intermittently occurred during password-based auth
  sessions because ssh-agent and key searching were still being used.

- Fixed error reporting blowout when key-exchange auth fails.


Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/



--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/


--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

--
https://mail.python.org/mailman/listinfo/python-list

Re: time.monotonic() roll over

[Ian Kelly]

On Thu, Dec 4, 2014 at 3:44 PM, Marko Rauhamaa  wrote:
>
> Ian Kelly :
>
> > It's not clear to me whether those cases are relevant to the rollover
> > concern anyway. I wouldn't be shocked if the GetTickCount() function
> > simply stopped increasing while the system is suspended, since after
> > all it's not "ticking" during that time.
>
> So, what's the semantics of time.sleep(), select.select() et al wrt
> process or machine suspension?

Rather than continue to speculate, I just tested this. I ran the following
script in a Windows 7 VM and paused the VM for part of the duration of the
sleep call. I unpaused well before the sleep call would normally have ended.

>>> import time
>>> def test():
...   t1 = time.time()
...   m1 = time.monotonic()
...   time.sleep(60)
...   t2 = time.time()
...   m2 = time.monotonic()
...   return t2 - t1, m2 - m1
...
>>> test()
(84.92642459869386, 60.0023994)

As you can see, the sleep call and the monotonic time elapsed both appear
to exclude the period when the VM was paused.

Then I tried the same with a MacBook and putting the system to sleep
instead of pausing a VM:

>>> test()
(59.889225006103516, 60.00102640298428)

Reducing the sleep time to 10 seconds and suspending the process with
Ctrl-Z produces a similar result on the MacBook:
(10.000508069992065, 10.000266332994215)

But the story is different in Linux. Here's what I got with the same Ctrl-Z
test:
(16.000478506088257, 16.000478034024127)

I think the relative roundness of those numbers is just coincidence. I
tried a second time and got:
(12.613622903823853, 12.613622067990946)

So it seems that it can go either way depending on the OS and perhaps the
mechanism of suspension.
-- 
https://mail.python.org/mailman/listinfo/python-list

concat string and dict in print statement

[gaurangnshah]

Hi Guys, 

I am trying to combine string and dict in the print statement, however getting 
an error. Would someone let me know what will be correct way to do that.

stats={'lname': 'shah', 'fname': 'gaurang'}
a=test

print "%s %(fname)s %(lname)s" %(a,stats)

Following is the error I am getting 
Traceback (most recent call last):
  File "", line 1, in 
TypeError: format requires a mapping
-- 
https://mail.python.org/mailman/listinfo/python-list

Tabs for indentation & Spaces for alignment in Python 3?

[Aahan Krish]

I have two general questions regarding Python that I couldn't find any good
answers for. This is not the often-asked Tabs vs Spaces question, so kindly
read it in whole.

*Q1.* This is not to debate the decision, but I really wanted to know the
reason why PEP 8 chose to go with spaces instead of tabs. I read that tabs
were initially preferred over spaces (esp. Mr. Rossum)? What caused the
decision that spaces are better?

According to Core Python Programming (Book):

...because tabs vary in the number of spaces depending on your system, we
> recommend not using tabs if there is any hint of cross-platform development.
>

Isn't that a feature of tabs? (i.e. allowing the user to configure the size
of a tab stop in his editor, which has no affect whatsoever on the tab
character itself or how it displays in another user's editor.)

Is it the difficulty to adhere to the Maximum Line Length (79) when using
tabs? or is it simply because most of the Python programmers were using
spaces (or were adamant on using them) at the time of the decision-making
process?

*Q2.* PEP 8 also reads, "Python 3 disallows mixing the use of tabs and
spaces for indentation."

So, if I am using tabs for indentation and spaces for alignment, is it
still considered "mixing the use of tabs and spaces" in Python 3? (Please
see this example
.)

Thank you very much for your time!


Best
Aahan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: concat string and dict in print statement

[Peter Otten]

gaurangns...@gmail.com wrote:

> I am trying to combine string and dict in the print statement, however
> getting an error. Would someone let me know what will be correct way to do
> that.
> 
> stats={'lname': 'shah', 'fname': 'gaurang'}
> a=test
> 
> print "%s %(fname)s %(lname)s" %(a,stats)
> 
> Following is the error I am getting
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: format requires a mapping

Try the str.format() method:

>>> stats = {'lname': 'shah', 'fname': 'gaurang'}
>>> a = "test"
>>> print "{0} {1[fname]} {1[lname]}".format(a, stats)
test gaurang shah


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: concat string and dict in print statement

[Ian Kelly]

On Fri, Dec 5, 2014 at 10:31 AM,  wrote:
>
> Hi Guys,
>
> I am trying to combine string and dict in the print statement, however
getting an error. Would someone let me know what will be correct way to do
that.
>
> stats={'lname': 'shah', 'fname': 'gaurang'}
> a=test
>
> print "%s %(fname)s %(lname)s" %(a,stats)
>
> Following is the error I am getting
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: format requires a mapping

You need to use either a tuple or a mapping, not a mapping inside a tuple.
Or switch to using str.format, which allows more advanced attribute/item
look-ups like this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Ian Kelly]

On Fri, Dec 5, 2014 at 10:40 AM, Aahan Krish  wrote:
> Q2. PEP 8 also reads, "Python 3 disallows mixing the use of tabs and
spaces for indentation."
>
> So, if I am using tabs for indentation and spaces for alignment, is it
still considered "mixing the use of tabs and spaces" in Python 3? (Please
see this example.)

No, you can mix tabs and spaces as long as you do so consistently within a
block, i.e. if one line is indented with  then the next
line in the same block had better start with that same exact sequence. The
difference is that Python 2 when trying to compare indentation will treat a
tab as equal to 8 spaces (or was it 4?) which can lead to situations where
the relative indentation of two lines looks one way to the programmer but
is lexed a different way by the interpreter. Python 3 resists the
temptation to guess in this situation and simply raises an error.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Aahan Krish]

Hello Ian,

So, wrt Q2, what you are saying is, the following would cause issues in
Python 3?

int f(int x,
..int y) {
--->return g(x,
--->.y);
}

Where:

---> for tabs (used for indentation)
 for spaces (used for alignment)


Best
Aahan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: time.monotonic() roll over

[Marko Rauhamaa]

Ian Kelly :

> On Thu, Dec 4, 2014 at 3:44 PM, Marko Rauhamaa  wrote:
>> So, what's the semantics of time.sleep(), select.select() et al wrt
>> process or machine suspension?
>
> Rather than continue to speculate, I just tested this.

The test, of course, can only have one useful result...

> So it seems that it can go either way depending on the OS and perhaps the
> mechanism of suspension.

... and you got it.

If the semantics had coincided, the question would remain unresolved; it
could just have been a coincidence.

However, the variance in the results means the semantics are
unspecified.

I think programmer's would need facilities to determine and control the
suspension behavior.

All things being equal, *early* wakeup is preferable to late wakeup
because the application can then check for a spurious wakeup and go back
to sleep. The reverse situation would be painful to deal with.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[sohcahtoa82]

On Friday, December 5, 2014 9:47:10 AM UTC-8, Aahan Krish wrote:
> I have two general questions regarding Python that I couldn't find any good 
> answers for. This is not the often-asked Tabs vs Spaces question, so kindly 
> read it in whole.
> 
> Q1. This is not to debate the decision, but I really wanted to know the 
> reason why PEP 8 chose to go with spaces instead of tabs. I read that tabs 
> were initially preferred over spaces (esp. Mr. Rossum)? What caused the 
> decision that spaces are better?
> 
> According to Core Python Programming (Book):
> 
> ...because tabs vary in the number of spaces depending on your system, we 
> recommend not using tabs if there is any hint of cross-platform development.
> 
> Isn't that a feature of tabs? (i.e. allowing the user to configure the size 
> of a tab stop in his editor, which has no affect whatsoever on the tab 
> character itself or how it displays in another user's editor.)
> 
> Is it the difficulty to adhere to the Maximum Line Length (79) when using 
> tabs? or is it simply because most of the Python programmers were using 
> spaces (or were adamant on using them) at the time of the decision-making 
> process?
> 

The problem comes when people use tabs for aligning code when a single 
statement spans multiple lines.  For example let's say your tabs are 4 spaces, 
and you have this block of code:

if someCondition:
someVariable = someFunction(parameter1, parameter2, parameter3,
parameter4, parameter5)

If you align the third line (the one with parameter4 and parameter5) with more 
than 1 tab, then someone with their tab size set to something other than 4 
spaces won't see the aligned code.

Of course, the correct solution *IF YOU ARE USING TABS FOR INDENTATION* is to 
indent that third line with a SINGLE tab, then use a bunch of spaces to align 
the code.  This way, even if someone else has their tab size set to 8 spaces, 
they still see aligned code.

So using spaces instead of tabs is a way of preventing the code aligning issue. 
 The downside, of course, is that it forces everyone to use the same number of 
spaces for indentation, which results in a different argument of how many 
spaces should be used, which of course is a different discussion entirely, 
another dead horse to beat.

It of course is worth mentioning at this point that any editor that is worth 
using can be configured to insert spaces when you press the TAB key, and the 
number of spaces being configurable.  So even if you're using spaces, you can 
still use the TAB key.  Even the 'nano' editor for *nix can do this.  I 
frequently see a lot of beginner programmers using the argument that hitting 
the space bar 4-8 times (Depending on agreed tab size) is wasteful as an 
argument for tabs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Chris Angelico]

On Sat, Dec 6, 2014 at 4:40 AM, Aahan Krish  wrote:
> I have two general questions regarding Python that I couldn't find any good
> answers for. This is not the often-asked Tabs vs Spaces question, so kindly
> read it in whole.
>
> Q1. This is not to debate the decision, but I really wanted to know the
> reason why PEP 8 chose to go with spaces instead of tabs. I read that tabs
> were initially preferred over spaces (esp. Mr. Rossum)? What caused the
> decision that spaces are better?

The decisions in PEP 8 govern the Python standard library *only*. For
any other project, you're free to say "We'll follow PEP 8 but using
tabs for indentation" or "We'll follow PEP 8 but use three spaces for
indentation". (Yes, you're free to be utterly insane.)

Personally, I prefer and recommend tabs for indentation. That way, if
there's any argument about how wide indents ought to be, the
belligerents can simply reconfigure them. But ultimately, there's very
little difference between "use tabs" and "use four spaces" and "use
eight spaces" and "use two spaces" (though I'd put them in that
order); the most important thing is to choose *something* and stick
with it.

Oh, and get yourself an editor that tells you when you've mucked them
up. SciTE does; a little blue line fills the indent if it's wrong
compared to the previous one. I work with a lot of students who use
Sublime, have it set to show tabs as four spaces wide, and then have
no idea why their code isn't working. Hmm. I guess "alias
python='python -tt'" would be a good thing, here.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

jitpy - Library to embed PyPy into CPython

[Mark Lawrence]

For those who haven't heard thought this might be of interest 
https://github.com/fijal/jitpy


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Cameron Simpson]

On 05Dec2014 17:40, Aahan Krish  wrote:

*Q1.* This is not to debate the decision, but I really wanted to know the
reason why PEP 8 chose to go with spaces instead of tabs. I read that tabs
were initially preferred over spaces (esp. Mr. Rossum)? What caused the
decision that spaces are better?


Essentially because the space is always the same.


According to Core Python Programming (Book):
...because tabs vary in the number of spaces depending on your system, we

recommend not using tabs if there is any hint of cross-platform development.


Isn't that a feature of tabs? (i.e. allowing the user to configure the size
of a tab stop in his editor, which has no affect whatsoever on the tab
character itself or how it displays in another user's editor.)


Yes, but in practice it causes varying degrees of pain.

Ideally, the various pieces of code have differing indents and that would be 
specified entirely with tabs. In practice, (1) people mix them and (2) people 
make other formatting decisions based on the rendering width of tabs in 
whatever editor they're using at the time, particularly with multiline strings 
such as docstrings.


There are two common approaches to TABs: the purists who uses TABs entirely so 
that other users can align the code as they see fit, and the pragmatists who 
configure their editors to accept the TAB _keystroke_ and have it insert spaces 
according to their tab convention.


I'm in the latter category; I have spent too much time reading files indented 
with TABs by people using a different tabwidth to my own, and thus looking 
aweful on my screen. The original author didn't choose to make it awful, but 
their tabs rendered in my tab scheme look awful. And doubtless vice versa. The 
root cause of this is that when we, as humans, indent with tabs, we do it to 
achieve a certain visual effect; as though a certain number of spaces were in 
play.


So my editor is configured to accept the tab key for convenience of typing, but 
to insert spaces.


Cheers,
Cameron Simpson 

In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt.- Blair P. Houghton
--
https://mail.python.org/mailman/listinfo/python-list

Re: Not Able to Log in on XNAT server through PyXNAT

[suyash . d . b]

On Friday, December 5, 2014 2:41:54 AM UTC-5, dieter wrote:
> suyash@gmail.com writes:
> 
> > Hello All,
> >
> > I have installed pyxnat on my mac. With pyxnat i am trying to access XNAT 
> > server in our university. As mentioned on the tutorial i tried both ways, 
> > neither is working. Following error is displayed:
> >
>  central=Interface(server='http://hd-hni-xnat.cac.cornell.edu:8443/xnat')
> > User: sdb99
> > Password: 
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File "/Library/Python/2.7/site-packages/pyxnat/core/interfaces.py", line 
> > 228, in __init__
> > self._get_entry_point()
> >   File "/Library/Python/2.7/site-packages/pyxnat/core/interfaces.py", line 
> > 268, in _get_entry_point
> > raise e
> > socket.error: [Errno 54] Connection reset by peer
> 
> "Connection reset by peer" means that the remote server unexpectedly
> closed the connection. This may be a problem at the remote site or
> an intermediate firewall or the remote site may be unhappy with the 
> request is hase been presented - and instead of an error response
> simply closed the connection (bad behavior).
> 
> I would try to contact the administrators of your "XNAT" server
> whether they can provide some help:
> 
>   *  did your request reached the server (or was it blocked
>  on its way to the server)?
> 
>   *  if yes, why was the connection closed (without response).

Thanks a ton for the help. i will check with our server administrator.
 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Ned Batchelder]

On 12/5/14 12:40 PM, Aahan Krish wrote:

I have two general questions regarding Python that I couldn't find any
good answers for. This is not the often-asked Tabs vs Spaces question,
so kindly read it in whole.

*Q1.* This is not to debate the decision, but I really wanted to know
the reason why PEP 8 chose to go with spaces instead of tabs. I read
that tabs were initially preferred over spaces (esp. Mr. Rossum)? What
caused the decision that spaces are better?

According to Core Python Programming (Book):

...because tabs vary in the number of spaces depending on your
system, we recommend not using tabs if there is any hint of
cross-platform development.


Isn't that a feature of tabs? (i.e. allowing the user to configure the
size of a tab stop in his editor, which has no affect whatsoever on the
tab character itself or how it displays in another user's editor.)


But you can't configure the width of tabs in all the places you look at 
code (printing, online repos, diff viewers, etc, etc).


Others have mentioned the awkward nature of over-indented continuation 
lines.


My feeling is that if you are working with others who feel strongly 
enough about differing indent widths that they need to use tabs so they 
can each have their own way, then you probably have bigger collaboration 
issues.


Use four spaces, and be done with it.  Agree with your team members on 
how your code will look, then innovate on the important things.


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Ned Batchelder]

On 12/5/14 1:49 PM, Aahan Krish wrote:

Hello Ian,

So, wrt Q2, what you are saying is, the following would cause issues in
Python 3?

 int f(int x,
 ..int y) {
 --->return g(x,
 --->.y);
 }

Where:

---> for tabs (used for indentation)
 for spaces (used for alignment)


(Aside from the fact that that isn't Python syntax *at all*), Python 3 
would be OK with that indentation. It wouldn't be OK with mixed tabs and 
spaces where the meaning depends on the indent width of a tab, but here 
it does not.


I sincerely hope no one is seriously considering trying to maintain code 
using a mix of tabs and spaces like that.  That's a nightmare.


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, C++ interaction

[wesleiramos2]

Em quinta-feira, 4 de dezembro de 2014 07h51min14s UTC-2, Sturla Molden  
escreveu:
> Dan Stromberg  wrote:
> 
> > 1) writing in Cython+CPython (as opposed to wrapping C++ with Cython)
> 
> That is an option, but it locks the code to Cython and CPython forever. C
> and C++ are at least semi-portable.
> 
> > 2) using numba+CPython (It's a pretty fast decorator - I've heard it's
> > faster than Cython)
> 
> Numba is usually not "faster than Cython" (Cython can be as fast as C), but
> it can be pretty fast. Sometimes it is comparable to -O2 in C for the
> subset of Python it supports, but usually a bit slower. But if you can use
> it, it is easier to use than Cython. There are no extra compilation steps,
> etc. Just add a couple of decorators to the Python code and it takes off
> like a rocket. For anyone who are familiar with PyPy and Psyco, Numba is
> far better than those. It is a Python JIT compiler that often can perform
> better than the Java VM. Numba will also JIT-compile Python code that uses
> ctypes or cffi to call external libraries down to almost zero overhead.
> 
> You forgot to mention using Fortran and f2py. Many scientists and engineers
> prefer Fortran to C and C++ because it is easier to use. And Fortran 90 and
> later standards are not anything like the loathed Fortran 66 and 77
> languages. Fortran is a high-level language particularly suited for
> numerical computing, C is a semi-portable high-level assembler. 
> 
> Sturla

m'giu vous êtès nom souris, pseudo nom cha'rs out oiu êtès, i'ret egop c'hâse
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Steven D'Aprano]

Cameron Simpson wrote:

> I have spent too much time reading files indented
> with TABs by people using a different tabwidth to my own, and thus looking
> aweful on my screen. The original author didn't choose to make it awful,
> but their tabs rendered in my tab scheme look awful. And doubtless vice
> versa. The root cause of this is that when we, as humans, indent with
> tabs, we do it to achieve a certain visual effect; as though a certain
> number of spaces were in play.

How is this different from people who achieve a certain visual effect by
indenting with actual spaces?

I've seen people indent with 8 spaces. I've seen people indent with 2
spaces. I've even seen people indent with a single space per level. I
haven't seen anyone indent with 17 spaces, but I suppose it's only a matter
of time...

I don't see how reading code indented with tabs configured for 8/4/2/1
spaces is *worse* than reading tab indented with 8/4/2/1 spaces.




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Ian Kelly]

On Fri, Dec 5, 2014 at 11:49 AM, Aahan Krish  wrote:
>
> Hello Ian,
>
> So, wrt Q2, what you are saying is, the following would cause issues in
Python 3?
>
> int f(int x,
> ..int y) {
> --->return g(x,
> --->.y);
> }
>
> Where:
>
> ---> for tabs (used for indentation)
>  for spaces (used for alignment)

That example should be fine, I think (if it were actually Python  and not
C, that is). The second line is a continuation of the first line, so the
preceding whitespace isn't indentation and doesn't matter. Likewise for the
fourth line. So the only line with any actual indentation there is the
third line.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Cameron Simpson]

On 06Dec2014 09:29, Steven D'Aprano  
wrote:

Cameron Simpson wrote:

I have spent too much time reading files indented
with TABs by people using a different tabwidth to my own, and thus looking
aweful on my screen. The original author didn't choose to make it awful,
but their tabs rendered in my tab scheme look awful. And doubtless vice
versa. The root cause of this is that when we, as humans, indent with
tabs, we do it to achieve a certain visual effect; as though a certain
number of spaces were in play.


How is this different from people who achieve a certain visual effect by
indenting with actual spaces?

I've seen people indent with 8 spaces. I've seen people indent with 2
spaces. I've even seen people indent with a single space per level. I
haven't seen anyone indent with 17 spaces, but I suppose it's only a matter
of time...

I don't see how reading code indented with tabs configured for 8/4/2/1
spaces is *worse* than reading tab indented with 8/4/2/1 spaces.


Because the author will have chosen a scheme not too insane. But when I pull up 
their indented-with-2-or-4-tab files in my tab==8 editor, it looks terrible.  
When I pull up their indented-with-spaces in whatever scheme, it looks as good 
or bad as their judgement, which even when tasteless is usually better than 
overwide tabs.


I would rather not have to readjust my editor's tab spacing every time I load 
up a file from someone-who-is-not-me. If they use spaces, I don't have to. If 
they use tabs and do not indent like I do, I have to to keep things readable.


Cheers,
Cameron Simpson 

They shouldn't get any new nuclear weapons until they've used the ones
they've got.- Murff
--
https://mail.python.org/mailman/listinfo/python-list

Re: jitpy - Library to embed PyPy into CPython

[Terry Reedy]

On 12/5/2014 2:54 PM, Mark Lawrence wrote:

For those who haven't heard thought this might be of interest
https://github.com/fijal/jitpy


So the old cpython module psyco which became the pypy jit is back as 
jitpy.  Nice.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Do you like the current design of python.org?

[Ian Kelly]

On Fri, Dec 5, 2014 at 4:30 AM, Fetchinson . 
wrote:
> > The formatting of long text essays get completely mangled towards the
> > bottom
> > of the page, e.g.:
> >
> > https://www.python.org/download/releases/2.2/descrintro
>
> It doesn't look mangled to me (firefox 22).

That's quite old at this point, considering that the current extended
support release is 31 and the previous one was 24. You should consider
upgrading for security fixes if nothing else.

As to the subject at hand, the page also looks fine to me in Chrome 39.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Do you like the current design of python.org?

[Ian Kelly]

On Fri, Dec 5, 2014 at 3:43 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> It requires Javascript or else basic functionality fails.

In what way does basic functionality fail? I just tried loading the page
with Javascript disabled and it seemed fine.

> With Javascript,
> basic functionality fails too, but in a much more entertaining and
exciting
> way, as in "I'm trying to click a button on that menu, why does the screen
> keep refreshing and hiding the menu before I can click?".

I've not encountered this myself.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Aahan Krish]

Hello Ned,

I thought that the use of tabs and spaces in the manner I suggested is
pretty common. Linux Kernel follows the same technique, for example:
https://github.com/torvalds/linux/blob/master/kernel/async.c#L100

Of course, I understand the gist of what you are saying—if people don't
understand this technique properly and start mixing up tabs and spaces
interchangeably or wrongly the code'd get mangled pretty quickly.

Thank you for the heads up!


Best,
Aahan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Ned Batchelder]

On 12/5/14 8:50 PM, Aahan Krish wrote:

Hello Ned,

I thought that the use of tabs and spaces in the manner I suggested is
pretty common. Linux Kernel follows the same technique, for example:
https://github.com/torvalds/linux/blob/master/kernel/async.c#L100



This is a perfect example!  The code (with tabs as >--- and leading 
spaces as .) is:


 >---if (!list_empty(pending))
 >--->---ret = list_first_entry(pending, struct async_entry,
 >--->--->--->---...domain_list)->cookie;

Now, display it in your editor with tabs set to four spaces:

 >---if (!list_empty(pending))
 >--->---ret = list_first_entry(pending, struct async_entry,
 >--->--->--->---...domain_list)->cookie;

"domain_list" and "pending" no longer line up, even though the author 
worked so hard to make the code look nice.


In fact, the Linux kernel specifically says that tabs must be eight 
spaces (https://www.kernel.org/doc/Documentation/CodingStyle):


Tabs are 8 characters, and thus indentations are also 8
characters.  There are heretic movements that try to make
indentations 4 (or even 2!) characters deep, and that is akin
to trying to define the value of PI to be 3.

So you've started by trying to use tabs so that people can choose the 
indentation width they like, and ended up with a strict rule that you 
cannot change the size of tabs.


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Aahan Krish]

Hello Ned, I didn't notice that he was using tabs more than as needed for
indentation. Guess I trusted the wrong guy. :P Anyway, it's one more thing
to keep in mind. G!

--
Aahan Krish
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Michael Torrie]

On 12/05/2014 07:31 PM, Ned Batchelder wrote:
> This is a perfect example!  The code (with tabs as >--- and leading 
> spaces as .) is:
> 
>   >---if (!list_empty(pending))
>   >--->---ret = list_first_entry(pending, struct async_entry,
>   >--->--->--->---...domain_list)->cookie;
> 
> Now, display it in your editor with tabs set to four spaces:
> 
>   >---if (!list_empty(pending))
>   >--->---ret = list_first_entry(pending, struct async_entry,
>   >--->--->--->---...domain_list)->cookie;

However, a conscientious programmer knows that tabs could be arbitrarily
sized, so he would never do that.  Instead he would do:

   >---if (!list_empty(pending))
   >--->---ret = list_first_entry(pending, struct async_entry,
   >--->---...domain_list)->cookie;

Which under the heretical tab size of 4:
   >---if (!list_empty(pending))
   >--->---ret = list_first_entry(pending, struct async_entry,
   >--->---...domain_list)->cookie;

In fact a decent editor that is auto-indenting code would, at least in C
or C++ mode, do that automatically.

Maybe I misread, but I would think this is what the OP had in mind.
Of course maybe kernel programmers think differently.  Ahh well.




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Ned Batchelder]

On 12/5/14 10:04 PM, Michael Torrie wrote:

On 12/05/2014 07:31 PM, Ned Batchelder wrote:

This is a perfect example!  The code (with tabs as >--- and leading
spaces as .) is:

   >---if (!list_empty(pending))
   >--->---ret = list_first_entry(pending, struct async_entry,
   >--->--->--->---...domain_list)->cookie;

Now, display it in your editor with tabs set to four spaces:

   >---if (!list_empty(pending))
   >--->---ret = list_first_entry(pending, struct async_entry,
   >--->--->--->---...domain_list)->cookie;


However, a conscientious programmer knows that tabs could be arbitrarily
sized, so he would never do that.


The Linux kernel style guide makes clear: tabs are not arbitrarily 
sized. In the Linux kernel, they are eight spaces.


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs for indentation & Spaces for alignment in Python 3?

[Dave Angel]

On 12/05/2014 09:48 PM, Aahan Krish wrote:

Hello Ned, I didn't notice that he was using tabs more than as needed for
indentation. Guess I trusted the wrong guy. :P Anyway, it's one more thing
to keep in mind. G!



Several times now you have started a new thread to comment on an 
existing one.  Please use the reply-list feature of your email program 
or newsgroup reader.


New messages are for new threads.

And while I'm at it, please use text messages.  html messages are wrong 
here for a number of reasons, even though none of them have apparently 
affected your recent messages.

--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list