Re: How to read and post tracebacks (was Registry Key Value Help)

[Chris Angelico]

On Fri, Jan 3, 2014 at 4:16 PM, Rustom Mody  wrote:
> Something like this is what I had in mind
> http://help.openerp.com/question/9704/how-to-read-and-understand-errors-from-tracebacks/
>

Hrm, site's having trouble. First time I tried it, it came back with a
gateway timeout. Seemed to work second time, though, so now I have the
content up.

That sort of thing is fine when you're working with a very specific
framework. (Look at point 6, for instance. Knowing the boundary
between "code we trust because it's really thoroughly tested" and
"code that might be the cause of the bug" means knowing what the
framework is, usually.) If you understand the code enough to pinpoint
the problem, you probably know enough to fix the problem, and if you
don't, you can save yourself a lot of analysis by just posting the
whole traceback for someone else to read. So while that advice may be
helpful on that site's forum, for the general field of python-list
it's probably more useful to just tell people to quote the whole
traceback, and then we can figure things out.

That's the "advice for python-list" part, though. What about the
opposite side of that - helping people to understand their own code?
Well, it's what I said in the parens about knowing the boundary. This
is completely language-independent now; I had the same thing come up
in REXX, the same thing will happen if you're debugging something in
gdb, and it happens to me all the time in Pike. In all four languages
it's common for the actual exception (or signal, in the case of gdb)
to emanate from somewhere below user code. So there are two options:
Either get so familiar with the library code that you recognize where
to stop reading, or get so familiar with the code you're debugging
that you recognize where to start reading. The first one is great for
users-helping-users forums, the second is superb for your own code :)
And if you can't do either of those, a crystal ball helps alot;
chances are an expert can go to the right area even without knowing
the code, just by what "looks right" and what "looks wrong". A handy
fallback.

ChrisA

PS. I left a typo in there because I'd love to see a drawing of a
crystal ball helping Alot.
http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ifs and assignments

[Chris Angelico]

On Fri, Jan 3, 2014 at 3:16 PM, Ethan Furman  wrote:
> On 01/02/2014 04:06 PM, Chris Angelico wrote:
>>
>>
>> Here's a crazy idea. Suppose we have a "sticky falseness" that can
>> quietly propagate through an expression the way a NaN can... then we
>> could just float that right through the .group() call.
>>
>> class truth:
>
> An interesting idea.  You'd need to add (at least) __getitem__, and I'll
> probably call it `maybe`, myself.  ;)

I was going for something like bool(). If you pass something through
bool(), you get either True or False; if you pass something through
this, you get either itself or something that acts like False.

>> (I'm not sure if I'm using __new__ correctly; I've never actually done
>> it in production code, and the info I found online was mainly Py2
>> examples. Should that be done with super(), or is that applicable only
>> once there's an actual instance with a real MRO?)
>
> I haven't tested it, but your __new__ looks fine.  The only thing you lose
> by not calling super() is the inability for cooperative multiple
> inheritance, except as the ultimate base class.

Is it possible to have multiple inheritance at this point, though? I
get a class argument, not an instance, because there isn't an
instance.

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

Re: How to read and post tracebacks (was Registry Key Value Help)

[Rustom Mody]

On Fri, Jan 3, 2014 at 9:33 AM, Chris Angelico  wrote:
> On Fri, Jan 3, 2014 at 2:58 PM, Rustom Mody  wrote:
>> Why not write up a few lines on "How to read and post python tracebacks"
>> and post it on the wiki?
>
> You mean "copy and paste the whole output"? I'm not sure what more
> needs to be said about posting them.
>
> Reading them is a bit more complicated, but possibly _too_ complicated
> for a simple wiki post. Being able to quickly eyeball a traceback and
> know which level to look for the problem at is part of the skill of
> debugging, and it usually requires that you know the codebase fairly
> well too. Though even with unfamiliar code, it's possible to figure a
> lot out by naming conventions, which is why they're so important (all
> uppercase meaning "constant" and normally a scalar - so useful).

Something like this is what I had in mind
http://help.openerp.com/question/9704/how-to-read-and-understand-errors-from-tracebacks/

Obviously it can be written much better (and thought you could make a start :D)

[I wonder if the "please make it readable thus not thus" at end proves
or disproves Roy's point??]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Blog "about python 3"

[Steven D'Aprano]

Robin Becker wrote:

> For fairly sensible reasons we changed the internal default to use unicode
> rather than bytes. After doing all that and making the tests compatible
> etc etc I have a version which runs in both and passes all its tests.
> However, for whatever reason the python 3.3 version runs slower

"For whatever reason" is right, unfortunately there's no real way to tell
from the limited information you give what that might be.

Are you comparing a 2.7 "wide" or "narrow" build? Do your tests use any
so-called "astral characters" (characters in the Supplementary Multilingual
Planes, i.e. characters with ord() > 0x)?

If I remember correctly, some early alpha(?) versions of Python 3.3
consistently ran Unicode operations a small but measurable amount slower
than 3.2 or 2.7. That especially effected Windows. But I understand that
this was sped up in the release version of 3.3.

There are some operations with Unicode strings in 3.3 which unavoidably are
slower. If you happen to hit a combination of such operations (mostly to do
with creating lots of new strings and then throwing them away without doing
much work) your code may turn out to be a bit slower. But that's a pretty
artificial set of code.

Generally, test code doesn't make good benchmarks. Tests only get run once,
in arbitrary order, it spends a lot of time setting up and tearing down
test instances, there are all sorts of confounding factors. This plays
merry hell with modern hardware optimizations. In addition, it's quite
possible that you're seeing some other slow down (the unittest module?) and
misinterpreting it as related to string handling. But without seeing your
entire code base and all the tests, who can say for sure?


> 2.7 Ran 223 tests in 66.578s
> 
> 3.3 Ran 223 tests in 75.703s
> 
> I know some of these tests are fairly variable, but even for simple things
> like paragraph parsing 3.3 seems to be slower. Since both use unicode
> internally it can't be that can it, or is python 2.7's unicode faster?

Faster in some circumstances, slower in others. If your application
bottleneck is the availability of RAM for strings, 3.3 will potentially be
faster since it can use anything up to 1/4 of the memory for strings. If
your application doesn't use much memory, or if it uses lots of strings
which get created then thrown away.


> So far the superiority of 3.3 escapes me, 

Yeah I know, I resisted migrating from 1.5 to 2.x for years. When I finally
migrated to 2.3, at first I couldn't see any benefit either. New style
classes? Super? Properties? Unified ints and longs? Big deal. Especially
since I was still writing 1.5 compatible code and couldn't really take
advantage of the new features.

When I eventually gave up on supporting versions pre-2.3, it was a load off
my shoulders. Now I can't wait to stop supporting 2.4 and 2.5, which will
make things even easier. And when I can ignore everything below 3.3 will be
a truly happy day.


> but I'm tasked with enjoying 
> this process so I'm sure there must be some new 'feature' that will help.
> Perhaps 'yield from' or 'raise from None' or ...

No, you have this completely backwards. New features don't help you support
old versions of Python that lack those new features. New features are an
incentive to drop support for old versions.


> In any case I think we will be maintaining python 2.x code for at least
> another 5 years; the version gap is then a real hindrance.

Five years sounds about right.



-- 
Steven

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

Re: About some problem

[Mark Lawrence]

On 03/01/2014 04:18, Ethan Furman wrote:

On 01/02/2014 05:14 PM, Mark Lawrence wrote:

On 02/01/2014 23:49, Steven D'Aprano wrote:

Mark Lawrence wrote:


raise "Not Valid DB Type"

is perfectly valid in Python 2.


Actually, no it isn't. It's only valid up to Python 2.4. In Python 2.5,
string exceptions display a warning but continue to work, and in
Python 2.6
they generate a compile-time SyntaxError.



Thaanks for the correction.


You know how the world ended when Python 2.6 broke backwards
compatibility
and split the Python community into two? No, me neither.



I'm 100% certain that you're wrong on this one, the split was simply
never noticed by anybody :)


Actually, the split was so severe the universe itself noticed and split
into two -- one where folks noticed, and one where nobody did... I
wonder which one we're in?

--
~Ethan~



The one where Breamore's at the centre.

--
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: Ifs and assignments

[Ethan Furman]

On 01/02/2014 04:06 PM, Chris Angelico wrote:


Here's a crazy idea. Suppose we have a "sticky falseness" that can
quietly propagate through an expression the way a NaN can... then we
could just float that right through the .group() call.

class truth:
 def __new__(cls, x):
 if x: return x
 return object.__new__(cls)
 def __bool__(self):
 return False
 def __getattr__(self, name):
 return self
 def __call__(self, *args, **kwargs):
 return self
 def __repr__(self):
 return repr(False)

Pass any object through truth() and it'll either stay the same (if
it's true) or become this object (if it's false). You can then carry
on with other method calls, and they'll all happily return false.


An interesting idea.  You'd need to add (at least) __getitem__, and I'll 
probably call it `maybe`, myself.  ;)




(I'm not sure if I'm using __new__ correctly; I've never actually done
it in production code, and the info I found online was mainly Py2
examples. Should that be done with super(), or is that applicable only
once there's an actual instance with a real MRO?)


I haven't tested it, but your __new__ looks fine.  The only thing you 
lose by not calling super() is the inability for cooperative multiple 
inheritance, except as the ultimate base class.


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

Re: About some problem

[Ethan Furman]

On 01/02/2014 05:14 PM, Mark Lawrence wrote:

On 02/01/2014 23:49, Steven D'Aprano wrote:

Mark Lawrence wrote:


raise "Not Valid DB Type"

is perfectly valid in Python 2.


Actually, no it isn't. It's only valid up to Python 2.4. In Python 2.5,
string exceptions display a warning but continue to work, and in
Python 2.6
they generate a compile-time SyntaxError.



Thaanks for the correction.


You know how the world ended when Python 2.6 broke backwards
compatibility
and split the Python community into two? No, me neither.



I'm 100% certain that you're wrong on this one, the split was simply
never noticed by anybody :)


Actually, the split was so severe the universe itself noticed and split 
into two -- one where folks noticed, and one where nobody did... I 
wonder which one we're in?


--
~Ethan~

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

Re: How to read and post tracebacks (was Registry Key Value Help)

[Roy Smith]

In article ,
 Chris Angelico  wrote:

> On Fri, Jan 3, 2014 at 2:58 PM, Rustom Mody  wrote:
> > Why not write up a few lines on "How to read and post python tracebacks"
> > and post it on the wiki?
> 
> You mean "copy and paste the whole output"? I'm not sure what more
> needs to be said about posting them.
> 
> Reading them is a bit more complicated, but possibly _too_ complicated
> for a simple wiki post. Being able to quickly eyeball a traceback and
> know which level to look for the problem at is part of the skill of
> debugging, and it usually requires that you know the codebase fairly
> well too. Though even with unfamiliar code, it's possible to figure a
> lot out by naming conventions, which is why they're so important (all
> uppercase meaning "constant" and normally a scalar - so useful).
> 
> ChrisA

One of the things I dislike about Python stack dumps is the alternation 
between lines of file locations and source code snippets.  Cognitively, 
jumping back and forth makes it more difficult to understand than it has 
to be.

They would be much easier to read (IMHO) if each stack frame took one 
line.  Sure, the lines would be longer, but I can easily get 300 columns 
of text on my laptop screen and still read it easily with my 
50-something eyes.

Yeah, yeah, I know, we're still living in an 80-column world.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ifs and assignments

[Mark Lawrence]

On 03/01/2014 04:25, Chris Angelico wrote:

On Fri, Jan 3, 2014 at 3:14 PM, Roy Smith  wrote:

Or turn it into a generator:
That certainly makes your mainline code cleaner...


Cleaner perhaps, but not clearer. Instead of seeing the original
function (say, a database retrieve-next call), you see a wrapper and
have to go dig to find out what it's actually doing. Unless it's some
kind of generic handler, like:

def funcinator(func,*args):
while True:
   var = func(*args)
   if var:
  yield var
   else:
  break

while funcinator(cur.getnext):
 

But even that would be problematic until it got so thoroughly
understood that it's like enumerate() - which is itself still not
perfect.

ChrisA



I find the above rather funcy :)

--
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: Ifs and assignments

[Chris Angelico]

On Fri, Jan 3, 2014 at 3:14 PM, Roy Smith  wrote:
> Or turn it into a generator:
> That certainly makes your mainline code cleaner...

Cleaner perhaps, but not clearer. Instead of seeing the original
function (say, a database retrieve-next call), you see a wrapper and
have to go dig to find out what it's actually doing. Unless it's some
kind of generic handler, like:

def funcinator(func,*args):
   while True:
  var = func(*args)
  if var:
 yield var
  else:
 break

while funcinator(cur.getnext):


But even that would be problematic until it got so thoroughly
understood that it's like enumerate() - which is itself still not
perfect.

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

Re: Ifs and assignments

[Roy Smith]

In article ,
 Chris Angelico  wrote:

> while (var = func())
> {
> 
> }
> 
> In Python, that gets a lot clunkier. The most popular way is to turn
> it into an infinite loop:
> 
> while True:
> var = func()
> if not var: break
> 

Or turn it into a generator:

def funcinator():
   while True:
  var = func()
  if var:
 yield var
  else:
 break

for var in funcinator():
   

That certainly makes your mainline code cleaner, but it's a lot of crud 
when all you really wanted to write was:

while func() as var:
   
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ifs and assignments

[Chris Angelico]

On Fri, Jan 3, 2014 at 3:00 PM, Roy Smith  wrote:
> I do this all the time:
>
> t0 = time.time()
> [some code]
> t1 = time.time()
> dt = t1 = t0   # <-- spot the typo?

Yep, I see that... now that it's pointed out as a typo. Without the
marker, I'd assume it's correct chained assignment, and only an
examination of the name (dt = delta t) hints otherwise.

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

Re: Ifs and assignments

[Roy Smith]

In article ,
 Chris Angelico  wrote:

> On Fri, Jan 3, 2014 at 2:33 PM, Steven D'Aprano
>  wrote:
> > Personally, I find it hard to care about assignment as an expression. I find
> > the obvious C-inspired syntax terrible, as it is too easy to mistakenly use
> > == instead of = or visa versa:
> 
> Python has similar problems, though. It's inherent to the nature of
> symbolic languages.
> 
> a = (1, 2, 3)
> b = {1, 2, 3}
> 
> In many fonts, it's hard to tell one from the other without peering.
> Do people decry set literal notation in favour of explicitly writing
> the word "set"? No; and I think most of us agree that it's better to
> have the symbols. At least with == vs = there's a length difference. I
> don't think it's C's fault or problem that equality and assignment
> look similar and can be used in the same places, any more than it's a
> problem to have assignment and subtraction differ by only one stroke:
> 
> a - (1, 2, 3)
> 
> Is that confusingly similar to assignment?
> 
> ChrisA

I do this all the time:

t0 = time.time()
[some code]
t1 = time.time()
dt = t1 = t0   # <-- spot the typo?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to read and post tracebacks (was Registry Key Value Help)

[Chris Angelico]

On Fri, Jan 3, 2014 at 2:58 PM, Rustom Mody  wrote:
> Why not write up a few lines on "How to read and post python tracebacks"
> and post it on the wiki?

You mean "copy and paste the whole output"? I'm not sure what more
needs to be said about posting them.

Reading them is a bit more complicated, but possibly _too_ complicated
for a simple wiki post. Being able to quickly eyeball a traceback and
know which level to look for the problem at is part of the skill of
debugging, and it usually requires that you know the codebase fairly
well too. Though even with unfamiliar code, it's possible to figure a
lot out by naming conventions, which is why they're so important (all
uppercase meaning "constant" and normally a scalar - so useful).

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

How to read and post tracebacks (was Registry Key Value Help)

[Rustom Mody]

On Fri, Jan 3, 2014 at 8:35 AM, Chris Angelico  wrote:
> On Fri, Jan 3, 2014 at 11:12 AM, J. McGaha  wrote:
>> When I run the this code I get an error that says the ‘int’ can’t be called.
>>
>
> Python errors include full backtraces that show exactly what's going
> on. They are extremely helpful, so when you post questions like this,
> you should copy and paste the whole thing.
>
> In this case, though, I'm pretty sure the problem is here:


Hey Chris!
Why not write up a few lines on "How to read and post python tracebacks"
and post it on the wiki?

If you feel like just summarizing the points and let someone else post it,
I or someone else can do it

[Or does such a page already exist?]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ifs and assignments

[Chris Angelico]

On Fri, Jan 3, 2014 at 2:33 PM, Steven D'Aprano
 wrote:
> Personally, I find it hard to care about assignment as an expression. I find
> the obvious C-inspired syntax terrible, as it is too easy to mistakenly use
> == instead of = or visa versa:

Python has similar problems, though. It's inherent to the nature of
symbolic languages.

a = (1, 2, 3)
b = {1, 2, 3}

In many fonts, it's hard to tell one from the other without peering.
Do people decry set literal notation in favour of explicitly writing
the word "set"? No; and I think most of us agree that it's better to
have the symbols. At least with == vs = there's a length difference. I
don't think it's C's fault or problem that equality and assignment
look similar and can be used in the same places, any more than it's a
problem to have assignment and subtraction differ by only one stroke:

a - (1, 2, 3)

Is that confusingly similar to assignment?

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

Re: About some problem

[Larry Hudson]

On 01/02/2014 08:31 AM, raj kumar wrote:

Hello, I am beginner to python and i am writing following code

from pytesser import *

and i am getting an error as follow

Traceback (most recent call last):
   File "", line 1, in 
   File "C:\Python33\lib\site-packages\pytesser.py", line 61
 print text
  ^
SyntaxError: invalid syntax



From your traceback:
   File "C:\Python33\lib\site-packages\pytesser.py", line 61
  ^
You are using Python 3.3, but the line "print text" is Python 2 syntax.
Python 3 requires parentheses:  print(text)

Obviously the pytesser.py file is written for Python 2 and it is an error to be installed with 
your Python 3 packages.




How to resolve it ? Give me all steps to resolve it.



It would be nicer if you would request help rather than demand it.  However, it seems to be some 
sort of installation error.  Without knowing anything about your system we can't help with that. 
 You'll have to figure it out for yourself, or give us more information:  where you got it, how 
you installed it, anything else relevant.


(We do appreciate full tracebacks, however.  Thank you for that.  Many people summarize or 
paraphrase error messages, which is not as helpful.)


 -=- Larry -=-

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

Re: Ifs and assignments

[Chris Angelico]

On Fri, Jan 3, 2014 at 2:33 PM, Steven D'Aprano
 wrote:
> However, I don't think we should treat this as specific to if statements:
>
> for i, obj in enumerate(alist + blist + clist as items):
> items[i] = process(obj)
>
>
> Is that really better than this?
>
> items = alist + blist + clist
> for i, obj in enumerate(items):
> items[i] = process(obj)

It definitely shouldn't be specific to if statements, though I think
that's probably going to be the biggest use-case (chained if/elif
blocks). Maybe a for loop isn't the best other example, but I
frequently work with places where I want to call some function and
keep iterating with the result of that until it returns false:

while (var = func())
{

}

In Python, that gets a lot clunkier. The most popular way is to turn
it into an infinite loop:

while True:
var = func()
if not var: break


which is pretty much how the C version will compile down, most likely.
It feels like an assembly language solution. The point of a while loop
is to put its condition into the loop header - burying it inside the
indented block (at the same indentation level as most of the code)
conceals that, and this is a very simple and common condition. So this
is what I'd cite as a second use-case:

while func() as var:


And that definitely looks more readable.

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

Re: Ifs and assignments

[Steven D'Aprano]

Dennis Lee Bieber wrote:

> On Thu, 02 Jan 2014 17:20:54 +, John Allsup 
> declaimed the following:

>>In many languages, such as C, one can use assignments in conditionals
>>and expressions.  The most common, and useful case turns up when you
> 
> Really? You can't do it in FORTRAN, BASIC, COBOL, Pascal, Ada...
> 
> C, C++, Java, C# are all based on the same core syntax. For all
> effective purposes, they are the same as grouping M$ Visual BASIC,
> GW-BASIC, Kemeny&Kurtz TrueBASIC as "most languages, such as BASIC"...


Thank you for pointing this out! Far too many people imagine that C and the
C-inspired languages make up the entire universe of programming.

But having said that, features should be judged on their merit, not on
whether they are familiar to Ada/Lisp/C/Algol/... programmers. (Although
familiarity is one factor out of many which should be considered.)

Personally, I find it hard to care about assignment as an expression. I find
the obvious C-inspired syntax terrible, as it is too easy to mistakenly use
== instead of = or visa versa:

if m = re.match(pattern, text):
...

Using "as" is slightly better:

if re.match(pattern, text) as m:
...

but I don't think it's sufficiently useful for me to get excited about it.

However, I don't think we should treat this as specific to if statements:

for i, obj in enumerate(alist + blist + clist as items):
items[i] = process(obj)


Is that really better than this?

items = alist + blist + clist
for i, obj in enumerate(items):
items[i] = process(obj)



-- 
Steven

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

Re: Registry Key Value Help

[Chris Angelico]

On Fri, Jan 3, 2014 at 11:12 AM, J. McGaha  wrote:
> When I run the this code I get an error that says the ‘int’ can’t be called.
>

Python errors include full backtraces that show exactly what's going
on. They are extremely helpful, so when you post questions like this,
you should copy and paste the whole thing.

In this case, though, I'm pretty sure the problem is here:

wr.KEY_SET_VALUE(aKey,"DisableAutoUpdateChecksCheckboxValue",  1, wr.REG_DWORD)

The all-uppercase keyword strongly suggests that this is a constant,
as I can confirm with my Python 3.3.0 (by the way, it's also helpful
to say what version of Python you're using). I suspect, without
looking at the docs, that what you want is actually wr.SetValue or
wr.SetValueEx, which are named like functions (or classes). Check out
the docs for those functions and see if they're what you need.

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

Registry Key Value Help

[J. McGaha]

Good evening, I am a complete noob at Python.  I am attempting to create a
key and update its value.  The code below is what I have come up with after
reading everything I can get my hands on.  

 

When I run the this code I get an error that says the 'int' can't be called.

 

I appreciate your help

 

 

 

import _winreg as wr
aReg = wr.ConnectRegistry(None, wr.HKEY_LOCAL_MACHINE)
targ = r'SOFTWARE\Policies\Google\Update'
aKey = wr.OpenKey(aReg, targ, 0, wr.KEY_WRITE)
wr.KEY_SET_VALUE(aKey,"DisableAutoUpdateChecksCheckboxValue",  1,
wr.REG_DWORD)
wr.CloseKey(aKey)
wr.CloseKey(aReg)
  

 

I appreciate your help

 

 

John

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

Re: need to print seconds from the epoch including the millisecond

[Dave Angel]

On Thu, 2 Jan 2014 16:23:22 + (UTC), Grant Edwards 
 wrote:

AFAIK, that's irrelevent.  time.time() returns a float.  On all the
CPython implementations I know of, that is a 64-bit IEEE format, 

which
provides 16 decimal digits of precision regardless of the 

granularity
of the system time value.  At this point in time, that means 10 

digits

left of the decimal point and 6 to the right.


Correction: no more than about 6 to the right.  You can certainly get 
less, from an os with a smaller resolution.  Or you can lose some of 
what you do get by printing in a sub-optimal way.


--
DaveA

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

Re: Ifs and assignments

[Mark Lawrence]

On 03/01/2014 00:57, Gary Herron wrote:

On 01/02/2014 01:44 PM, John Allsup wrote:

The point of my original post was that, whilst C's
  if( x = 2 ) { do something }
and
  if( x == 2 ) { do something }
are easy to confuse, and a source of bugs, having a construct like
follows:

if x == 2:
do something # what happens at present
if testFunc() as x:
do something with x

using the 'as' syntax that appears with 'with' and 'except', would allow
for the advantages of C style assignments in conditionals but without
the easy confusion, since here the syntax is significantly different
between assignment and equality testing (rather than a character apart
as happens with C).

This occurs further down in my original post (past the point where you
inserted your reply).

Another post suggested a workaround by defining a 'pocket' class, for
which I am grateful.

John


Sorry.  I shot off my answer before reading the whole post.  That's
never a good idea.


After reading to the end, I rather like your suggestion.  It works well
in your example, , nicely avoids the C/C++ trap, and has some
consistency with other parts of Python.

Gary Herron




I liked the look of this as well.  It ought to go to python ideas, or 
has it been suggested there in the past?


--
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: About some problem

[Mark Lawrence]

On 02/01/2014 23:49, Steven D'Aprano wrote:

Mark Lawrence wrote:


raise "Not Valid DB Type"

is perfectly valid in Python 2.


Actually, no it isn't. It's only valid up to Python 2.4. In Python 2.5,
string exceptions display a warning but continue to work, and in Python 2.6
they generate a compile-time SyntaxError.



Thaanks for the correction.


You know how the world ended when Python 2.6 broke backwards compatibility
and split the Python community into two? No, me neither.



I'm 100% certain that you're wrong on this one, the split was simply 
never noticed by anybody :)


--
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: Ifs and assignments

[Gary Herron]

On 01/02/2014 01:44 PM, John Allsup wrote:

The point of my original post was that, whilst C's
  if( x = 2 ) { do something }
and
  if( x == 2 ) { do something }
are easy to confuse, and a source of bugs, having a construct like 
follows:


if x == 2:
do something # what happens at present
if testFunc() as x:
do something with x

using the 'as' syntax that appears with 'with' and 'except', would allow
for the advantages of C style assignments in conditionals but without 
the easy confusion, since here the syntax is significantly different 
between assignment and equality testing (rather than a character apart 
as happens with C).


This occurs further down in my original post (past the point where you 
inserted your reply).


Another post suggested a workaround by defining a 'pocket' class, for 
which I am grateful.


John


Sorry.  I shot off my answer before reading the whole post.  That's 
never a good idea.



After reading to the end, I rather like your suggestion.  It works well 
in your example, , nicely avoids the C/C++ trap, and has some 
consistency with other parts of Python.


Gary Herron





On 02/01/2014 19:27, Gary Herron wrote:

On 01/02/2014 09:20 AM, John Allsup wrote:

Hi,

This is my debut on this list.

In many languages, such as C, one can use assignments in conditionals
and expressions.  The most common, and useful case turns up when you
have if/else if/else if/else constructs. Consider the following
non-working pseudoPython.

import re
r1 = re.compile("hello (\d)")
r2 = re.compile("world([!?])")

w = "hello world!"

if m = r1.search(w):


This kind of thing in C/C+ has always been the source of much confusion
and potential errors, because the construct is so similar to an "=="
test.  Python does not replicate this potential for confusion. Instead,
we use two lines of code, an assignment and then the test.   If you find
that extra line of code inconvenient than at least you can take comfort
in the fact that it is clearer code.  If you are still not convinced,
... then sorry, that's just the way Python is.

Gary Herron



handleMatch1(m)
elif m = r2.search(w):
handleMatch2(m)
else:
print("No match")

If the regular expressions are complex, running them multiple times
(once to test, another to capture groups) isn't ideal.  On the other
hand, at present, one has to either do:

m = r1.search(w)
if m:
handleMatch1(m)
else:
m = r2.search(w)
if m:
handleMatch2(m)
else:
print("No match")

if not running unnecessary matches, yet capturing groups in the event
of a successful match, is what is desired.

If there are multiple tests, the indentation gets silly.  This arises
because having removed the ability to assign in an expression, there
is no way to save the result of a function call that is used in a
conditional at all.

I am aware that this facility in C is a source of bugs, = being only a
typo away from the more common ==.  With exceptions and contexts, we
have:

with open("file") as f:
doSomethingWith(f)

try:
trySomething()
except SomethingRandomGoingWrong as e:
lookAtException(e)

What I am wondering is why not use a similar syntax with if, so that
one could do

if r1.search(w) as m:
g = m.groups()
print(g[1])

This would remove the risk of errors by typos since the syntax for
equality testing (if x == y:) is completely different from that for
assigning in a conditional (which would look like 'if y as x:'

Related would be to have Nonetype work with contexts such that

with None as x:
doStuff(x)

would do nothing.  This would allow things like:

with maybeGetSomething as x:
doStuff(x)

to call doStuff(x) within a context of maybeGetSomething returns
something, or do nothing if nothing is returned.  (Adding an else-like
keyword to with, or possibly using else in that context, would allow
one to process a non-None object if returned, or else do something in
response to a None object being returned by the maybeGetSomething.)

Just a thought.

Or what is the current 'Pythonic' way to do something like:

if x = func1():
do1(x)
elif x = func2():
do2(x)
elif x = func3():
do3(x)
elif x = func4():
do4(x)
else:
do5()

where each of func1,func2,func3,func4 have side effects so that func2
is tested if and only if func1 returns a false value, func1 must be
called only once, and what is returned from func1 must be available to
the code inside the if block?


John







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

Re: Setuptools - cannot install

[Chris Angelico]

On Fri, Jan 3, 2014 at 9:26 AM,   wrote:
>   File "C:\Python\lib\mimetypes.py", line 255, in read_windows_registry
> with _winreg.OpenKey(hkcr, subkeyname) as subkey:
> TypeError: OpenKey() argument 2 must be str without null characters or None, 
> not str

Interestingly, I pulled up that file on my 3.3.0 (Windows) and that
line is different. May be related to this issue, which was cited in
the commit summary that effected the change:

http://bugs.python.org/issue15207

In 3.3.0, it looks for HKEY_CLASSES_ROOT plus subkey
r'MIME\Database\Content Type', but in 3.3.3 it's iterating over all
the subkeys in HKEY_CLASSES_ROOT. (Note that _winreg is simply the
winreg module or None if it couldn't be imported.) I wonder is it
possible you have a null character in a key?? It's worth a try.

>>> import winreg
>>> hkcr=winreg.OpenKey(winreg.HKEY_CLASSES_ROOT, '')
>>> for i in range(99):
key=winreg.EnumKey(hkcr,i)
if '\0' in key: print(repr(key))

If that throws a "No more data available" error without printing any
keys, then this isn't your problem.

Alternatively, you could hack C:\Python\lib\mimetypes.py to print out
subkeyname before attempting to open it. That would at least tell you
what the offending key is. My suspicion at the moment is that you may
have a corrupted registry, or else there's something that's possible
that the winreg module doesn't expect.

BTW, thanks for the first-line summary of version numbers. Much
appreciated! So many people don't give that.

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

Re: Ifs and assignments

[Chris Angelico]

On Fri, Jan 3, 2014 at 10:36 AM, Roy Smith  wrote:
> The most common place I wish for an atomic "test and assign" is with
> regexes, as in your examples.  This would be so much nicer than what we
> have to do now:
>
> if re.match(string) as m:
> print m.group(0)

Here's a crazy idea. Suppose we have a "sticky falseness" that can
quietly propagate through an expression the way a NaN can... then we
could just float that right through the .group() call.

class truth:
def __new__(cls, x):
if x: return x
return object.__new__(cls)
def __bool__(self):
return False
def __getattr__(self, name):
return self
def __call__(self, *args, **kwargs):
return self
def __repr__(self):
return repr(False)

Pass any object through truth() and it'll either stay the same (if
it's true) or become this object (if it's false). You can then carry
on with other method calls, and they'll all happily return false.

result = (
truth(re1.match(string)).group(0) or
truth(re2.match(string)).group(0) or
truth(re3.match(string)).group(0) or
default_value
)

(I'm not sure if I'm using __new__ correctly; I've never actually done
it in production code, and the info I found online was mainly Py2
examples. Should that be done with super(), or is that applicable only
once there's an actual instance with a real MRO?)

I've given the class a lower-case first letter as I'm basically using
this as a function. If this were ever to be considered for the
standard library I would expect to see that aspect of it heavily
bikeshedded, so I'm not too concerned about the details.

In a spirit of full disclosure, I must confess that the idea came from
Pike, where there's a variant member-lookup operator that will happily
return false from false rather than throwing an exception. :)

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

Re: Ifs and assignments

[Chris Angelico]

On Fri, Jan 3, 2014 at 11:06 AM, Chris Angelico  wrote:
> Pass any object through truth() and it'll either stay the same (if
> it's true) or become this object (if it's false). You can then carry
> on with other method calls, and they'll all happily return false.
>
> result = (
> truth(re1.match(string)).group(0) or
> truth(re2.match(string)).group(0) or
> truth(re3.match(string)).group(0) or
> default_value
> )

Oh, just thought of a possible snag. Since an empty string comes up as
false, this exact notation would fail if the re can match nothing. But
you probably know if it's possible for that to happen, so don't use
this simple short-hand. :)

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

Re: Blog "about python 3"

[Antoine Pitrou]

Hi,

Robin Becker  reportlab.com> writes:
> 
> For fairly sensible reasons we changed the internal default to use unicode 
> rather than bytes. After doing all that and making the tests compatible
etc etc 
> I have a version which runs in both and passes all its tests. However, for 
> whatever reason the python 3.3 version runs slower
> 
> 2.7 Ran 223 tests in 66.578s
> 
> 3.3 Ran 223 tests in 75.703s

Running a test suite is a completely broken benchmarking methodology.
You should isolate workloads you are interested in and write a benchmark
simulating them.

Regards

Antoine.


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

Re: On a scrollbar for tkinter

[Rick Johnson]

I know you're using Python3.x, so there may be new functionality in Tkinter 
that i am not aware of yet. I still have oodles of Python2.x dependencies and 
really don't see a need to make the jump yet -- so keep that in mind when 
taking my advice below. 

In the old days of Tkinter, if you wanted to scroll the mainframe (aka:root, 
aka:Tkinter.Tk) you had two choices:

OPTION_1. Use tk.Canvas and "create_window" method
http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/create_window.html

OPTION_2. The "TIX" extension widgets for Tkinter has a "scrolledwindow" object 
that requires much less work and provides a more intuitive interface than the 
canvas.

PS: It's "Terry" not "Teddy".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About some problem

[Steven D'Aprano]

Mark Lawrence wrote:

> raise "Not Valid DB Type"
> 
> is perfectly valid in Python 2.

Actually, no it isn't. It's only valid up to Python 2.4. In Python 2.5,
string exceptions display a warning but continue to work, and in Python 2.6
they generate a compile-time SyntaxError.


You know how the world ended when Python 2.6 broke backwards compatibility
and split the Python community into two? No, me neither.

-- 
Steven

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

Re: Ifs and assignments

[Roy Smith]

In article ,
 John Allsup  wrote:

> if testFunc() as x:
> do something with x

+1

The most common place I wish for an atomic "test and assign" is with 
regexes, as in your examples.  This would be so much nicer than what we 
have to do now:

if re.match(string) as m:
print m.group(0)

The analogy to

except SomeError as ex:

is very clear.  They are both "Perform some action, capture the result, 
do some test on it, and then make that captured value available bound to 
a name".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ifs and assignments

[John Allsup]

The point of my original post was that, whilst C's
  if( x = 2 ) { do something }
and
  if( x == 2 ) { do something }
are easy to confuse, and a source of bugs, having a construct like follows:

if x == 2:
do something # what happens at present
if testFunc() as x:
do something with x

using the 'as' syntax that appears with 'with' and 'except', would allow
for the advantages of C style assignments in conditionals but without 
the easy confusion, since here the syntax is significantly different 
between assignment and equality testing (rather than a character apart 
as happens with C).


This occurs further down in my original post (past the point where you 
inserted your reply).


Another post suggested a workaround by defining a 'pocket' class, for 
which I am grateful.


John


On 02/01/2014 19:27, Gary Herron wrote:

On 01/02/2014 09:20 AM, John Allsup wrote:

Hi,

This is my debut on this list.

In many languages, such as C, one can use assignments in conditionals
and expressions.  The most common, and useful case turns up when you
have if/else if/else if/else constructs. Consider the following
non-working pseudoPython.

import re
r1 = re.compile("hello (\d)")
r2 = re.compile("world([!?])")

w = "hello world!"

if m = r1.search(w):


This kind of thing in C/C+ has always been the source of much confusion
and potential errors, because the construct is so similar to an "=="
test.  Python does not replicate this potential for confusion. Instead,
we use two lines of code, an assignment and then the test.   If you find
that extra line of code inconvenient than at least you can take comfort
in the fact that it is clearer code.  If you are still not convinced,
... then sorry, that's just the way Python is.

Gary Herron



handleMatch1(m)
elif m = r2.search(w):
handleMatch2(m)
else:
print("No match")

If the regular expressions are complex, running them multiple times
(once to test, another to capture groups) isn't ideal.  On the other
hand, at present, one has to either do:

m = r1.search(w)
if m:
handleMatch1(m)
else:
m = r2.search(w)
if m:
handleMatch2(m)
else:
print("No match")

if not running unnecessary matches, yet capturing groups in the event
of a successful match, is what is desired.

If there are multiple tests, the indentation gets silly.  This arises
because having removed the ability to assign in an expression, there
is no way to save the result of a function call that is used in a
conditional at all.

I am aware that this facility in C is a source of bugs, = being only a
typo away from the more common ==.  With exceptions and contexts, we
have:

with open("file") as f:
doSomethingWith(f)

try:
trySomething()
except SomethingRandomGoingWrong as e:
lookAtException(e)

What I am wondering is why not use a similar syntax with if, so that
one could do

if r1.search(w) as m:
g = m.groups()
print(g[1])

This would remove the risk of errors by typos since the syntax for
equality testing (if x == y:) is completely different from that for
assigning in a conditional (which would look like 'if y as x:'

Related would be to have Nonetype work with contexts such that

with None as x:
doStuff(x)

would do nothing.  This would allow things like:

with maybeGetSomething as x:
doStuff(x)

to call doStuff(x) within a context of maybeGetSomething returns
something, or do nothing if nothing is returned.  (Adding an else-like
keyword to with, or possibly using else in that context, would allow
one to process a non-None object if returned, or else do something in
response to a None object being returned by the maybeGetSomething.)

Just a thought.

Or what is the current 'Pythonic' way to do something like:

if x = func1():
do1(x)
elif x = func2():
do2(x)
elif x = func3():
do3(x)
elif x = func4():
do4(x)
else:
do5()

where each of func1,func2,func3,func4 have side effects so that func2
is tested if and only if func1 returns a false value, func1 must be
called only once, and what is returned from func1 must be available to
the code inside the if block?


John





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

Re: Score one for unit testing.

[Chris Angelico]

On Fri, Jan 3, 2014 at 9:53 AM, Roy Smith  wrote:
> We've got a test that's been running fine ever since it was written a
> month or so ago.  Now, it's failing intermittently on our CI (continuous
> integration) box, so I took a look.

I recommend you solve these problems the way these folks did:

http://thedailywtf.com/Articles/Productive-Testing.aspx

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

Score one for unit testing.

[Roy Smith]

We've got a test that's been running fine ever since it was written a 
month or so ago.  Now, it's failing intermittently on our CI (continuous 
integration) box, so I took a look.

It turns out it's a stupid test because it depends on pre-existing data 
in the database.  But, the win is that while looking at the code to 
figure out why this was failing, I noticed a completely unrelated bug in 
the production code.

See, unit testing helps find bugs :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: On a scrollbar for tkinter

[eneskristo]

@Teddy

Yes, indeed I have, but so far I have only found material for scrolling in 
other stuff, not the main frame. If you can give me a link...
-- 
https://mail.python.org/mailman/listinfo/python-list

Setuptools - cannot install

[tim . hamza]

setuptools 2.0.2, win7 x64, python 3.3.3 (64bit), tried as user (who is admin, 
and as admin)

This started happening several versions ago.  Could not track down a setuptools 
support list.  Any ideas?

C:\Users\tim\Desktop\setuptools-2.0.2>python setup.py install
Traceback (most recent call last):
  File "setup.py", line 17, in 
exec(init_file.read(), command_ns)
  File "", line 8, in 
  File "C:\Users\tim\Desktop\setuptools-2.0.2\setuptools\__init__.py", line 11, 
in 
from setuptools.extension import Extension
  File "C:\Users\tim\Desktop\setuptools-2.0.2\setuptools\extension.py", line 5, 
in 
from setuptools.dist import _get_unpatched
  File "C:\Users\tim\Desktop\setuptools-2.0.2\setuptools\dist.py", line 15, in 

from setuptools.compat import numeric_types, basestring
  File "C:\Users\tim\Desktop\setuptools-2.0.2\setuptools\compat.py", line 49, 
in 
from http.server import HTTPServer, SimpleHTTPRequestHandler
  File "C:\Python\lib\http\server.py", line 654, in 
class SimpleHTTPRequestHandler(BaseHTTPRequestHandler):
  File "C:\Python\lib\http\server.py", line 839, in SimpleHTTPRequestHandler
mimetypes.init() # try to read system mime.types
  File "C:\Python\lib\mimetypes.py", line 348, in init
db.read_windows_registry()
  File "C:\Python\lib\mimetypes.py", line 255, in read_windows_registry
with _winreg.OpenKey(hkcr, subkeyname) as subkey:
TypeError: OpenKey() argument 2 must be str without null characters or None, 
not str
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ifs and assignments

[Tim Chase]

On 2014-01-02 17:20, John Allsup wrote:
> m = r1.search(w)
> if m:
>   handleMatch1(m)
> else:
>   m = r2.search(w)
>   if m:
>   handleMatch2(m)
>   else:
>   print("No match")
> 
> if not running unnecessary matches, yet capturing groups in the
> event of a successful match, is what is desired.
> 
> If there are multiple tests, the indentation gets silly.  This
> arises because having removed the ability to assign in an
> expression, there is no way to save the result of a function call
> that is used in a conditional at all.

Usually this is done something like

  pairs = (
  for r, fn in (
  (r1, handleMatch1),
  (r2, handleMatch2),
  (r3, handleMatch3),
  ):
m = r.search(w)
if m:
  fn(m)
  break
  else: # yes, a for/else, a handy Python construct if new to you
print("No match")

which simplifies the logic considerably, avoiding the deep nesting.

-tkc



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

Re: On a scrollbar for tkinter

[Terry Reedy]

On 1/2/2014 2:52 PM, eneskri...@gmail.com wrote:


I'm new to tkinter, but I have to use it for a program for a competition. So, I 
make a RadioButton program using a while loop. So far so good, fully working. 
BUT it didn't show the full content, even after maximising the window. So, my 
question is, how do I make a scroll bar(On x and y axis) for my Main Frame. I 
can provide additional info if needed.


Have you already searched 'python tkinter scrollbar', with maybe 
'example' added? Or looked at the links given in the library manual chapter?


--
Terry Jan Reedy

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

On a scrollbar for tkinter

[eneskristo]

Hello people!
I'm new to tkinter, but I have to use it for a program for a competition. So, I 
make a RadioButton program using a while loop. So far so good, fully working. 
BUT it didn't show the full content, even after maximising the window. So, my 
question is, how do I make a scroll bar(On x and y axis) for my Main Frame. I 
can provide additional info if needed.
Notes:
Python 3.2 (Using Portable Python for a while. Outdated but meh.)
Thank you in advance!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ifs and assignments

[Gary Herron]

On 01/02/2014 09:20 AM, John Allsup wrote:

Hi,

This is my debut on this list.

In many languages, such as C, one can use assignments in conditionals 
and expressions.  The most common, and useful case turns up when you 
have if/else if/else if/else constructs. Consider the following 
non-working pseudoPython.


import re
r1 = re.compile("hello (\d)")
r2 = re.compile("world([!?])")

w = "hello world!"

if m = r1.search(w):


This kind of thing in C/C+ has always been the source of much confusion 
and potential errors, because the construct is so similar to an "==" 
test.  Python does not replicate this potential for confusion.   
Instead, we use two lines of code, an assignment and then the test.   If 
you find that extra line of code inconvenient than at least you can take 
comfort in the fact that it is clearer code.  If you are still not 
convinced, ... then sorry, that's just the way Python is.


Gary Herron



handleMatch1(m)
elif m = r2.search(w):
handleMatch2(m)
else:
print("No match")

If the regular expressions are complex, running them multiple times 
(once to test, another to capture groups) isn't ideal.  On the other 
hand, at present, one has to either do:


m = r1.search(w)
if m:
handleMatch1(m)
else:
m = r2.search(w)
if m:
handleMatch2(m)
else:
print("No match")

if not running unnecessary matches, yet capturing groups in the event 
of a successful match, is what is desired.


If there are multiple tests, the indentation gets silly.  This arises 
because having removed the ability to assign in an expression, there 
is no way to save the result of a function call that is used in a 
conditional at all.


I am aware that this facility in C is a source of bugs, = being only a 
typo away from the more common ==.  With exceptions and contexts, we 
have:


with open("file") as f:
doSomethingWith(f)

try:
trySomething()
except SomethingRandomGoingWrong as e:
lookAtException(e)

What I am wondering is why not use a similar syntax with if, so that 
one could do


if r1.search(w) as m:
g = m.groups()
print(g[1])

This would remove the risk of errors by typos since the syntax for 
equality testing (if x == y:) is completely different from that for 
assigning in a conditional (which would look like 'if y as x:'


Related would be to have Nonetype work with contexts such that

with None as x:
doStuff(x)

would do nothing.  This would allow things like:

with maybeGetSomething as x:
doStuff(x)

to call doStuff(x) within a context of maybeGetSomething returns 
something, or do nothing if nothing is returned.  (Adding an else-like
keyword to with, or possibly using else in that context, would allow 
one to process a non-None object if returned, or else do something in 
response to a None object being returned by the maybeGetSomething.)


Just a thought.

Or what is the current 'Pythonic' way to do something like:

if x = func1():
do1(x)
elif x = func2():
do2(x)
elif x = func3():
do3(x)
elif x = func4():
do4(x)
else:
do5()

where each of func1,func2,func3,func4 have side effects so that func2 
is tested if and only if func1 returns a false value, func1 must be 
called only once, and what is returned from func1 must be available to 
the code inside the if block?



John



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

Re: About some problem

[Mark Lawrence]

On 02/01/2014 17:46, Rustom Mody wrote:


Oh ok I get what you are saying: python3 will not recognize a python2
package and install it seemingly correctly but actually wrongly



No, it will install it quite correctly.  What it won't know is that some 
of the code is valid in Python 2 but invalid in Python 3.  An example I 
discovered 30 minutes ago.


raise "Not Valid DB Type"

is perfectly valid in Python 2.  In Python 3 it's so illegal the 2to3 
conversion tool can't cope with it :(


--
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: Blog "about python 3"

[Terry Reedy]

On 1/2/2014 12:36 PM, Robin Becker wrote:


I just spent a large amount of effort porting reportlab to a version
which works with both python2.7 and python3.3. I have a large number of
functions etc which handle the conversions that differ between the two
pythons.


I am imagine that this was not fun.

[For those who do not know, reportlab produces pdf documents.]


For fairly sensible reasons we changed the internal default to use
unicode rather than bytes.


Do you mean 'from __future__ import unicode_literals'?

Am I correct in thinking that this change increases the capabilities of 
reportlab? For instance, easily producing an article with abstracts in 
English, Arabic, Russian, and Chinese?


> After doing all that and making the tests

compatible etc etc I have a version which runs in both and passes all
its tests. However, for whatever reason the python 3.3 version runs slower.


Python 3 is slower in some things, like integer arithmetic with small ints.


2.7 Ran 223 tests in 66.578s

3.3 Ran 223 tests in 75.703s

I know some of these tests are fairly variable, but even for simple
things like paragraph parsing 3.3 seems to be slower. Since both use
unicode internally it can't be that can it, or is python 2.7's unicode
faster?


The new unicode implementation in 3.3 is faster for some operations and 
slower for others. It is definitely more space efficient, especially 
compared to a wide build system. It is definitely less buggy, especially 
compared to a narrow build system.


Do your tests use any astral (non-BMP) chars? If so, do they pass on 
narrow 2.7 builds (like on Windows)?



So far the superiority of 3.3 escapes me,


For one thing, indexing and slicing just works on all machines for all 
unicode strings. Code for 2.7 and 3.3 either a) does not index or slice, 
b) does not work for all text on 2.7 narrow builds, or c) has extra 
conditional code only for 2.7.


--
Terry Jan Reedy

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

Re: Ifs and assignments

[Ethan Furman]

On 01/02/2014 09:20 AM, John Allsup wrote:


In many languages, such as C, one can use assignments in conditionals
and expressions.  The most common, and useful case turns up when you
have if/else if/else if/else constructs.  Consider the following
non-working pseudoPython.

import re
r1 = re.compile("hello (\d)")
r2 = re.compile("world([!?])")

w = "hello world!"

if m = r1.search(w):
 handleMatch1(m)
elif m = r2.search(w):
 handleMatch2(m)
else:
 print("No match")


What you're looking for is a pocket function:

#untested
class assign(object):
def set(self, value):
self._assignment = value
return value
def get(self):
return self._assignment

m = assign()

if m.set(r1.search(w)):
 handleMatch1(m.get())
elif m.set(r2.search(w)):
 handleMatch2(m.get())
else:
 print("No match")

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

Re: Blog "about python 3"

[David Hutto]

Just because it's 3.3 doesn't matter...the main interest is in
compatibility. Secondly, you used just one piece of code, which could be a
fluke, try others, and check the PEP. You need to realize that evebn the
older versions are benig worked on, and they have to be refined. So if you
have a problem, use the older and import from the future would be my
suggestion



On Thu, Jan 2, 2014 at 12:36 PM, Robin Becker  wrote:

> On 31/12/2013 15:41, Roy Smith wrote:
>
>> I'm using 2.7 in production.  I realize that at some point we'll need to
>> upgrade to 3.x.  We'll keep putting that off as long as the "effort +
>> dependencies + risk" metric exceeds the "perceived added value" metric.
>>
>>  We too are using python 2.4 - 2.7 in production. Different clients
> migrate at different speeds.
>
>
>> To be honest, the "perceived added value" in 3.x is pretty low for us.
>> What we're running now works.  Switching to 3.x isn't going to increase
>> our monthly average users, or our retention rate, or decrease our COGS,
>> or increase our revenue.  There's no killer features we need.  In
>> summary, the decision to migrate will be driven more by risk aversion,
>> when the risk of staying on an obsolete, unsupported platform, exceeds
>> the risk of moving to a new one.  Or, there will be some third-party
>> module that we must have which is no longer supported on 2.x.
>>
>>
> +1
>
>  If I were starting a new project today, I would probably start it in 3.x.
>>
> +1
>
> I just spent a large amount of effort porting reportlab to a version which
> works with both python2.7 and python3.3. I have a large number of functions
> etc which handle the conversions that differ between the two pythons.
>
> For fairly sensible reasons we changed the internal default to use unicode
> rather than bytes. After doing all that and making the tests compatible etc
> etc I have a version which runs in both and passes all its tests. However,
> for whatever reason the python 3.3 version runs slower
>
> 2.7 Ran 223 tests in 66.578s
>
> 3.3 Ran 223 tests in 75.703s
>
> I know some of these tests are fairly variable, but even for simple things
> like paragraph parsing 3.3 seems to be slower. Since both use unicode
> internally it can't be that can it, or is python 2.7's unicode faster?
>
> So far the superiority of 3.3 escapes me, but I'm tasked with enjoying
> this process so I'm sure there must be some new 'feature' that will help.
> Perhaps 'yield from' or 'raise from None' or ...
>
> In any case I think we will be maintaining python 2.x code for at least
> another 5 years; the version gap is then a real hindrance.
> --
> Robin Becker
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com *
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About some problem

[David Hutto]

Looks like you have a a list of 2.7 dependencies in the path
 args.

The first you seem to have 3.3 args, and the second a longer list of 2.7
argsI would assume the second is the full list...correct?



On Thu, Jan 2, 2014 at 1:07 PM, David Hutto  wrote:

> I think, but haven't tried, and this would be 2-3  from __future__ import
>
>
> On Thu, Jan 2, 2014 at 12:46 PM, Rustom Mody wrote:
>
>> On Thu, Jan 2, 2014 at 11:06 PM, Ned Batchelder 
>> wrote:
>> > On 1/2/14 12:05 PM, Rustom Mody wrote:
>> >
>> >>
>> >> i'm not sure about this but isnt it normally the case that different
>> >> version modules dont get mixed up like that?
>> >> IOW if pytesser was a properly packaged 2.7 module would python 3 be
>> >> able to get at it ??
>> >>
>> >
>> > If you use a Python 3 installer it can succeed at installing a Python 2
>> > package. Then you won't find out until you try to run the package that
>> it is
>> > incompatible.  A mechanism to prevent this seems like a good idea, but
>> since
>> > it wasn't in place at the dawn of Python 3, it would be difficult to
>> put in
>> > place now.
>>
>> $ python3
>> Python 3.3.3 (default, Dec  8 2013, 16:34:29)
>> [GCC 4.8.2] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> from sys import path
>> >>> path
>> ['', '/usr/lib/python3.3', '/usr/lib/python3.3/plat-i386-linux-gnu',
>> '/usr/lib/python3.3/lib-dynload',
>> '/usr/local/lib/python3.3/dist-packages',
>> '/usr/lib/python3/dist-packages']
>>
>>
>> $ python
>> Python 2.7.6 (default, Dec  6 2013, 21:56:56)
>> [GCC 4.8.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> from sys import path
>> >>> path
>> ['', '/usr/local/lib/python2.7/dist-packages/pip-1.0-py2.7.egg',
>> '/usr/lib/python2.7', '/usr/lib/python2.7/plat-i386-linux-gnu',
>> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
>> '/usr/lib/python2.7/lib-dynload',
>> '/usr/local/lib/python2.7/dist-packages',
>> '/usr/lib/python2.7/dist-packages',
>> '/usr/lib/python2.7/dist-packages/PILcompat',
>> '/usr/lib/python2.7/dist-packages/gst-0.10',
>> '/usr/lib/python2.7/dist-packages/gtk-2.0',
>> '/usr/lib/pymodules/python2.7',
>> '/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode']
>>
>>
>> So as far as I can see (on a debian linux system) the paths are
>> clearly 2.7-prefixed or 3.3-prefixed.
>>
>> So apart from being stupid and/or malicious to munge sys.path to tread
>> on the other python's toes...???
>>
>> Oh ok I get what you are saying: python3 will not recognize a python2
>> package and install it seemingly correctly but actually wrongly
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
> --
> Best Regards,
> David Hutto
> *CEO:* *http://www.hitwebdevelopment.com
> *
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com *
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About some problem

[David Hutto]

and as I usually do, keep with the older stable version in order to keep up
with other packages compatibiity.



On Thu, Jan 2, 2014 at 1:07 PM, David Hutto  wrote:

> I think, but haven't tried, and this would be 2-3  from __future__ import
>
>
> On Thu, Jan 2, 2014 at 12:46 PM, Rustom Mody wrote:
>
>> On Thu, Jan 2, 2014 at 11:06 PM, Ned Batchelder 
>> wrote:
>> > On 1/2/14 12:05 PM, Rustom Mody wrote:
>> >
>> >>
>> >> i'm not sure about this but isnt it normally the case that different
>> >> version modules dont get mixed up like that?
>> >> IOW if pytesser was a properly packaged 2.7 module would python 3 be
>> >> able to get at it ??
>> >>
>> >
>> > If you use a Python 3 installer it can succeed at installing a Python 2
>> > package. Then you won't find out until you try to run the package that
>> it is
>> > incompatible.  A mechanism to prevent this seems like a good idea, but
>> since
>> > it wasn't in place at the dawn of Python 3, it would be difficult to
>> put in
>> > place now.
>>
>> $ python3
>> Python 3.3.3 (default, Dec  8 2013, 16:34:29)
>> [GCC 4.8.2] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> from sys import path
>> >>> path
>> ['', '/usr/lib/python3.3', '/usr/lib/python3.3/plat-i386-linux-gnu',
>> '/usr/lib/python3.3/lib-dynload',
>> '/usr/local/lib/python3.3/dist-packages',
>> '/usr/lib/python3/dist-packages']
>>
>>
>> $ python
>> Python 2.7.6 (default, Dec  6 2013, 21:56:56)
>> [GCC 4.8.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> from sys import path
>> >>> path
>> ['', '/usr/local/lib/python2.7/dist-packages/pip-1.0-py2.7.egg',
>> '/usr/lib/python2.7', '/usr/lib/python2.7/plat-i386-linux-gnu',
>> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
>> '/usr/lib/python2.7/lib-dynload',
>> '/usr/local/lib/python2.7/dist-packages',
>> '/usr/lib/python2.7/dist-packages',
>> '/usr/lib/python2.7/dist-packages/PILcompat',
>> '/usr/lib/python2.7/dist-packages/gst-0.10',
>> '/usr/lib/python2.7/dist-packages/gtk-2.0',
>> '/usr/lib/pymodules/python2.7',
>> '/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode']
>>
>>
>> So as far as I can see (on a debian linux system) the paths are
>> clearly 2.7-prefixed or 3.3-prefixed.
>>
>> So apart from being stupid and/or malicious to munge sys.path to tread
>> on the other python's toes...???
>>
>> Oh ok I get what you are saying: python3 will not recognize a python2
>> package and install it seemingly correctly but actually wrongly
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
> --
> Best Regards,
> David Hutto
> *CEO:* *http://www.hitwebdevelopment.com
> *
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com *
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About some problem

[David Hutto]

I think, but haven't tried, and this would be 2-3  from __future__ import


On Thu, Jan 2, 2014 at 12:46 PM, Rustom Mody  wrote:

> On Thu, Jan 2, 2014 at 11:06 PM, Ned Batchelder 
> wrote:
> > On 1/2/14 12:05 PM, Rustom Mody wrote:
> >
> >>
> >> i'm not sure about this but isnt it normally the case that different
> >> version modules dont get mixed up like that?
> >> IOW if pytesser was a properly packaged 2.7 module would python 3 be
> >> able to get at it ??
> >>
> >
> > If you use a Python 3 installer it can succeed at installing a Python 2
> > package. Then you won't find out until you try to run the package that
> it is
> > incompatible.  A mechanism to prevent this seems like a good idea, but
> since
> > it wasn't in place at the dawn of Python 3, it would be difficult to put
> in
> > place now.
>
> $ python3
> Python 3.3.3 (default, Dec  8 2013, 16:34:29)
> [GCC 4.8.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from sys import path
> >>> path
> ['', '/usr/lib/python3.3', '/usr/lib/python3.3/plat-i386-linux-gnu',
> '/usr/lib/python3.3/lib-dynload',
> '/usr/local/lib/python3.3/dist-packages',
> '/usr/lib/python3/dist-packages']
>
>
> $ python
> Python 2.7.6 (default, Dec  6 2013, 21:56:56)
> [GCC 4.8.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from sys import path
> >>> path
> ['', '/usr/local/lib/python2.7/dist-packages/pip-1.0-py2.7.egg',
> '/usr/lib/python2.7', '/usr/lib/python2.7/plat-i386-linux-gnu',
> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
> '/usr/lib/python2.7/lib-dynload',
> '/usr/local/lib/python2.7/dist-packages',
> '/usr/lib/python2.7/dist-packages',
> '/usr/lib/python2.7/dist-packages/PILcompat',
> '/usr/lib/python2.7/dist-packages/gst-0.10',
> '/usr/lib/python2.7/dist-packages/gtk-2.0',
> '/usr/lib/pymodules/python2.7',
> '/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode']
>
>
> So as far as I can see (on a debian linux system) the paths are
> clearly 2.7-prefixed or 3.3-prefixed.
>
> So apart from being stupid and/or malicious to munge sys.path to tread
> on the other python's toes...???
>
> Oh ok I get what you are saying: python3 will not recognize a python2
> package and install it seemingly correctly but actually wrongly
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com *
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About some problem

[Rustom Mody]

On Thu, Jan 2, 2014 at 11:06 PM, Ned Batchelder  wrote:
> On 1/2/14 12:05 PM, Rustom Mody wrote:
>
>>
>> i'm not sure about this but isnt it normally the case that different
>> version modules dont get mixed up like that?
>> IOW if pytesser was a properly packaged 2.7 module would python 3 be
>> able to get at it ??
>>
>
> If you use a Python 3 installer it can succeed at installing a Python 2
> package. Then you won't find out until you try to run the package that it is
> incompatible.  A mechanism to prevent this seems like a good idea, but since
> it wasn't in place at the dawn of Python 3, it would be difficult to put in
> place now.

$ python3
Python 3.3.3 (default, Dec  8 2013, 16:34:29)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sys import path
>>> path
['', '/usr/lib/python3.3', '/usr/lib/python3.3/plat-i386-linux-gnu',
'/usr/lib/python3.3/lib-dynload',
'/usr/local/lib/python3.3/dist-packages',
'/usr/lib/python3/dist-packages']


$ python
Python 2.7.6 (default, Dec  6 2013, 21:56:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sys import path
>>> path
['', '/usr/local/lib/python2.7/dist-packages/pip-1.0-py2.7.egg',
'/usr/lib/python2.7', '/usr/lib/python2.7/plat-i386-linux-gnu',
'/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/usr/local/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages/PILcompat',
'/usr/lib/python2.7/dist-packages/gst-0.10',
'/usr/lib/python2.7/dist-packages/gtk-2.0',
'/usr/lib/pymodules/python2.7',
'/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode']


So as far as I can see (on a debian linux system) the paths are
clearly 2.7-prefixed or 3.3-prefixed.

So apart from being stupid and/or malicious to munge sys.path to tread
on the other python's toes...???

Oh ok I get what you are saying: python3 will not recognize a python2
package and install it seemingly correctly but actually wrongly
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Blog "about python 3"

[Robin Becker]

On 31/12/2013 15:41, Roy Smith wrote:

I'm using 2.7 in production.  I realize that at some point we'll need to
upgrade to 3.x.  We'll keep putting that off as long as the "effort +
dependencies + risk" metric exceeds the "perceived added value" metric.

We too are using python 2.4 - 2.7 in production. Different clients migrate at 
different speeds.




To be honest, the "perceived added value" in 3.x is pretty low for us.
What we're running now works.  Switching to 3.x isn't going to increase
our monthly average users, or our retention rate, or decrease our COGS,
or increase our revenue.  There's no killer features we need.  In
summary, the decision to migrate will be driven more by risk aversion,
when the risk of staying on an obsolete, unsupported platform, exceeds
the risk of moving to a new one.  Or, there will be some third-party
module that we must have which is no longer supported on 2.x.



+1


If I were starting a new project today, I would probably start it in 3.x.

+1

I just spent a large amount of effort porting reportlab to a version which works 
with both python2.7 and python3.3. I have a large number of functions etc which 
handle the conversions that differ between the two pythons.


For fairly sensible reasons we changed the internal default to use unicode 
rather than bytes. After doing all that and making the tests compatible etc etc 
I have a version which runs in both and passes all its tests. However, for 
whatever reason the python 3.3 version runs slower


2.7 Ran 223 tests in 66.578s

3.3 Ran 223 tests in 75.703s

I know some of these tests are fairly variable, but even for simple things like 
paragraph parsing 3.3 seems to be slower. Since both use unicode internally it 
can't be that can it, or is python 2.7's unicode faster?


So far the superiority of 3.3 escapes me, but I'm tasked with enjoying this 
process so I'm sure there must be some new 'feature' that will help. Perhaps 
'yield from' or 'raise from None' or ...


In any case I think we will be maintaining python 2.x code for at least another 
5 years; the version gap is then a real hindrance.

--
Robin Becker

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

Re: About some problem

[Ned Batchelder]

On 1/2/14 12:05 PM, Rustom Mody wrote:



i'm not sure about this but isnt it normally the case that different
version modules dont get mixed up like that?
IOW if pytesser was a properly packaged 2.7 module would python 3 be
able to get at it ??



If you use a Python 3 installer it can succeed at installing a Python 2 
package. Then you won't find out until you try to run the package that 
it is incompatible.  A mechanism to prevent this seems like a good idea, 
but since it wasn't in place at the dawn of Python 3, it would be 
difficult to put in place now.


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

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

Argparse class method based instantiation

[Joseph L. Casale]

I have an Python3 argparse implementation that is invoked as a method from an 
imported
class within a users script __main__.

When argparse is setup in __main__ instead, all the help switches produce help 
then exit.
When a help switch is passed based on the above implementation, they are 
ignored?

Anyone seen this and or know of a workaround?

Thanks,
jlc

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

Ifs and assignments

[John Allsup]

Hi,

This is my debut on this list.

In many languages, such as C, one can use assignments in conditionals 
and expressions.  The most common, and useful case turns up when you 
have if/else if/else if/else constructs.  Consider the following 
non-working pseudoPython.


import re
r1 = re.compile("hello (\d)")
r2 = re.compile("world([!?])")

w = "hello world!"

if m = r1.search(w):
handleMatch1(m)
elif m = r2.search(w):
handleMatch2(m)
else:
print("No match")

If the regular expressions are complex, running them multiple times 
(once to test, another to capture groups) isn't ideal.  On the other 
hand, at present, one has to either do:


m = r1.search(w)
if m:
handleMatch1(m)
else:
m = r2.search(w)
if m:
handleMatch2(m)
else:
print("No match")

if not running unnecessary matches, yet capturing groups in the event of 
a successful match, is what is desired.


If there are multiple tests, the indentation gets silly.  This arises 
because having removed the ability to assign in an expression, there is 
no way to save the result of a function call that is used in a 
conditional at all.


I am aware that this facility in C is a source of bugs, = being only a 
typo away from the more common ==.  With exceptions and contexts, we have:


with open("file") as f:
doSomethingWith(f)

try:
trySomething()
except SomethingRandomGoingWrong as e:
lookAtException(e)

What I am wondering is why not use a similar syntax with if, so that one 
could do


if r1.search(w) as m:
g = m.groups()
print(g[1])

This would remove the risk of errors by typos since the syntax for 
equality testing (if x == y:) is completely different from that for 
assigning in a conditional (which would look like 'if y as x:'


Related would be to have Nonetype work with contexts such that

with None as x:
doStuff(x)

would do nothing.  This would allow things like:

with maybeGetSomething as x:
doStuff(x)

to call doStuff(x) within a context of maybeGetSomething returns 
something, or do nothing if nothing is returned.  (Adding an else-like
keyword to with, or possibly using else in that context, would allow one 
to process a non-None object if returned, or else do something in 
response to a None object being returned by the maybeGetSomething.)


Just a thought.

Or what is the current 'Pythonic' way to do something like:

if x = func1():
do1(x)
elif x = func2():
do2(x)
elif x = func3():
do3(x)
elif x = func4():
do4(x)
else:
do5()

where each of func1,func2,func3,func4 have side effects so that func2 is 
tested if and only if func1 returns a false value, func1 must be called 
only once, and what is returned from func1 must be available to the code 
inside the if block?



John

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

looking for a quote on age and technology

[Rustom Mody]

On Thu, Jan 2, 2014 at 11:22 AM, Ben Finney wrote:
> I think you're referring to an article by the late, great Douglas Adams,
> “How to Stop Worrying and Learn to Love the Internet”:

Thanks Ben -- Yes thats the one I was looking for!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About some problem

[Mark Lawrence]

On 02/01/2014 16:53, Joel Goldstick wrote:




On Thu, Jan 2, 2014 at 11:31 AM, raj kumar mailto:rajkumar84...@gmail.com>> wrote:

Hello, I am beginner to python and i am writing following code

from pytesser import *

and i am getting an error as follow

Traceback (most recent call last):
   File "", line 1, in 
   File "C:\Python33\lib\site-packages\pytesser.py", line 61
 print text
  ^
SyntaxError: invalid syntax


How to resolve it ? Give me all steps to resolve it.


"Please" goes a long way.



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

First, you should give version and os when you ask a question.  However
it is clear you are using python 3.3 and Windows.

Your print statement implies that pytesser.py is written in the 2.x
dialect of python.  In version 3.x print became a function and requires
parenthesis around the arguments.

So, you need to find a version of pytesser.py that is compatible with
python 3, or if you can't do that, and you need pytesser.py, you have to
install python 2.7



What's wrong with making a compatible version using this command?

2to3 -w pytesser.py

--
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: About some problem

[Rustom Mody]

On Thu, Jan 2, 2014 at 10:23 PM, Joel Goldstick
 wrote:
>
>
>
> On Thu, Jan 2, 2014 at 11:31 AM, raj kumar  wrote:
>>
>> Hello, I am beginner to python and i am writing following code
>>
>> from pytesser import *
>>
>> and i am getting an error as follow
>>
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "C:\Python33\lib\site-packages\pytesser.py", line 61
>> print text
>>  ^
>> SyntaxError: invalid syntax
>>
>>
>> How to resolve it ? Give me all steps to resolve it.
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
> First, you should give version and os when you ask a question.  However it
> is clear you are using python 3.3 and Windows.
>
> Your print statement implies that pytesser.py is written in the 2.x dialect
> of python.  In version 3.x print became a function and requires parenthesis
> around the arguments.
>
> So, you need to find a version of pytesser.py that is compatible with python
> 3, or if you can't do that, and you need pytesser.py, you have to install
> python 2.7
>
> Also, this is usually a bad idea:
>
> from pytesser import *
>
> Probably better not to muddle the namespace with a chance of naming
> collisions and do:
>
>   import pytesser
>
>
> Good luck.  Come back after you've had a go with those ideas

i'm not sure about this but isnt it normally the case that different
version modules dont get mixed up like that?
IOW if pytesser was a properly packaged 2.7 module would python 3 be
able to get at it ??
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 2.x and 3.x usage survey

[Grant Edwards]

On 2013-12-31, Steven D'Aprano  wrote:
> Mark Lawrence wrote:
>
>> On 30/12/2013 21:56, Dan Stromberg wrote:
>>> I keep hearing naysayers, nay saying about Python 3.x.
>>>
>>> Here's a 9 question, multiple choice survey I put together about
>>> Python 2.x use vs Python 3.x use.
>>>
>>> I'd be very pleased if you could take 5 or 10 minutes to fill it out.
>>>
>>> Here's the URL:
>>> https://www.surveymonkey.com/s/N5N5PG2
>>>
>> 
>> People using 1.x will be miffed as their baby has been missed out :)
>
> You laugh, but there was at least one attendee at the last PyCon who was
> still using 1.5 professionally. Software never quite dies so long as there
> is hardware capable of running it.

ITYM: ... so long as there is hardware capable of running an emulator
that is capable of running it.

-- 
Grant Edwards   grant.b.edwardsYow! I don't understand
  at   the HUMOUR of the THREE
  gmail.comSTOOGES!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About some problem

[Joel Goldstick]

On Thu, Jan 2, 2014 at 11:31 AM, raj kumar  wrote:

> Hello, I am beginner to python and i am writing following code
>
> from pytesser import *
>
> and i am getting an error as follow
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\Python33\lib\site-packages\pytesser.py", line 61
> print text
>  ^
> SyntaxError: invalid syntax
>
>
> How to resolve it ? Give me all steps to resolve it.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
> First, you should give version and os when you ask a question.  However it
is clear you are using python 3.3 and Windows.

Your print statement implies that pytesser.py is written in the 2.x dialect
of python.  In version 3.x print became a function and requires parenthesis
around the arguments.

So, you need to find a version of pytesser.py that is compatible with
python 3, or if you can't do that, and you need pytesser.py, you have to
install python 2.7

Also, this is usually a bad idea:

from pytesser import *

Probably better not to muddle the namespace with a chance of naming
collisions and do:

  import pytesser


Good luck.  Come back after you've had a go with those ideas

-- 
Joel Goldstick
http://joelgoldstick.com
-- 
https://mail.python.org/mailman/listinfo/python-list

About some problem

[raj kumar]

Hello, I am beginner to python and i am writing following code

from pytesser import *

and i am getting an error as follow

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python33\lib\site-packages\pytesser.py", line 61
print text
 ^
SyntaxError: invalid syntax


How to resolve it ? Give me all steps to resolve it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: So, what's the real story on Python 2 vs Python 3?

[Grant Edwards]

On 2013-12-27, Andrew Berg  wrote:
> On 2013.12.26 23:04, Travis McGee wrote:
>> The Python.org site says that the future is Python 3, yet whenever I try 
>> something new in Python, such as Tkinter which I am learning now, 
>> everything seems to default to Python 2. By this I mean that, whenever I 
>> find that I need to install another package, it shows up as Python 2 
>> unless I explicitly specify Python 3.
>> 
>> What's the deal? If I want to make a distributable software package, 
>> should it be 2 or 3? Enquiring minds want to know.
>
> Oh boy, another 2 vs. 3 thread!
>
> Always use 3 unless you absolutely have to use 2. Python 3 is not a
> shiny new thing. It is *five* years old at this point



While Python 3 may not be shiney and new, the Python 3 support in some
third-party packages and libraries is still shiney and new at best,
and missing at worst.  The situation is improving steadily, and while
I do try to write new code work with both 2.7 and 3.x, I still use 2.7
for my day-to-day work.

-- 
Grant Edwards   grant.b.edwardsYow! Of course, you
  at   UNDERSTAND about the PLAIDS
  gmail.comin the SPIN CYCLE --
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: So, what's the real story on Python 2 vs Python 3?

[Grant Edwards]

On 2013-12-27, Travis McGee  wrote:

> The Python.org site says that the future is Python 3, yet whenever I
> try something new in Python, such as Tkinter which I am learning now,
> everything seems to default to Python 2. By this I mean that,
> whenever I find that I need to install another package, it shows up
> as Python 2 unless I explicitly specify Python 3.

That's a function of whatever you're using to "install another package".

I can tell you how to configure Gentoo Linux so that portage/emerge 
always installs Python packages for Python 3, Python 2, or both.

> What's the deal? If I want to make a distributable software package, 
> should it be 2 or 3?

Both. :)

-- 
Grant Edwards   grant.b.edwardsYow! This ASEXUAL PIG
  at   really BOILS my BLOOD
  gmail.com... He's so ... so
   ... URGENT!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: need to print seconds from the epoch including the millisecond

[Grant Edwards]

On 2013-12-26, Steven D'Aprano  wrote:
> matt.doolittl...@gmail.com wrote:
>
>> On Thursday, December 26, 2013 2:22:10 PM UTC-5, Dan Stromberg wrote:
>>> On Thu, Dec 26, 2013 at 10:32 AM,   wrote:
>>> 
>>> > i am using 2.7.   I need to print the time in seconds from the epoch
>>> > with millisecond precision.  i have tried many things but have failed. 
> [...]
>>> In [1]: import time
>>> In [2]: time.time()
>>> Out[2]: 1388085670.1567955
>>
>> 
>> OK i did what you said but I am only getting 2 decimal places.
>> Why is this and what can I do to get the millisecond?
>
> Please show *exactly* what you did. Also please tell us what operating
> system you are using. It may be that your operating system's clock doesn't
> provide millisecond precision.

AFAIK, that's irrelevent.  time.time() returns a float.  On all the
CPython implementations I know of, that is a 64-bit IEEE format, which
provides 16 decimal digits of precision regardless of the granularity
of the system time value.  At this point in time, that means 10 digits
left of the decimal point and 6 to the right.

-- 
Grant Edwards   grant.b.edwardsYow! Will the third world
  at   war keep "Bosom Buddies"
  gmail.comoff the air?
-- 
https://mail.python.org/mailman/listinfo/python-list

python finance

[d ss]

dailystockselect.com needs a couple of talented python people for the 
development and implementation of new trading strategies.
it may be also some pythonic design change for the displayed figures
now the web app consists of 1 of the 8 conceived strategies.
contact us at the email on the website for more details
Samir
-- 
https://mail.python.org/mailman/listinfo/python-list

editing video using python

[Alok Singh Mahor]

Hello everyone,
I want to join 2 or 3 video and want to add effect of fading in and out.
I also want to add text strip on the video.

I am not able to decide what to adopt for doing this task.
I have option of MLT ( http://www.mltframework.org/bin/view/MLT/WebHome )
but I guess its too complex and I didnt find any documentation of MLT

I have another option of FFmpeg, but I am not sure whether I can do all
three requirement with ffmpeg. if I adopt ffmpeg then should I use ffmpeg's
wrapper for python like http://code.google.com/p/pyffmpeg/ or I should use
pure ffmpeg in python as subprocess?

how is pymedia? can I do my task with pymedia?

please tell me easy way to do my task in python.
Thank you
-- 
https://mail.python.org/mailman/listinfo/python-list