date:20130328

On Wed, 27 Mar 2013 22:42:18 -0700, rusi wrote:


 More seriously Ive never seen anyone -- cause or person -- aided by
 the use of excessively strong language.

Of course not. By definition, if it helps, it wasn't *excessively* strong 
language.


 IOW I repeat my support for Ned's request: Ad hominiem attacks are not
 welcome, irrespective of the context/provocation.

Insults are not ad hominem attacks.

You sir, are a bounder and a cad. Furthermore, your 
argument is wrong, because of reasons.

may very well be an insult, but it also may be correct, and the reasons 
logically valid.

Your argument is wrong, because you are a bounder 
and a cad.

is an ad hominem fallacy, because even bounders and cads may tell the 
truth occasionally, or be correct by accident.

I find it interesting that nobody has yet felt the need to defend JMF, 
and tell me I was factually incorrect about him (as opposed to merely 
impolite or mean-spirited).

In any case, I don't want this to be specifically about any one person, 
so let's move away from JMF. I disagree that hostile language is *always* 
inappropriate, although I agree that it is *usually* inappropriate.

Although even that depends on what you define as hostile -- I would 
much prefer that people confronted me for being (supposedly) dishonest 
than silently shunning me without giving me any way to respond or correct 
either my behaviour or their (mis)apprehensions. Quite frankly, I think 
that the passive-aggressive silent treatment (kill-filing) is MUCH more 
hostile and mean-spirited[1] than honest, respectful, direct criticism, 
even when that criticism is about character (you sir are a lying 
scoundrel).

I treat people the way I hope to be treated. As galling as it would be to 
be accused of lying, I would rather that you called me a liar to my face 
and gave me the opportunity to respond, than for you to ignore everything 
I said.

I hope that we all agree that we want a nice, friendly, productive 
community where everyone is welcome. But some people simply cannot or 
will not behave in ways that are compatible with those community values. 
There are some people whom we *do not want here* -- spoilers and messers, 
vandals and spammers and cheats and liars and trolls and crackpots of all 
sorts. We only disagree as to the best way to make it clear to them that 
they are not welcome so long as they continue their behaviour.



[1] Although sadly, given the reality of communication on the Internet, 
sometimes kill-filing is the least-worst option.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 07:12, Ethan Furman et...@stoneleaf.us wrote:
 On 03/27/2013 08:49 PM, rusi wrote:

  In particular You are a liar is as bad as You are an idiot
  The same statement can be made non-abusively thus: ... is not true
  because ...

 I don't agree.  With all the posts and micro benchmarks and other drivel that 
 jmf has inflicted on us, I find it /very/
 hard to believe that he forgot -- which means he was deliberately lying.

 At some point we have to stop being gentle / polite / politically correct and 
 call a shovel a shovel... er, spade.

 --
 ~Ethan~

---

The problem is elsewhere. Nobody understand the examples
I gave on this list, because nobody understand Unicode.
These examples are not random examples, they are well
thought.

If you were understanding the coding of the characters,
Unicode and what this flexible representation does, it
would not be a problem for you to create analog examples.

So, we are turning into circles.

This flexible representation succeeds to cumulate in one
shoot all the design mistakes it is possible to do, when
one wishes to implements Unicode.

Example of a good Unicode understanding.
If you wish 1) to preserve memory, 2) to cover the whole range
of Unicode, 3) to keep maximum performance while preserving the
good work Unicode.org as done (normalization, sorting), there
is only one solution: utf-8. For this you have to understand,
what is really a unicode transformation format.

Why all the actors, active in the text field, like MicroSoft,
Apple, Adobe, the unicode compliant TeX engines, the foundries,
the organisation in charge of the OpenType font specifications,
are able to handle all this stuff correctly (understanding +
implementation) and Python not?, I should say this is going
beyond my understanding.

Python has certainly and definitvely not revolutionize
Unicode.

jmf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Ian Foote


On 28/03/13 09:03, jmfauth wrote:

The problem is elsewhere. Nobody understand the examples
I gave on this list, because nobody understand Unicode.
These examples are not random examples, they are well
thought.

If you were understanding the coding of the characters,
Unicode and what this flexible representation does, it
would not be a problem for you to create analog examples.

So, we are turning into circles.

This flexible representation succeeds to cumulate in one
shoot all the design mistakes it is possible to do, when
one wishes to implements Unicode.

Example of a good Unicode understanding.
If you wish 1) to preserve memory, 2) to cover the whole range
of Unicode, 3) to keep maximum performance while preserving the
good work Unicode.org as done (normalization, sorting), there
is only one solution: utf-8. For this you have to understand,
what is really a unicode transformation format.

Why all the actors, active in the text field, like MicroSoft,
Apple, Adobe, the unicode compliant TeX engines, the foundries,
the organisation in charge of the OpenType font specifications,
are able to handle all this stuff correctly (understanding +
implementation) and Python not?, I should say this is going
beyond my understanding.

Python has certainly and definitvely not revolutionize
Unicode.

jmf



You're confusing python's choice of internal string representation with 
the programmer's choice of encoding for communicating with other programs.


I think most people agree that utf-8 is usually the best encoding to use 
for interoperating with other unicode aware software, but as a 
variable-length encoding it has disadvantages that make it unsuitable 
for use as an internal representation.


Specifically, indexing a variable-length encoding like utf-8 is not as 
efficient as indexing a fixed-length encoding.


Regards,
Ian F
--
http://mail.python.org/mailman/listinfo/python-list

Re: Altering 2 statements from Python 2.6 = 3.2

I'am just tryign to print the date with proper greek letters as it uses to work 
with Python v2.6 

date gets calculated here: 

date = ( datetime.utcnow() + timedelta(hours=2) ).strftime( '%y-%m-%d %H:%M:%S' 
) 

I'am not sure but i believe that the decode must be taken out in python 3.x 
because objexts returned in unicoide now, but i'am not sure. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Oscar Benjamin

On 28 March 2013 09:03, jmfauth wxjmfa...@gmail.com wrote:

 The problem is elsewhere. Nobody understand the examples
 I gave on this list, because nobody understand Unicode.
 These examples are not random examples, they are well
 thought.

There are many people here and among the Python devs who understand
unicode. Similarly they have understood the examples that you have
given. It has been accepted that there are a handful of cases where
performance has been reduced as a result of the change. There are also
many cases where the performance has improved. It is certainly not
clear that there is an *overall* performance reduction for people
using non latin-1 characters as you have often suggested.

The reason your initial posts received a poor reception is that they
were accompanied with pointless rants and arrogant claims that no one
understood the problem. Had you simply reported the timing differences
without the rants then I imagine that you would have received a
response like Okay, there might be a few regressions. Can you open an
issue on the tracker please?.

Since then you have been relentlessly hijacking unrelated threads and
this is clearly just trolling.


 If you were understanding the coding of the characters,
 Unicode and what this flexible representation does, it
 would not be a problem for you to create analog examples.

 So, we are turning into circles.

 This flexible representation succeeds to cumulate in one
 shoot all the design mistakes it is possible to do, when
 one wishes to implements Unicode.

This is clearly untrue.The most significant design mistakes are the
ones that lead to incorrect handling of unicode characters. This new
implementation in Python 3.3 has been designed in a way that makes it
possible to handle all unicode characters correctly.


 Example of a good Unicode understanding.
 If you wish 1) to preserve memory, 2) to cover the whole range
 of Unicode, 3) to keep maximum performance while preserving the
 good work Unicode.org as done (normalization, sorting), there
 is only one solution: utf-8. For this you have to understand,
 what is really a unicode transformation format.

Again you pretend that others here don't understand. Most people here
are well aware of utf-8 is. Your suggestion that maximum performance
would be achieved if Python use utf-8 internally ignores the fact that
it would have many negative performance implications for slicing and
indexing and so on.


 Why all the actors, active in the text field, like MicroSoft,
 Apple, Adobe, the unicode compliant TeX engines, the foundries,
 the organisation in charge of the OpenType font specifications,
 are able to handle all this stuff correctly (understanding +
 implementation) and Python not?, I should say this is going
 beyond my understanding.

 Python has certainly and definitvely not revolutionize
 Unicode.

Perhaps not, but it does now correctly handle all unicode characters
(unlike many other languages and pieces of software).


Oscar
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cannot run a single MySQLdb execute....

Can someone else esxcept Chris help me please?

I'm strugling with this and cannot see whats wrong.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Thu, Mar 28, 2013 at 4:20 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 On Wed, 27 Mar 2013 20:49:20 -0700, rusi wrote:

 In particular You are a liar is as bad as You are an idiot The same
 statement can be made non-abusively thus: ... is not true because ...

 I accept that criticism, even if I disagree with it. Does that make
 sense? I mean it in the sense that I accept that your opinion differs
 from mine.

 Politeness does not always trump honesty, and stating that somebody's
 statement is not true because... is not the same as stating that they
 are deliberately telling lies (rather than merely being mistaken or
 confused).

There comes a time when a bit of rudeness is a small cost to pay for
forum maintenance. Before you criticize someone for nit-picking, think
what happens when someone reads the thread archive. Of course, that
particular example can be done courteously too - cf the def vs
class nit from a recent thread. But it'd still be of value even if
done rudely, so the hundreds of subsequent readers would have a chance
to know what's going on. I was researching a problem with ALSA a
couple of weeks ago, and came across a forum thread that discussed
exactly what I needed to know. A dozen or so courteous posts delivered
misinformation; finally someone had the guts to be rude and call
people out for posting incorrect points (and got criticized for doing
so), and that one post was the most useful in the whole thread.

I'd rather this list have some vinegar than it devolve into
uselessness. Or, worse, if there's a hard-and-fast rule about
courtesy, devolve into aspartame... everyone's courteous in words but
hates each other underneath. Or am I taking the analogy too far? :)

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Thu, Mar 28, 2013 at 8:03 PM, jmfauth wxjmfa...@gmail.com wrote:
 Example of a good Unicode understanding.
 If you wish 1) to preserve memory, 2) to cover the whole range
 of Unicode, 3) to keep maximum performance while preserving the
 good work Unicode.org as done (normalization, sorting), there
 is only one solution: utf-8. For this you have to understand,
 what is really a unicode transformation format.

You really REALLY need to sort out in your head the difference between
correctness and performance. I still haven't seen one single piece of
evidence from you that Python 3.3 fails on any point of Unicode
correctness. Covering the whole range of Unicode has never been a
problem.

In terms of memory usage and performance, though, there's one obvious
solution. Fork CPython 3.3 (or the current branch head[1]), change the
internal representation of a string to be UTF-8 (by the way, that's
the official spelling), and run the string benchmarks. Then post your
code and benchmark figures so other people can replicate your results.

 Python has certainly and definitvely not revolutionize
 Unicode.

This is one place where you're actually correct, though, because PEP
393 isn't the first instance of this kind of format - Pike's had it
for years. Funny though, I don't think that was your point :)

[1] Apologies if my terminology is wrong, I'm a git user and did one
quick Google search to see if hg uses the same term.

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

Re: Help me pick an API design (OO vs functional)

2013-03-28 Thread Michael Herrmann

On Wednesday, March 27, 2013 2:56:55 PM UTC+1, Mitya Sirenef wrote:
 ...
 
 I think alt-tab has to be special in any case. Regular alt-tab would act
 like the GOTO statement. As a programmer looking at a script you have no
 idea where you just alt-tabbed to without possibly looking through
 dozens of lines of previous code.
 
 Keypresses that start a new window also seem pretty special to me.
 They're inherently special. After all, the essential function of a
 windowing system is when a new window is created, which means subsequent
 operations have an entirely different meaning, in a text editor del
 key will delete a character, in a file manager del key will delete a
 file!
 
 But, as I mentioned, if you can get away with treating simple dialogs
 implicitly (and I don't see why you can't, at this point), that'd be the
 preferred way for me.

Ok. Thank you for your inputs!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help me pick an API design (OO vs functional)

2013-03-28 Thread Michael Herrmann

On Wednesday, March 27, 2013 5:45:49 PM UTC+1, Ethan Furman wrote:
 On 03/27/2013 02:34 AM, Michael Herrmann wrote:
  Design #2:
   notepad_1 = start(Notepad)
   notepad_2 = start(Notepad)
   switch_to(notepad_1)
   write(Hello World!)
   press(CTRL + 'a', CTRL + 'c')
   switch_to(notepad_2)
   press(CTRL + 'v')
 ...
 
 Go with #2.  Not everything has to be a method.  len(), for example, is not a 
 method, even though it calls one.

That's a good point. I actually think #2 is the one we'll use.
-- 
http://mail.python.org/mailman/listinfo/python-list

Curl and python httplib?

2013-03-28 Thread ??????PHP

Guys,

I take a project that need send request to Hadoop by curl.
But now, the curl and pycurl can't satisfy my project. So i need use the 
powerful httplib.
But failed.


my curl request:
curl -i -X PUT http://localhost:50070/webhdfs/v1/levi/7?op=CREATE;


my return:
HTTP/1.1 307 TEMPORARY_REDIRECT
Content-Type: application/octet-stream
Location: http://58.53.211.47:50075/webhdfs/v1/levi/7?op=CREATEoverwrite=false
Content-Length: 0
Server: Jetty(6.1.26)



Now, i change the curl request to httplib:
import httplib
import urllib


params=urllib.urlencode({@op:CREATE,@user.name:levi})
headers={Content-type: application/x-www-form-urlencoded,Accept: 
text/plain}
conn=httplib.HTTPConnection(localhost:50070)
conn.request(PUT,/webhdfs/v1/levi/7.txt,params,headers)
response=conn.getresponse()
print response.status, response.reason
data=response.read()

print data
conn.close()


But it failed:
#print response.status, response.reason
500 Internal Server Error
#print data
'{RemoteException:{exception:WebApplicationException,javaClassName:javax.ws.rs.WebApplicationException,message:null}}'


Who knows why? It's OK when i use curl, so where is the problem in httplib 
method?
Or some other reasons?
Who can help me change the curl request to httplib edition?


TIA
Levi-- 
http://mail.python.org/mailman/listinfo/python-list

PyCon Australia 2013 Early Bird registration and Accommodation deals now available!

2013-03-28 Thread Chris Neugebauer

tl;dr: PyCon Australia early bird registrations are now open! Find out
more at http://2013.pycon-au.org/register/prices, including details of
our accommodation programme.

**

PyCon Australia is excited to announce that early bird conference
registrations are now available for our 2013 conference, to be held on
Saturday 6 and Sunday 6 July in Hobart, Tasmania. Early bird
registration will be extended to the first 80 confirmed conference
registrations, or until Friday 3 May, whichever comes first.

PyCon Australia is the national conference for students, enthusiasts
and professionals working with the Python programming language; it
represents a unique opportunity for Python developers to meet fellow
developers, and gain knowledge from experts and core Python developers
from around Australia and the world. Securing your registration during
the early bird period ensures your place at all of the events that
PyCon Australia has to offer.

Early bird registration comes with a substantial discount for tickets
at our Enthusiast and Professional rates. Early bird tickets at
both the Enthusiast and Professional level are guaranteed a seat
at our conference dinner. All tickets include access to the CodeWars
event on Friday 5 July, and the post-conference sprints on Monday 8
and Tuesday 9 July.

Early bird registration starts at $44 for full-time students; $168 for
enthusiasts and $420 for professionals.

This year's conference also features two single-day miniconfs, being
held on Friday 5 July: DjangoCon AU, the first national gathering of
Australian Django developers; and the Python on OpenStack Day. Entry
to these miniconfs is free for professional delegates, and $44 for
students and enthusiasts.

PyCon Australia has been working closely with our venue to provide a
great conference experience; we're very pleased to be able to offer
accommodation to delegates for the duration of the conference. We've
secured an allocation of rooms within the Wrest Point complex. Rooms
available to delegates start at $135 per night; rooms with wired
internet access start at $157 per night.

Information on conference registration, including details on how to
book delegate accommodation through our preferred provider can be
found at the PyCon Australia website (http://2013.pycon-au.org).

Our conference Call for Proposals is still open, and will close on
Friday 5 April.

We can't wait to see you in Hobart in July!

=== About PyCon Australia ===

PyCon Australia is the national conference for the Python Programming
Community. The fourth PyCon Australia will be held on July 5--7, 2013
in Hobart, Tasmania, bringing together professional, student and
enthusiast developers with a love for developing with Python. PyCon
Australia informs the country’s Python developers with presentations,
tutorials and panel sessions by experts and core developers of Python,
as well as the libraries and frameworks that they rely on.

To find out more about PyCon Australia 2013, visit our website at
http://pycon-au.org or e-mail us at cont...@pycon-au.org.

PyCon Australia is presented by Linux Australia (www.linux.org.au) and
acknowledges the support of our Platinum sponsor: Australian Computer
Society (Tasmanian Branch) (www.acs.org.au); and our Gold Sponsor,
Google Australia (www.google.com.au). For full details of our
sponsors, see our website.

-- 
--
--Christopher Neugebauer
Conference Coordinator and Sponsor Liaison

PyCon Australia: Hobart 2013 -- http://pycon-au.org -- @pyconau
5–7 July 2013; CFP now open: closes 5 April -- http://pycon-au.org/cfp

Jabber: chris...@gmail.com -- IRC: chrisjrn on irc.freenode.net --
WWW: http://chris.neugebauer.id.au -- Twitter/Identi.ca: @chrisjrn
-- 
http://mail.python.org/mailman/listinfo/python-list

Need admin right to install wxPython2.8.win64-unicode-2.8.12.1-py27.exe in Win7

2013-03-28 Thread xiaojun.zhong

Hi,



When I using standard user account to install 
wxPython2.8-win64-unicode-2.8.12.1-py27.exe in Win7, it prompt me must be 
logged in as an admin when installing. Is there any solution to install 
wxPython without admin right?



Thanks,

Scott


This email was sent to you by Thomson Reuters, the global news and information 
company. Any views expressed in this message are those of the individual 
sender, except where the sender specifically states them to be the views of 
Thomson Reuters.-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help me pick an API design (OO vs functional)

2013-03-28 Thread Michael Herrmann

On Thursday, March 28, 2013 1:42:35 AM UTC+1, Steven D'Aprano wrote:
 On Wed, 27 Mar 2013 02:34:09 -0700, Michael Herrmann wrote:
 
  On Tuesday, March 26, 2013 11:37:23 PM UTC+1, Steven D'Aprano wrote:
  
  Global *variables* are bad, not global functions. You have one global
  variable, the current window. So long as your API makes it obvious
  when the current window changes, implicitly operating on the current
  window is no more dangerous than Python's implicit operations on the
  current namespace (e.g. x = 2 binds 2 to x in the current namespace).
 
  I'm generally wary of everything global, but you're right as long as no
  (global) state is involved.
 
 That comment surprises me. Your preferred API:
 
 switch_to(notepad)
 write(Hello World!)
 press(CTRL + 'a', CTRL + 'c')
 
 uses implied global state (the current window). Even if you avoid the use 
 of an actual global for (say) an instance attribute, it's still 
 semantically a global. Surely you realise that?

I do :-) You made the statement that global variables are bad, not global 
functions. I didn't want to agree completely with this comment, because if a 
global function refers to a global variable, I would consider it bad too. You 
correctly point out that our global functions would be exactly of that bad 
kind. Of course, it doesn't make sense to be too dogmatic about bad, which is 
why I am considering the global functions as an option, for advantages they 
have despite being bad.

 Not trying to be argumentative, I'm just surprised at your comment.

No offense taken :) I guess I just wasn't expressing myself clearly.

  ...
  After everybody's input, I think Design #2 or Design #4 would be the
  best fit for us:
  
  Design #2:
  notepad_1 = start(Notepad)
  notepad_2 = start(Notepad)
  switch_to(notepad_1)
  write(Hello World!)
  press(CTRL + 'a', CTRL + 'c')
  switch_to(notepad_2)
  press(CTRL + 'v')
 
 This is nice syntax for trivial cases and beginners whose needs are not 
 demanding, but annoying for experts who have more complicated 
 requirements. If this is the only API, experts who need to simultaneously 
 operate in two windows will be forced to write unproductive boilerplate 
 code that does nothing but jump from window to window.
 
 
 Well what do you know, even in the simple case above, you have 
 unproductive code that does nothing but jump from window to window :-)
 
 I'm not against this API, I'm just against it as the *only* API.
 
  Design #4:
  notepad_1 = start(Notepad)
  notepad_2 = start(Notepad)
  notepad_1.activate()
  write(Hello World!)
  press(CTRL + 'a', CTRL + 'c')
  notepad_2.activate()
  press(CTRL + 'v')
 
 This is actually no different from #2 above, except that it uses method 
 call syntax while #2 uses function call syntax. So it has the same 
 limitations as above: it's simple for simple uses, but annoying for 
 complex use.
 
 Neither API supports advanced users with complicated needs. A hybrid 
 approach, where you have function call syntax that operates on the 
 implicit current window, plus method call syntax that operates on any 
 window, strikes me as the best of both worlds. With a little forethought 
 in your implementation, you don't have to duplicate code. E.g. something 
 like this:
 
 class WindowOps:
 def __init__(self, theWindow=None):
 self.theWindow = None
 
 def press(self, c):
 win = self.getWindow()
 send_keypress_to(win)
 
 def getWindow(self):
 if self.theWindow is None:
 return gTheTopWindow
 return self.theWindow
 
 _implicit = WindowOps(None)
 press = _implicit.press
 # etc.
 del _implicit
 
 This gives you the best of both worlds, for free: a simple API using an 
 implicit top window for simple cases, and a slightly more complex API 
 with an explicit window for advanced users.

I understand completely where you are coming from, however if we offer two ways 
of doing the same thing, people will start mixing the styles and things will 
get messy. A user commented above that this approach - offering global as well 
as object oriented functions to do the same thing - is offered by matplotlib 
and makes examples on the net very confusing and difficult to read. For this 
reason, I would rather only offer one way of doing things now, and add 
additional ways later in case they are really needed. You are right that this 
may not cater for experts' needs very well, but I think I prefer a smaller API 
that can be extended to one that may result in being difficult to read.

  Normally, I'd go for Design #4, as it results in one less global,
 
 I don't see how this is possible. Both APIs use an implicit top window. 
 What's the one less global you are referring to?

By global I meant function name.

  is
  better for autocompletion etc. The thing with our library is that it
  tries to make its scripts as similar as

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Neil Hodgson


Ian Foote:


Specifically, indexing a variable-length encoding like utf-8 is not as
efficient as indexing a fixed-length encoding.


   Many common string operations do not require indexing by character 
which reduces the impact of this inefficiency. UTF-8 seems like a 
reasonable choice for an internal representation to me. One benefit of 
UTF-8 over Python's flexible representation is that it is, on average, 
more compact over a wide set of samples.


   Neil
--
http://mail.python.org/mailman/listinfo/python-list

Differentiation in Python

2013-03-28 Thread zingbagbamark

How do I differentiate(first order and 2nd order) the following equations in 
python. I want to differentiate C wrt Q.

C = (Q**3)-15*(Q**2)+ 93*Q + 100

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Mark Lawrence


On 28/03/2013 03:18, Ethan Furman wrote:


I wouldn't call it unproductive -- a half-dozen amusing posts followed
because of Mark's initial post, and they were a great relief from the
tedium and (dare I say it?) idiocy of jmf's posts.

--
~Ethan~


Thanks for those words.  They're a tonic as I've just clawed my way out 
of bed at 12:00 GMT having slept for 15 hours.


Once the PEP393 unicode debacle has been sorted, does anyone have a cure 
for Chronic Fatigue Syndrome? :)


--
If you're using GoogleCrap™ please read this 
http://wiki.python.org/moin/GoogleGroupsPython.


Mark Lawrence

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

Re: Differentiation in Python

On Thu, 28 Mar 2013 05:17:36 -0700, zingbagbamark wrote:

 How do I differentiate(first order and 2nd order) the following
 equations in python. I want to differentiate C wrt Q.
 
 C = (Q**3)-15*(Q**2)+ 93*Q + 100


For such a simple case, you don't do it with Python, you do it with 
maths, and get an exact result.

dC/dQ = 3*Q**2 - 30*Q + 93


d²C/dQ² = 6*Q - 30


The rule for differentiating polynomials of the form

y = k*x**n

is:

dy/dx = (k*n)*x**(n-1)

Consult a good calculus text book or on-line site for further details.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Thu, 28 Mar 2013 23:11:55 +1100, Neil Hodgson wrote:

 Ian Foote:
 
 Specifically, indexing a variable-length encoding like utf-8 is not as
 efficient as indexing a fixed-length encoding.
 
 Many common string operations do not require indexing by character
 which reduces the impact of this inefficiency. 

Which common string operations do you have in mind?

Specifically in Python's case, the most obvious counter-example is the 
length of a string. But that's only because Python strings are immutable 
objects, and include a field that records the length. So once the string 
is created, checking its length takes constant time.

Some string operations need to inspect every character, e.g. str.upper(). 
Even for them, the increased complexity of a variable-width encoding 
costs. It's not sufficient to walk the string inspecting a fixed 1, 2 or 
4 bytes per character. You have to walk the string grabbing 1 byte at a 
time, and then decide whether you need another 1, 2 or 3 bytes. Even 
though it's still O(N), the added bit-masking and overhead of variable-
width encoding adds to the overall cost. 

Any string method that takes a starting offset requires the method to 
walk the string byte-by-byte. I've even seen languages put responsibility 
for dealing with that onto the programmer: the start offset is given in 
*bytes*, not characters. I don't remember what language this was... it 
might have been Haskell? Whatever it was, it horrified me.


 UTF-8 seems like a
 reasonable choice for an internal representation to me.

It's not. Haskell, for example, uses UTF-8 internally, and it warns that 
this makes string operations O(N) instead of O(1) precisely because of 
the need to walk the string inspecting every byte.

Remember, when your string primitives are O(N), it is very easy to write 
code that becomes O(N**2). Using UTF-8 internally is just begging for 
user-written code to be O(N**2).


 One benefit of
 UTF-8 over Python's flexible representation is that it is, on average,
 more compact over a wide set of samples.

Sure. And over a different set of samples, it is less compact. If you 
write a lot of Latin-1, Python will use one byte per character, while 
UTF-8 will use two bytes per character.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

after discussing about the line

2013-03-28 Thread betatwelve

Hiya all.

it might be appropriate to imagine the remote surveillance of the color using
 up-to-date methodologies when studying the line with the color remote 
monitoring;
We may also notice that, everybody should applicate this type of guidelines
 The hairline on the 
right side of the face creates a sweeping curve as it meets the neckline of 
the t-shirt.
 Such an approach was used to build our pencil portrait above.

 Take care where you choose to position them on the page as this will affect
 the overall balance of the portrait.
 The hairline on the right side of the
 face creates a sweeping curve as it meets the neckline of the t-shirt.
 The
 hairline on the right side of the face creates a sweeping curve as it meets 
the neckline of the t-shirt.
 Such an approach was used to build our pencil 
portrait above.
 Take care where you choose to position them on the page as 
this will affect the overall balance of the portrait.
 The hairline on the 
right side of the face creates a sweeping curve as it meets the neckline of 
the t-shirt.
 Such an approach was used to build our pencil portrait above.

 Take care where you choose to position them on the page as this will affect
 the overall balance of the portrait.
 The hairline on the right side of the
 face creates a sweeping curve as it meets the neckline of the t-shirt.
;
would you mind detailing how to increase the focus on the line supervision and 
the collaboration with the color data analysis?

tchao
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 11:30, Chris Angelico ros...@gmail.com wrote:
 On Thu, Mar 28, 2013 at 8:03 PM, jmfauth wxjmfa...@gmail.com wrote:

-

 You really REALLY need to sort out in your head the difference between
 correctness and performance. I still haven't seen one single piece of
 evidence from you that Python 3.3 fails on any point of Unicode
 correctness.

That's because you are not understanding unicode. Unicode takes
you from the character to the unicoded transformed fomat via
the code point, working with a unique set of characters with
a contigoous range of code points.
Then it is up to the implementors (languages, compilers, ...)
to implement this utf.

 Covering the whole range of Unicode has never been a
 problem.

... for all those, who are following the scheme explained above.
And it magically works smoothly. Of course, there are some variations
due to the Character Encoding Form wich is later influenced by the
Character Encoding Scheme (the serialization of the character Encoding
Scheme).

Rough explanation in other words.
I does not matter if you are using utf-8, -16, -32, ucs2 or ucs4.
All the single characters are handled in the same way with the same
algorithm.

---

The flexible string representation takes the problem from the
other side, it attempts to work with the characters by using
their representations and it (can only) fails...

PS I never propose to use utf-8. I only spoke about utf-8
as an example. If you start to discuss indexing, you are off-topic.

jmf


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

Re: Help with zip in a Python exercise

2013-03-28 Thread Anssi Saari

lug...@elpasotel.net writes:

 I've been working through a Python tutorial online and one of the exercises 
 uses the zip command.  The only problem is that the command doesn't work.  
 I've read through the man page for zip and it looks like what I'm attempting 
 should work, but it doesn't.

 The command is:

 zip -qr /media/backup/backups/test/20130326100218.zip -i 
 /home/luggw1/Documents/ /home/luggw1/Code/

-i simply isn't used to to specify which directories you want to
 zip. You can use it to specify filenames that you want in your zip,
 regardless of where they are. Not exactly an option I've ever had use
 for in over a decade of using zip...

Just leave -i out of the command and you'll probably get what you
intended.
-- 
http://mail.python.org/mailman/listinfo/python-list

Embed vtk window in a QTabWidget

2013-03-28 Thread Kene Meniru

Hi: 

I know this may not be the right place to post this but I found some other 
PyQt questions and I am desperate. 

My app is the Window class object below and I am trying to embed a 
QVTKRenderWindowInteractor class called ConeWindow in its QTabWidget. First 
of all running ConeWindow gives out QPainter::begin:, QPainter::save:, 
QPainter::setClipRegion:, and QPainter::restore: messages. This may be what 
is crashing the Window class when I embed it.

Can somebody help me here? Thanks.

---
#!/usr/bin/env python
from PyQt4 import QtGui, QtCore
import vtk
from vtk.qt4.QVTKRenderWindowInteractor import QVTKRenderWindowInteractor
import sys


class Window(QtGui.QMainWindow):
def __init__(self, parent=None):
super(Window, self).__init__(parent)
self.treeArea = QtGui.QTreeWidget()
self.textArea = QtGui.QTextEdit()
self.viewArea = QtGui.QTabWidget()
self.msgArea = QtGui.QTextBrowser()
# Add tabs
self.modelTab = ConeWindow(self)
#self.modelTab = QtGui.QTextBrowser()
self.reportTab = QtGui.QTextBrowser()
self.viewArea.addTab(self.modelTab, Model)
self.viewArea.addTab(self.reportTab, Report)
# Window area splitters
self.vSplitter = QtGui.QSplitter(QtCore.Qt.Vertical)
self.vSplitter.addWidget(self.viewArea)
self.vSplitter.addWidget(self.msgArea)
self.hSplitter = QtGui.QSplitter(QtCore.Qt.Horizontal)
self.hSplitter.addWidget(self.treeArea)
self.hSplitter.addWidget(self.textArea)
self.hSplitter.addWidget(self.vSplitter)
# Assign mainwindow
self.setCentralWidget(self.hSplitter)


class ConeWindow(QVTKRenderWindowInteractor):
def __init__(self, parent=None):
QVTKRenderWindowInteractor.__init__(self, parent)
self._parent = parent
self.vrenderer = vtk.vtkRenderer()
self.renderWindow = self.GetRenderWindow()
self.renderWindow.AddRenderer(self.vrenderer)
self.iren = self.renderWindow.GetInteractor()
#
self.cone = vtk.vtkConeSource()
self.cone.SetResolution(8)
self.coneMapper = vtk.vtkPolyDataMapper()
self.coneMapper.SetInput(self.cone.GetOutput())
self.coneActor = vtk.vtkActor()
self.coneActor.SetMapper(self.coneMapper)
self.vrenderer.AddActor(self.coneActor)
self.iren.Initialize()

if __name__ == '__main__':
app = QtGui.QApplication(sys.argv)
widge = Window()
widge.show()
sys.exit(app.exec_())

-- 

Kene
::
kemen...@gmail.com

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 14:01, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
 On Thu, 28 Mar 2013 23:11:55 +1100, Neil Hodgson wrote:
  Ian Foote:


  One benefit of
  UTF-8 over Python's flexible representation is that it is, on average,
  more compact over a wide set of samples.

 Sure. And over a different set of samples, it is less compact. If you
 write a lot of Latin-1, Python will use one byte per character, while
 UTF-8 will use two bytes per character.


This flexible string representation is so absurd that not only
it does not know you can not write Western European Languages
with latin-1, it penalizes you by just attempting to optimize
latin-1. Shown in my multiple examples.

(This is a similar case of the long and short int question/dicussion
Chris Angelico opened).


PS1: I received plenty of private mails. I'm suprise, how the dev
do not understand unicode.

PS2: Question I received once from a registrated French Python
Developper (in another context). What are those French characters
you can handle with cp1252 and not with latin-1?

jmf


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

No errors displayed but i blank scren nstead.

Fianlly my cgi .py script doesnt produce any more errors, i think i ahve 
correct them but it present a blank screen

http://superhost.gr

Any idea why?
What should i check?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Fri, Mar 29, 2013 at 1:12 AM, jmfauth wxjmfa...@gmail.com wrote:
 This flexible string representation is so absurd that not only
 it does not know you can not write Western European Languages
 with latin-1, it penalizes you by just attempting to optimize
 latin-1. Shown in my multiple examples.

PEP393 strings have two optimizations, or kinda three:

1a) ASCII-only strings
1b) Latin1-only strings
2) BMP-only strings
3) Everything else

Options 1a and 1b are almost identical - I'm not sure what the detail
is, but there's something flagging those strings that fit inside seven
bits. (Something to do with optimizing encodings later?) Both are
optimized down to a single byte per character.

Option 2 is optimized to two bytes per character.

Option 3 is stored in UTF-32.

Once again, jmf, you are forgetting that option 2 is a safe and
bug-free optimization.

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

Help printing the integers of a longer number

2013-03-28 Thread khaosyt

I want to print the individual numbers of a large number using division and 
modulus division. 

For example:

Enter a positive integer: 54321
5
4
3
2
1

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

Re: No errors displayed but i blank scren nstead.

2013-03-28 Thread Miki Tebeka

 Fianlly my cgi .py script doesnt produce any more errors, i think i ahve 
 correct them but it present a blank screen
 Any idea why?
Please post the code to the script, otherwise we can't help you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help printing the integers of a longer number

2013-03-28 Thread Joel Goldstick

On Thu, Mar 28, 2013 at 10:39 AM, khao...@gmail.com wrote:

 I want to print the individual numbers of a large number using division
 and modulus division.

 For example:

 Enter a positive integer: 54321
 5
 4
 3
 2
 1


This looks familiar.  Make the integer a string and use a for loop to
iterate over each item

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




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

Re: Help printing the integers of a longer number

On Fri, Mar 29, 2013 at 1:39 AM,  khao...@gmail.com wrote:
 I want to print the individual numbers of a large number using division and 
 modulus division.

 For example:

 Enter a positive integer: 54321
 5
 4
 3
 2
 1

Python has two operators that can help here:

// for integer division - returns the quotient without the remainder
% for modulus - returns the remainder

You'll also want to use a while loop to continue gathering digits so
long as there's something left in the number.

And if you want the digits to come out in that order, you're probably
going to want to gather them into a list and then output them in
reverse. But start by ignoring that part and producing something that,
for the input 54321, produces 1, 2, 3, 4, and then 5.

Finally, when you're asking about homework, please be honest about it.
We can tell, you're not putting one over us :) Better still, post your
non-working code and explain where you're having trouble; we'll be
happy to help you learn, but we won't simply give you the answer.

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

Re: No errors displayed but i blank scren nstead.

Τη Πέμπτη, 28 Μαρτίου 2013 4:42:59 μ.μ. UTC+2, ο χρήστης Miki Tebeka έγραψε:

 Please post the code to the script, otherwise we can't help you.

I wanted to make my website running Python 3 which is more new and bette:)

i treid to execute metrites.py via my jailed shell, please take a look if i'am 
not tiring you and maybe you can see if there is nothign wrong because i dont 
see nayhting.

The gethostbyaddr at the end its because the script run in cmd instead of in a 
browser.
Please help, its alkmost ready to run correctly!


[code]
ni...@superhost.gr [~/www/cgi-bin]# /usr/bin/python3 metrites.py 
!--: spam
Content-Type: text/html

body bgcolor=#f0f0f8font color=#f0f0f8 size=-5 --
body bgcolor=#f0f0f8font color=#f0f0f8 size=-5 -- --
/font /font /font /script /object /blockquote /pre
/table /table /table /table /table /font /font /fontbody 
bgcolor=#f0f0f8
table width=100% cellspacing=0 cellpadding=2 border=0 summary=heading
tr bgcolor=#6622aa
td valign=bottomnbsp;br
font color=#ff face=helvetica, 
arialnbsp;brbigbigstrongKeyError/strong/big/big/font/td
td align=right valign=bottom
font color=#ff face=helvetica, arialPython 3.2.3: 
/usr/bin/python3brThu Mar 28 09:41:53 2013/font/td/tr/table

pA problem occurred in a Python script.  Here is the sequence of
function calls leading up to the error, in the order they occurred./p
table width=100% cellspacing=0 cellpadding=0 border=0
trtd bgcolor=#d8bbffbignbsp;/biga 
href=file:///home/nikos/public_html/cgi-bin/metrites.py/home/nikos/public_html/cgi-bin/metrites.py/a
 in strongmodule/strong()/td/tr
trtdfont 
color=#909090ttnbsp;nbsp;smallnbsp;nbsp;nbsp;26/smallnbsp;userformnbsp;=nbsp;form.getvalue('userform')br
/tt/font/td/tr
trtdfont 
color=#909090ttnbsp;nbsp;smallnbsp;nbsp;nbsp;27/smallnbsp;br
/tt/font/td/tr
trtd 
bgcolor=#ffcceett=gt;smallnbsp;nbsp;nbsp;28/smallnbsp;hostnbsp;=nbsp;socket.gethostbyaddr(nbsp;os.environ['REMOTE_ADDR']nbsp;)[0]br
/tt/td/tr
trtdfont 
color=#909090ttnbsp;nbsp;smallnbsp;nbsp;nbsp;29/smallnbsp;datenbsp;=nbsp;(nbsp;datetime.utcnow()nbsp;+nbsp;timedelta(hours=2)nbsp;).strftime(nbsp;'%y-%m-%dnbsp;%H:%M:%S'nbsp;)br
/tt/font/td/tr
trtdfont 
color=#909090ttnbsp;nbsp;smallnbsp;nbsp;nbsp;30/smallnbsp;userinfonbsp;=nbsp;os.environ['HTTP_USER_AGENT']br
/tt/font/td/tr
trtdsmallfont color=#909090host emundefined/em, 
strongsocket/strongnbsp;= lt;module 'socket' from 
'/opt/python3/lib/python3.2/socket.py'gt;, 
socket.stronggethostbyaddr/strongnbsp;= lt;built-in function 
gethostbyaddrgt;, strongos/strongnbsp;= lt;module 'os' from 
'/opt/python3/lib/python3.2/os.py'gt;, os.strongenviron/strongnbsp;= 
environ({'PROMPT_COMMAND': 'history -a', 
'PERL_M...xa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:'})/font/small/td/tr/table
table width=100% cellspacing=0 cellpadding=0 border=0
trtd bgcolor=#d8bbffbignbsp;/biga 
href=file:///opt/python3/lib/python3.2/os.py/opt/python3/lib/python3.2/os.py/a
 in strong__getitem__/strong(self=environ({'PROMPT_COMMAND': 'history -a', 
'PERL_M...xa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:'}), 
key='REMOTE_ADDR')/td/tr
trtdfont 
color=#909090ttnbsp;nbsp;smallnbsp;nbsp;448/smallnbsp;br
/tt/font/td/tr
trtdfont 
color=#909090ttnbsp;nbsp;smallnbsp;nbsp;449/smallnbsp;nbsp;nbsp;nbsp;nbsp;defnbsp;__getitem__(self,nbsp;key):br
/tt/font/td/tr
trtd 
bgcolor=#ffcceett=gt;smallnbsp;nbsp;450/smallnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;valuenbsp;=nbsp;self._data[self.encodekey(key)]br
/tt/td/tr
trtdfont 
color=#909090ttnbsp;nbsp;smallnbsp;nbsp;451/smallnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;returnnbsp;self.decodevalue(value)br
/tt/font/td/tr
trtdfont 
color=#909090ttnbsp;nbsp;smallnbsp;nbsp;452/smallnbsp;br
/tt/font/td/tr
trtdsmallfont color=#909090value emundefined/em, 
strongself/strongnbsp;= environ({'PROMPT_COMMAND': 'history -a', 
'PERL_M...xa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:'}), 
self.strong_data/strongnbsp;= {b'CLASSPATH': 
b'.:/usr/local/jdk/lib/classes.zip', b'CVS_RSH': b'ssh', b'EDITOR': b'pico', 
b'GREP_COLOR': b'1;32', b'GREP_OPTIONS': b'--color', b'G_BROKEN_FILENAMES': 
b'1', b'HISTSIZE': b'5000', b'HOME': b'/home/nikos', b'HOSTNAME': 
b'menara.websitewelcome.com', b'INPUTRC': b'/etc/inputrc', ...}, 
self.strongencodekey/strongnbsp;= lt;function encodegt;, 
strongkey/strongnbsp;= 
'REMOTE_ADDR'/font/small/td/tr/tablepstrongKeyError/strong: 
b'REMOTE_ADDR'
brttsmallnbsp;nbsp;nbsp;nbsp;nbsp;/smallnbsp;/ttargsnbsp;=
(b'REMOTE_ADDR',)
brttsmallnbsp;nbsp;nbsp;nbsp;nbsp;/smallnbsp;/ttwith_tracebacknbsp;=
lt;built-in method with_traceback of KeyError objectgt;


!-- The above is a description of an error in a Python program, formatted
 for a Web browser because the 'cgitb' module was enabled.  In case you
 are not reading this in a Web browser, here is the original traceback:

Traceback (most recent call last):
  File metrites.py, line 28, in lt;modulegt;
host = socket.gethostbyaddr( os.environ['REMOTE_ADDR'] )[0]
  File /opt/python3/lib/python3.2/os.py, line 450, in

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread MRAB


On 28/03/2013 12:11, Neil Hodgson wrote:

Ian Foote:


Specifically, indexing a variable-length encoding like utf-8 is not
as efficient as indexing a fixed-length encoding.


Many common string operations do not require indexing by character
which reduces the impact of this inefficiency. UTF-8 seems like a
reasonable choice for an internal representation to me. One benefit
of UTF-8 over Python's flexible representation is that it is, on
average, more compact over a wide set of samples.


Implementing the regex module (http://pypi.python.org/pypi/regex) would
have been more difficult if the internal representation had been UTF-8,
because of the need to decode, and the implementation would also have
been slower for that reason.
--
http://mail.python.org/mailman/listinfo/python-list

Re: No errors displayed but i blank scren nstead.

Τη Πέμπτη, 28 Μαρτίου 2013 4:42:59 μ.μ. UTC+2, ο χρήστης Miki Tebeka έγραψε:
  Fianlly my cgi .py script doesnt produce any more errors, i think i ahve 
  correct them but it present a blank screen
 
  Any idea why?
 
 Please post the code to the script, otherwise we can't help you.

who ever dent me an email please sent agian or post here too

he sai soemhtign about param style but accidently got deleted please send again 
or post here!

Thank you and i apolgoze.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: No errors displayed but i blank scren nstead.

On Fri, Mar 29, 2013 at 1:46 AM, Νίκος Γκρ33κ nikos.gr...@gmail.com wrote:
 !-- The above is a description of an error in a Python program, formatted
  for a Web browser because the 'cgitb' module was enabled.  In case you
  are not reading this in a Web browser, here is the original traceback:

 Traceback (most recent call last):
   File metrites.py, line 28, in lt;modulegt;
 host = socket.gethostbyaddr( os.environ['REMOTE_ADDR'] )[0]
   File /opt/python3/lib/python3.2/os.py, line 450, in __getitem__
 value = self._data[self.encodekey(key)]
 KeyError: b'REMOTE_ADDR'

 --

Oh look, an exception traceback! In all this time of using Python,
Nikos, have you learned how to read these?

Very courteous of it to provide.

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

Re: Cannot run a single MySQLdb execute....

2013-03-28 Thread David M Chess

Νίκος Γκρ33κ nikos.gr...@gmail.com :

 What paramstyle are you using?

Yes it is Chris, but i'am not sure what exactly are you asking me.
Please if you cna pout it even simper for me, thank you.

For instance:

 import MySQLdb
 MySQLdb.paramstyle
'format'

FWIW and HTH,
DC

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

Re: No errors displayed but i blank scren nstead.

this is correct when it runs from a browser thats not the issue here othwerise 
it would prodice an error.

the question is why the blank screen...

somehting with param style perhaps?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Fri, Mar 29, 2013 at 1:51 AM, MRAB pyt...@mrabarnett.plus.com wrote:
 On 28/03/2013 12:11, Neil Hodgson wrote:

 Ian Foote:

 Specifically, indexing a variable-length encoding like utf-8 is not
 as efficient as indexing a fixed-length encoding.


 Many common string operations do not require indexing by character
 which reduces the impact of this inefficiency. UTF-8 seems like a
 reasonable choice for an internal representation to me. One benefit
 of UTF-8 over Python's flexible representation is that it is, on
 average, more compact over a wide set of samples.

 Implementing the regex module (http://pypi.python.org/pypi/regex) would
 have been more difficult if the internal representation had been UTF-8,
 because of the need to decode, and the implementation would also have
 been slower for that reason.

In fact, nearly ALL string parsing operations would need to be done
differently. The only method that I can think of that wouldn't be
impacted is a linear state-machine parser - something that could be
written inside a for character in string loop.

text = []

def initial(c):
global state
if c=='': state=tag
else: text.append(c)

def tag(c):
global state
if c=='': state=initial

state = initial
for character in string:
state(character)

print(''.join(text))


I'm pretty sure this will run in O(N) time, even with UTF-8 strings.
But it's an *extremely* simple parser.

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 15:38, Chris Angelico ros...@gmail.com wrote:
 On Fri, Mar 29, 2013 at 1:12 AM, jmfauth wxjmfa...@gmail.com wrote:
  This flexible string representation is so absurd that not only
  it does not know you can not write Western European Languages
  with latin-1, it penalizes you by just attempting to optimize
  latin-1. Shown in my multiple examples.

 PEP393 strings have two optimizations, or kinda three:

 1a) ASCII-only strings
 1b) Latin1-only strings
 2) BMP-only strings
 3) Everything else

 Options 1a and 1b are almost identical - I'm not sure what the detail
 is, but there's something flagging those strings that fit inside seven
 bits. (Something to do with optimizing encodings later?) Both are
 optimized down to a single byte per character.

 Option 2 is optimized to two bytes per character.

 Option 3 is stored in UTF-32.

 Once again, jmf, you are forgetting that option 2 is a safe and
 bug-free optimization.

 ChrisA

As long as you are attempting to devide a set of characters in
chunks and try to handle them seperately, it will never work.

Read my previous post about the unicode transformation format.
I know what pep393 does.

jmf

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

Re: No errors displayed but i blank scren nstead.

PLEASE GIVE ME A CLUE ABOUT THIS SITUATION.

EVEN JAILED SHELL ACCESS SAYS ITS OKEY BUT I CNA ONLY SEE A BLANK PAGE NOT EVEN 
AN INTERNAL SERVER ERROR.

ni...@superhost.gr [~/www/cgi-bin]# /usr/bin/python3 metrites.py 

says its ok.
-- 
http://mail.python.org/mailman/listinfo/python-list

list comprehension misbehaving

2013-03-28 Thread Wolfgang Maier

Dear all, with
a=list(range(1,11))

why (in Python 2.7 and 3.3) is this explicit for loop working:
for i in a[:-1]:
a.pop() and a

giving:
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8]
[1, 2, 3, 4, 5, 6, 7]
[1, 2, 3, 4, 5, 6]
[1, 2, 3, 4, 5]
[1, 2, 3, 4]
[1, 2, 3]
[1, 2]
[1]

but the equivalent comprehension failing:
[a.pop() and a for i in a[:-1]]

giving:
[[1], [1], [1], [1], [1], [1], [1], [1], [1]]

???
Especially, since these two things *do* work as expected:
[a.pop() and a[:] for i in a[:-1]]
[a.pop() and print(a) for i in a[:-1]] # Python 3 only

Thanks for your help,
Wolfgang

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

Replacing old data with new data using python

2013-03-28 Thread inkprs

I have 2 tables TBL1 and TBL2.

TBL1 has 2 columns id, nSql.
TBL2 has 3 columns date, custId, userId.
I have 17 rows in TBL1 with id 1 to 17. Each nSql has a SQL query in it.

For example nSql for

id == 1 is: select date, pId as custId, tId as userId from TBL3
id == 2 is: select date, qId as custId, rId as userId from TBL4 ...

nSql result is always same 3 columns.

Below query runs and puts data into the table TBL2. If there is already data in 
TBL2 for that day, I want the query to replace the data with new data. If there 
is not data in TBL2, I want to put data in normal way.

Any time I run the query, it will push the data for yesterday into TBL2.

For example, if I run the query in the morning and if I want to run it again in 
evening, I want new data to replace old data for yesterday, since data will be 
inserted into TBL2 everyday.

It is also precaution that if the data already exists (if run by coworker), I 
do not want duplicate data for that day.

I think we can use it in 'if else' statement. something pseudocode like: if 
there is data in TBL2 for  date_sub(curdate(), interval 1 day), remove the 
database data and insert new data. else insert new data into database. 



How can I do it?

Thank you.

(I am new to python, I would appreciate if someone could explain in steps and 
show in the code)

import MySQLdb

# Open connection
con = MySQLdb.Connection(host=localhost, user=root, passwd=root, 
db=test)

# create a cursor object 
cur = con.cursor()

selectStatement = (select nSql from TBL1) 
cur.execute(selectStatement)
res = cur.fetchall()
for outerrow in res:
nSql = outerrow[0]
cur.execute(nSql)
reslt = cur.fetchall()

for row in reslt:
date = row[0]
custId = row[1]
userId = row[2]
insertStatement = (insert into TBL2( date, custId, userId) values 
('%s', %d, %d) % (date, custId, userId))
cur.execute(insertStatement)
con.commit()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Fri, Mar 29, 2013 at 2:14 AM, jmfauth wxjmfa...@gmail.com wrote:
 As long as you are attempting to devide a set of characters in
 chunks and try to handle them seperately, it will never work.

Okay. Let's look at integers. To properly represent the Python 3 'int'
type (or the Python 2 'long'), we need to be able to encode ANY
integer. And of course, any attempt to divide them up into chunks will
never work. So we need a single representation that will cover ANY
integer, right?

Perfect. We already have one of those, detailed in RFC 2795. (It's
coming up to its thirteenth anniversary in a day or two. Very
appropriate.)

http://tools.ietf.org/html/rfc2795#section-4

Are you saying Python's integers should be stored as I-TAGs?

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

Re: No errors displayed but i blank scren nstead.

On Fri, Mar 29, 2013 at 2:20 AM, Νίκος Γκρ33κ nikos.gr...@gmail.com wrote:
 PLEASE GIVE ME A CLUE ABOUT THIS SITUATION.

 EVEN JAILED SHELL ACCESS SAYS ITS OKEY BUT I CNA ONLY SEE A BLANK PAGE NOT 
 EVEN AN INTERNAL SERVER ERROR.

Quit shouting. You are asking for free help from volunteers.

At the moment, you're asking for a killfiling.

You have the traceback. Read it. Grok it. Solve it.

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

Re: list comprehension misbehaving

2013-03-28 Thread Tim Chase

On 2013-03-28 15:25, Wolfgang Maier wrote:
 Dear all, with
 a=list(range(1,11))
 
 why (in Python 2.7 and 3.3) is this explicit for loop working:
 for i in a[:-1]:
 a.pop() and a

As you discover:

 Especially, since these two things *do* work as expected:
 [a.pop() and a[:] for i in a[:-1]]

it's because you're taking a snapshot copy of a in the middle of
the loop.  In your first example, if you change it to

  results = []
  for i in a[:-1]:
results.append(a.pop() and a)
  print results

you get the same thing as your list comprehension because each item
in results refers to the now-(mostly)empty a.

-tkc


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

Re: list comprehension misbehaving

2013-03-28 Thread Peter Otten

Wolfgang Maier wrote:

 Dear all, with
 a=list(range(1,11))
 
 why (in Python 2.7 and 3.3) is this explicit for loop working:
 for i in a[:-1]:
 a.pop() and a
 
 giving:
 [1, 2, 3, 4, 5, 6, 7, 8, 9]
 [1, 2, 3, 4, 5, 6, 7, 8]
 [1, 2, 3, 4, 5, 6, 7]
 [1, 2, 3, 4, 5, 6]
 [1, 2, 3, 4, 5]
 [1, 2, 3, 4]
 [1, 2, 3]
 [1, 2]
 [1]

No. Introduce a result list, and you'll see that you append the *same* list 
to the result nine times:

 a = range(1, 11)
 result = []
 for i in a[:-1]:
... result.append(a.pop() and a)
... 
 result
[[1], [1], [1], [1], [1], [1], [1], [1], [1]]

 but the equivalent comprehension failing:
 [a.pop() and a for i in a[:-1]]
 
 giving:
 [[1], [1], [1], [1], [1], [1], [1], [1], [1]]
 
 ???
 Especially, since these two things *do* work as expected:
 [a.pop() and a[:] for i in a[:-1]]
 [a.pop() and print(a) for i in a[:-1]] # Python 3 only

So you already know the solution to your problem...

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 16:14, jmfauth wxjmfa...@gmail.com wrote:
 On 28 mar, 15:38, Chris Angelico ros...@gmail.com wrote:









  On Fri, Mar 29, 2013 at 1:12 AM, jmfauth wxjmfa...@gmail.com wrote:
   This flexible string representation is so absurd that not only
   it does not know you can not write Western European Languages
   with latin-1, it penalizes you by just attempting to optimize
   latin-1. Shown in my multiple examples.

  PEP393 strings have two optimizations, or kinda three:

  1a) ASCII-only strings
  1b) Latin1-only strings
  2) BMP-only strings
  3) Everything else

  Options 1a and 1b are almost identical - I'm not sure what the detail
  is, but there's something flagging those strings that fit inside seven
  bits. (Something to do with optimizing encodings later?) Both are
  optimized down to a single byte per character.

  Option 2 is optimized to two bytes per character.

  Option 3 is stored in UTF-32.

  Once again, jmf, you are forgetting that option 2 is a safe and
  bug-free optimization.

  ChrisA

 As long as you are attempting to devide a set of characters in
 chunks and try to handle them seperately, it will never work.

 Read my previous post about the unicode transformation format.
 I know what pep393 does.

 jmf

Addendum.

This was you correctly percieved in one another thread.
You qualified it as a switch. Now you have to understand
from where this switch is coming from.

jmf

by toy with
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list comprehension misbehaving

2013-03-28 Thread Wolfgang Maier

Tim Chase python.list at tim.thechases.com writes:

 it's because you're taking a snapshot copy of a in the middle of
 the loop.  In your first example, if you change it to
 
   results = []
   for i in a[:-1]:
 results.append(a.pop() and a)
   print results
 
 you get the same thing as your list comprehension because each item
 in results refers to the now-(mostly)empty a.
 
 -tkc
 
 

Hi Tim, and thanks a lot for helping!
I got it:
in the comprehension case I'm only getting my results at the end,
when my list has been emptied!
Thanks, I got stuck with this, but now it's obvious.
Best,
Wolfgang


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

Re: No errors displayed but i blank scren nstead.

Τη Πέμπτη, 28 Μαρτίου 2013 5:25:26 μ.μ. UTC+2, ο χρήστης Chris Angelico έγραψε:
 On Fri, Mar 29, 2013 at 2:20 AM, Νίκος Γκρ33κ nikos.gr...@gmail.com wrote:
 
  PLEASE GIVE ME A CLUE ABOUT THIS SITUATION.
 
 
 
  EVEN JAILED SHELL ACCESS SAYS ITS OKEY BUT I CNA ONLY SEE A BLANK PAGE NOT 
  EVEN AN INTERNAL SERVER ERROR.
 
 
 
 Quit shouting. You are asking for free help from volunteers.
 
 
 
 At the moment, you're asking for a killfiling.
 
 
 
 You have the traceback. Read it. Grok it. Solve it.

What traceback? It displayes no error at all not i cmd not in browser mode at 
http://superhost.gr

i dont see what wrong with it.

If you know what wrong with it why not just tell me?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list comprehension misbehaving

2013-03-28 Thread duncan smith


On 28/03/13 15:25, Wolfgang Maier wrote:

Dear all, with
a=list(range(1,11))

why (in Python 2.7 and 3.3) is this explicit for loop working:
for i in a[:-1]:
 a.pop() and a

giving:
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8]
[1, 2, 3, 4, 5, 6, 7]
[1, 2, 3, 4, 5, 6]
[1, 2, 3, 4, 5]
[1, 2, 3, 4]
[1, 2, 3]
[1, 2]
[1]

but the equivalent comprehension failing:
[a.pop() and a for i in a[:-1]]

giving:
[[1], [1], [1], [1], [1], [1], [1], [1], [1]]

???
Especially, since these two things *do* work as expected:
[a.pop() and a[:] for i in a[:-1]]
[a.pop() and print(a) for i in a[:-1]] # Python 3 only

Thanks for your help,
Wolfgang



With the for loop the list is printed each time you pop an element. With 
the list comprehension all but one of the elements are popped before the 
string representation of the resulting list (containing several 
references to a) is printed.


The two list comprehensions that you say work behave differently 
because the first contains copies of a (which are unaffected by 
subsequent pops), and the second because (I imagine) it does something 
similar to,


[a.pop() and repr(a) for i in a[:-1]]

on 2.7 (I haven't migrated to 3 yet). i.e. The list contains a 
representation of a after each element is popped.


Duncan
--
http://mail.python.org/mailman/listinfo/python-list

Re: No errors displayed but i blank scren nstead.

On Fri, Mar 29, 2013 at 2:51 AM, Νίκος Γκρ33κ nikos.gr...@gmail.com wrote:
 Τη Πέμπτη, 28 Μαρτίου 2013 5:25:26 μ.μ. UTC+2, ο χρήστης Chris Angelico 
 έγραψε:
 On Fri, Mar 29, 2013 at 2:20 AM, Νίκος Γκρ33κ nikos.gr...@gmail.com wrote:

  PLEASE GIVE ME A CLUE ABOUT THIS SITUATION.

 

  EVEN JAILED SHELL ACCESS SAYS ITS OKEY BUT I CNA ONLY SEE A BLANK PAGE NOT 
  EVEN AN INTERNAL SERVER ERROR.



 Quit shouting. You are asking for free help from volunteers.



 At the moment, you're asking for a killfiling.



 You have the traceback. Read it. Grok it. Solve it.

 What traceback? It displayes no error at all not i cmd not in browser mode at 
 http://superhost.gr

 i dont see what wrong with it.

 If you know what wrong with it why not just tell me?

When you ran it from a shell, it showed you a traceback. Did you solve
that issue?

I am about done holding your hand like a little child. If you're not
going to pay me a salary (with overtime rates, it's Good Friday over
here now), you can solve your own problem... or at least demonstrate
that you're trying things. So far, you're just making random changes
that we can't see to code that we can't see, then expecting us to
solve your problems.

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Ian Kelly

On Thu, Mar 28, 2013 at 7:01 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 Any string method that takes a starting offset requires the method to
 walk the string byte-by-byte. I've even seen languages put responsibility
 for dealing with that onto the programmer: the start offset is given in
 *bytes*, not characters. I don't remember what language this was... it
 might have been Haskell? Whatever it was, it horrified me.

Go does this.  I remember because it came up in one of these threads,
where jmf (or was it Ranting Rick?) was praising Go for just getting
Unicode right.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: No errors displayed but i blank scren nstead.

Τη Πέμπτη, 28 Μαρτίου 2013 4:42:59 μ.μ. UTC+2, ο χρήστης Miki Tebeka έγραψε:
  Fianlly my cgi .py script doesnt produce any more errors, i think i ahve 
  correct them but it present a blank screen
 
  Any idea why?
 
 Please post the code to the script, otherwise we can't help you.

Can you do me a big favour please?

may i send you my code or perhaps jailed linux access so to understand whats 
wrong and altyhough i get no erros now i see a blank poage at 
http://superhost.gr

Please man iam struggling 2 days to conever a 2,6 script to 3.2.3

please accept!!!
-- 
http://mail.python.org/mailman/listinfo/python-list

IV ECCOMAS Thematic Conference VipIMAGE 2013: SUBMISSION REMINDER

2013-03-28 Thread tava...@fe.up.pt

Dear Colleague,

We would like to call your attention that the deadline for abstracts submission 
for the International Conference VipIMAGE 2013 - IV ECCOMAS THEMATIC CONFERENCE 
ON COMPUTATIONAL VISION AND MEDICAL IMAGE PROCESSING (www.fe.up.pt/~vipimage) 
to be held October 14-16, 2013, in Melia Madeira Mare Hotel, Madeira Island, 
Funchal, Portugal, is approaching (April 15).

Once again, we would like to invite you to participate and share your expertise 
in VipIMAGE 2013.


Possible Topics (not limited to)

• Signal and Image Processing 
• Computational Vision 
• Medical Imaging 
• Physics of Medical Imaging 
• Tracking and Analysis of Movement 
• Simulation and Modeling
• Image Acquisition 
• Industrial Applications 
• Shape Reconstruction 
• Objects Segmentation, Matching, Simulation 
• Data Interpolation, Registration, Acquisition and Compression 
• 3D Vision 
• Virtual Reality 
• Visual Inspection 
• Software Development for Image Processing and Analysis 
• Computer Aided Diagnosis, Surgery, Therapy, and Treatment 
• Computational Bioimaging and Visualization 
• Telemedicine Systems and their Applications

Invited Lecturers

• Daniel Rueckert - Imperial College London, UK
• Dimitris N. Metaxas - Rutgers University, USA
• Durval C. Costa - Champalimaud Foundation, Portugal
• James S Duncan - Yale School of Medicine, USA
• Milan Sonka - The University of Iowa, USA
• Richard Bowden - University of Surrey, UK

Thematic Sessions

Proposals to organize Thematic Session under the auspicious of VipIMAGE 2013 
are welcome.
Proposals for Thematic Sessions should be submitted by email to the conference 
co-chairs (tava...@fe.up.pt, rna...@fe.up.pt).

Confirmed Thematic Sessions

• Imaging of Biological Flows: trends and challenges
• Trabecular Bone Characterization: New trends and challenges
• Computational Vision and Image Processing applied to Dental Medicine

Publications

• Proceedings: The proceedings book will be published by the Taylor  Francis 
Group (www.balkema.nl/instructions.asp) and indexed by Thomson Reuters 
Conference Proceedings Citation Index, IET Inspect and Elsevier Scopus.
• Springer Book: A book with 20 invited works from the ones presented in the 
conference will be published by Springer under the book series “Lecture Notes 
in Computational Vision and Biomechanics” (www.springer.com/series/8910).
• Journal Publication: A dedicated special issue of the Taylor  Francis 
International Journal “Computer Methods in Biomechanics and Biomedical 
Engineering: Imaging  Visualization” (www.tandfonline.com/tciv) will be 
published with extended versions of the best works presented in the conference.

Important dates

• Deadline for Abstracts: April 15, 2013
• Authors Notification: May 1, 2013
• Deadline for Lectures and Papers: July 1, 2013


We are looking forward to see you in Funchal next October.

Kind regards,

João Manuel R. S. Tavares
Renato Natal Jorge
(conference co-chairs)

PS. For further details, please, have a look in the conference website at: 
www.fe.up.pt/~vipimage, or in the conference Facebook page at: 
www.facebook.com/pages/Vipimage/237980719665456, or join the LinkedIn 
conference group at: http://www.linkedin.com/groups?gid=4752820trk=hb_side_g
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Terry Reedy


On 3/28/2013 10:38 AM, Chris Angelico wrote:


PEP393 strings have two optimizations, or kinda three:

1a) ASCII-only strings
1b) Latin1-only strings
2) BMP-only strings
3) Everything else

Options 1a and 1b are almost identical - I'm not sure what the detail
is, but there's something flagging those strings that fit inside seven
bits. (Something to do with optimizing encodings later?)


Yes. 'Encoding' an ascii-only string to any ascii-compatible encoding 
amounts to a simple copy of the internal bytes. I do not know if *all* 
the codecs for such encodings are 393-aware, but I do know that the 
utf-8 and latin-1 group are. This is one operation that 3.3+ does much 
faster than 3.2-



--
Terry Jan Reedy

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

Re: No errors displayed but i blank scren nstead.

Τη Πέμπτη, 28 Μαρτίου 2013 5:59:55 μ.μ. UTC+2, ο χρήστης Chris Angelico έγραψε:
On Fri, Mar 29, 2013 at 2:51 AM, Νίκος Γκρ33κ nikos.gr...@gmail.com wrote:

Τη Πέμπτη, 28 Μαρτίου 2013 5:25:26 μ.μ. UTC+2, ο χρήστης Chris Angelico
έγραψε:

On Fri, Mar 29, 2013 at 2:20 AM, Νίκος Γκρ33κ nikos.gr...@gmail.com
wrote:

PLEASE GIVE ME A CLUE ABOUT THIS SITUATION.

EVEN JAILED SHELL ACCESS SAYS ITS OKEY BUT I CNA ONLY SEE A BLANK PAGE
NOT EVEN AN INTERNAL SERVER ERROR.

Quit shouting. You are asking for free help from volunteers.

At the moment, you're asking for a killfiling.

You have the traceback. Read it. Grok it. Solve it.

What traceback? It displayes no error at all not i cmd not in browser mode
at http://superhost.gr

i dont see what wrong with it.

If you know what wrong with it why not just tell me?

When you ran it from a shell, it showed you a traceback. Did you solve

that issue?

I am about done holding your hand like a little child. If you're not

going to pay me a salary (with overtime rates, it's Good Friday over

here now), you can solve your own problem... or at least demonstrate

that you're trying things. So far, you're just making random changes

that we can't see to code that we can't see, then expecting us to

solve your problems.

ChrisA

I am trying my best with the little knowledge i have and i expect no help from
you. You are more inclinded to criticize that to actually help. And if i pay
someone that certainly not gonna be you.

And i told you about gethostbyaddr, tht its not an issue its because the script
bein run form cmd that canot get hold of an address via browser tis ok.

something else is wrong here and the page is displayed blank.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Replacing old data with new data using python

On Fri, Mar 29, 2013 at 2:23 AM,  ink...@gmail.com wrote:
 I think we can use it in 'if else' statement. something pseudocode like: if 
 there is data in TBL2 for  date_sub(curdate(), interval 1 day), remove the 
 database data and insert new data. else insert new data into database.

 How can I do it?

Can you simply do a searched DELETE?

DELETE from TBL2 WHERE datedate_sub(curdate(), interval 1 day)

That will happily do nothing if there are no such records. Be careful
of what it'll do, of course. Make sure you won't accidentally delete
too much!

(BTW, isn't date a reserved word? Maybe it isn't in MySQL.)

 insertStatement = (insert into TBL2( date, custId, userId) values 
 ('%s', %d, %d) % (date, custId, userId))
 cur.execute(insertStatement)
 con.commit()

I recommend you get used to parameterized queries. Assuming your date
field, coming from the other table, is clean, this will be safe; but
if there's any chance that date might have an apostrophe in it, this
code is very dangerous.

But there's a really neat trick you can do. If you have a guarantee
that all the SQL statements follow the structure you've given, just
prepend a simple string to them, thus:

select date, pId as custId, tId as userId from TBL3
--
insert into TBL2 (date, custId, userId) select date, pId as custId,
tId as userId from TBL3

That'll do the whole transfer in a single statement! Something like this:

cur.execute(select nSql from TBL1)
for outerrow in cur.fetchall():
cur.execute(insert into TBL2 (date, custId, userId) +outerrow[0])
con.commit()

Note: I've backtabbed the commit() call so that the whole job happens
in a single transaction. You may wish to reindent it, to preserve the
semantics of your previous version; but I recommend doing the whole
job as one transaction, rather than committing each row separately. If
this job is interrupted, you'll have to start over anyway, so you may
as well have the database be clean.

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Ian Kelly

On Thu, Mar 28, 2013 at 8:38 AM, Chris Angelico ros...@gmail.com wrote:
 PEP393 strings have two optimizations, or kinda three:

 1a) ASCII-only strings
 1b) Latin1-only strings
 2) BMP-only strings
 3) Everything else

 Options 1a and 1b are almost identical - I'm not sure what the detail
 is, but there's something flagging those strings that fit inside seven
 bits. (Something to do with optimizing encodings later?) Both are
 optimized down to a single byte per character.

The only difference for ASCII-only strings is that they are kept in a
struct with a smaller header.  The smaller header omits the utf8
pointer (which optionally points to an additional UTF-8 representation
of the string) and its associated length variable.  These are not
needed for ASCII-only strings because an ASCII string can be directly
interpreted as a UTF-8 string for the same result.  The smaller header
also omits the wstr_length field which, according to the PEP,
differs from length only if there are surrogate pairs in the
representation.  For an ASCII string, of course there would not be
any surrogate pairs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Fri, Mar 29, 2013 at 3:01 AM, Terry Reedy tjre...@udel.edu wrote:
 On 3/28/2013 10:38 AM, Chris Angelico wrote:

 PEP393 strings have two optimizations, or kinda three:

 1a) ASCII-only strings
 1b) Latin1-only strings
 2) BMP-only strings
 3) Everything else

 Options 1a and 1b are almost identical - I'm not sure what the detail
 is, but there's something flagging those strings that fit inside seven
 bits. (Something to do with optimizing encodings later?)


 Yes. 'Encoding' an ascii-only string to any ascii-compatible encoding
 amounts to a simple copy of the internal bytes. I do not know if *all* the
 codecs for such encodings are 393-aware, but I do know that the utf-8 and
 latin-1 group are. This is one operation that 3.3+ does much faster than
 3.2-

Thanks Terry. So that's not so much a representation difference as a
flag that costs little or nothing to retain, and can improve
performance in the encode later on. Sounds like a useful tweak to the
basics of flexible string representation, without being particularly
germane to jmf's complaints.

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Ian Kelly

On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wxjmfa...@gmail.com wrote:
 The flexible string representation takes the problem from the
 other side, it attempts to work with the characters by using
 their representations and it (can only) fails...

This is false.  As I've pointed out to you before, the FSR does not
divide characters up by representation.  It divides them up by
codepoint -- more specifically, by the *bit-width* of the codepoint.
We call the internal format of the string ASCII or Latin-1 or
UCS-2 for conciseness and a point of reference, but fundamentally
all of the FSR formats are simply byte arrays of *codepoints* -- you
know, those things you keep harping on.  The major optimization
performed by the FSR is to consistently truncate the leading zero
bytes from each codepoint when it is possible to do so safely.  But
regardless of to what extent this truncation is applied, the string is
*always* internally just an array of codepoints, and the same
algorithms apply for all representations.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

Chris,

Your problem with int/long, the start of this thread, is
very intersting.

This is not a demonstration, a proof, rather an illustration.

Assume you have a set of integers {0...9} and an operator,
let say, the addition.

Idea.
Just devide this set in two chunks, {0...4} and {5...9}
and work hardly to optimize the addition of 2 operands in
the sets {0...4}.

The problems.
- When optimizing {0...4}, your algorithm will most probably
weaken {5...9}.
- When using {5...9}, you do not benefit from your algorithm, you
will be penalized just by the fact you has optimized {0...4}
- And the first mistake, you are just penalized and impacted by the
fact you have to select in which subset you operands are when
working with {0...9}.

Very interestingly, working with the representation (bytes) of
these integers will not help. You have to consider conceptually
{0..9} as numbers.

Now, replace numbers by characters, bytes by encoded code points,
and you have qualitatively the flexible string representation.

In Unicode, there is one more level of abstraction: one conceptually
neither works with characters, nor with encoded code points, but
with unicode transformed formated entities. (see my previous post).

That means you can work very hardly on the bytes levels,
you will never solves the problem which is one level higher
in the unicode hierarchy:
character - code point - utf - bytes (implementation)
with the important fact that this construct can only go
from left to right.

---

In fact, by proposing a flexible representation of ints, you may
just fall in the same trap the flexible string representation
presents.



All this stuff is explained in good books about the coding of the
characters and/or unicode.
The unicode.org documention explains it too. It is a little
bit harder to discover, because the doc is presenting always
this stuff from a technical perspective.
You get it when reading a large part of the Unicode doc.

jmf



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

Re: Help printing the integers of a longer number

2013-03-28 Thread Jussi Piitulainen

khao...@gmail.com writes:

 I want to print the individual numbers of a large number using
 division and modulus division.
 
 For example:
 
 Enter a positive integer: 54321
 5
 4
 3
 2
 1

Those numbers are called the digits of the large number.

With divmod(54321, 10) you get both the number that is left after
removing the last digit, and the last digit:

 left, last = divmod(54321, 10)
 left
5432
 last
1

Define a function, print_digits(num), that prints the digits of the
non-negative integer num. Zero turns out fine so let's allow zero:

def print_digits(num):
   left, last = divmod(num, 10)
   if left  0: print the digits of left
   print(last)

How do you print the digits of left? With print_digits. Why does it
work? Because you only call print_digits again when left is closer to
zero than num.

It's called recursion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Fri, Mar 29, 2013 at 3:55 AM, jmfauth wxjmfa...@gmail.com wrote:
 Assume you have a set of integers {0...9} and an operator,
 let say, the addition.

 Idea.
 Just devide this set in two chunks, {0...4} and {5...9}
 and work hardly to optimize the addition of 2 operands in
 the sets {0...4}.

 The problems.
 - When optimizing {0...4}, your algorithm will most probably
 weaken {5...9}.
 - When using {5...9}, you do not benefit from your algorithm, you
 will be penalized just by the fact you has optimized {0...4}
 - And the first mistake, you are just penalized and impacted by the
 fact you have to select in which subset you operands are when
 working with {0...9}.

 Very interestingly, working with the representation (bytes) of
 these integers will not help. You have to consider conceptually
 {0..9} as numbers.

Yeah, and there's an easy representation of those numbers. But let's
look at Python's representations of integers. I have a sneaking
suspicion something takes note of how large the number is before
deciding how to represent it. Look!

 sys.getsizeof(1)
14
 sys.getsizeof(12)
14
 sys.getsizeof(14)
14
 sys.getsizeof(18)
14
 sys.getsizeof(131)
18
 sys.getsizeof(130)
18
 sys.getsizeof(116)
16
 sys.getsizeof(112345)
1660
 sys.getsizeof(1123456)
16474

Small numbers are represented more compactly than large ones! And it's
not like in REXX, where all numbers are stored as strings.

Go fork CPython and make the changes you suggest. Then run real-world
code on it and see how it performs. Or at very least, run plausible
benchmarks like the strings benchmark from the standard tests.

My original post about integers was based on two comparisons: Python 2
and Pike. Both languages have an optimization for small integers
(where small is within machine word - on rechecking some of my
stats, I find that I perhaps should have used a larger offset, as the
64-bit Linux Python I used appeared to be a lot faster than it should
have been), which Python 3 doesn't have. Real examples, real
statistics, real discussion. (I didn't include Pike stats in what I
posted, for two reasons: firstly, it would require a reworking of the
code, rather than simply run this under both interpreters; and
secondly, Pike performance is completely different from CPython
performance, and is non-comparable. Pike is more similar to PyPy, able
to compile - in certain circumstances - to machine code. So the
comparisons were Py2 vs Py3.)

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

Re: Help printing the integers of a longer number

2013-03-28 Thread Jussi Piitulainen

Jussi Piitulainen writes:

 khao...@gmail.com writes:
 
  I want to print the individual numbers of a large number using
  division and modulus division.
  
  For example:
  
  Enter a positive integer: 54321
  5
  4
  3
  2
  1
 
 Those numbers are called the digits of the large number.
 
 With divmod(54321, 10) you get both the number that is left after
 removing the last digit, and the last digit:
 
  left, last = divmod(54321, 10)
  left
 5432
  last
 1
 
 Define a function, print_digits(num), that prints the digits of the
 non-negative integer num. Zero turns out fine so let's allow zero:
 
 def print_digits(num):
left, last = divmod(num, 10)
if left  0: print the digits of left
print(last)

Blush. That should be:

...
if left  0: ...
...

(Or just if left because left will eventually be 0, positive numbers
are true values, and 0 is a false value.)

Sorry about that.

 How do you print the digits of left? With print_digits. Why does it
 work? Because you only call print_digits again when left is closer to
 zero than num.
 
 It's called recursion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help printing the integers of a longer number

On Fri, Mar 29, 2013 at 4:03 AM, Jussi Piitulainen
jpiit...@ling.helsinki.fi wrote:
 def print_digits(num):
left, last = divmod(num, 10)
if left  0: print the digits of left
print(last)

 How do you print the digits of left? With print_digits. Why does it
 work? Because you only call print_digits again when left is closer to
 zero than num.

 It's called recursion.

An elegant solution, but buggy, I'm afraid... fortunately it's a
trivial problem. The comparison should be left0. :)

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

Re: Help printing the integers of a longer number

On Fri, Mar 29, 2013 at 4:11 AM, Jussi Piitulainen
jpiit...@ling.helsinki.fi wrote:
 Jussi Piitulainen writes:

 khao...@gmail.com writes:

  I want to print the individual numbers of a large number using
  division and modulus division.
 
  For example:
 
  Enter a positive integer: 54321
  5
  4
  3
  2
  1

 Those numbers are called the digits of the large number.

 With divmod(54321, 10) you get both the number that is left after
 removing the last digit, and the last digit:

  left, last = divmod(54321, 10)
  left
 5432
  last
 1

 Define a function, print_digits(num), that prints the digits of the
 non-negative integer num. Zero turns out fine so let's allow zero:

 def print_digits(num):
left, last = divmod(num, 10)
if left  0: print the digits of left
print(last)

 Blush. That should be:

 ...
 if left  0: ...
 ...

 (Or just if left because left will eventually be 0, positive numbers
 are true values, and 0 is a false value.)

 Sorry about that.

Sorry, I just nitpicked that very thing, hehe :)

Note that this doesn't work with negative numbers; it'll infinitely
recurse, due to divmod's behaviour. You'd need a special trap in there
to handle that:

if num0:
print(-)
num=-num
# and continue.

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

Re: No errors displayed but i blank scren nstead.

2013-03-28 Thread Walter Hurry

On Fri, 29 Mar 2013 02:25:26 +1100, Chris Angelico wrote:

 On Fri, Mar 29, 2013 at 2:20 AM, Νίκος Γκρ33κ nikos.gr...@gmail.com
 wrote:
 PLEASE GIVE ME A CLUE ABOUT THIS SITUATION.

 EVEN JAILED SHELL ACCESS SAYS ITS OKEY BUT I CNA ONLY SEE A BLANK PAGE
 NOT EVEN AN INTERNAL SERVER ERROR.
 
 Quit shouting. You are asking for free help from volunteers.
 
 At the moment, you're asking for a killfiling.

He's got one.

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

Re: No errors displayed but i blank scren nstead.

Like you werent of any help
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 17:33, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wxjmfa...@gmail.com wrote:
  The flexible string representation takes the problem from the
  other side, it attempts to work with the characters by using
  their representations and it (can only) fails...

 This is false.  As I've pointed out to you before, the FSR does not
 divide characters up by representation.  It divides them up by
 codepoint -- more specifically, by the *bit-width* of the codepoint.
 We call the internal format of the string ASCII or Latin-1 or
 UCS-2 for conciseness and a point of reference, but fundamentally
 all of the FSR formats are simply byte arrays of *codepoints* -- you
 know, those things you keep harping on.  The major optimization
 performed by the FSR is to consistently truncate the leading zero
 bytes from each codepoint when it is possible to do so safely.  But
 regardless of to what extent this truncation is applied, the string is
 *always* internally just an array of codepoints, and the same
 algorithms apply for all representations.

-

You know, we can discuss this ad nauseam. What is important
is Unicode.

You have transformed Python back in an ascii oriented product.

If Python had imlemented Unicode correctly, there would
be no difference in using an a, é, € or any character,
what the narrow builds did.

If I am practically the only one, who speakes /discusses about
this, I can ensure you, this has been noticed.

Now, it's time to prepare the Asparagus, the jambon cru
and a good bottle a dry white wine.

jmf




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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Fri, Mar 29, 2013 at 4:48 AM, jmfauth wxjmfa...@gmail.com wrote:
 If Python had imlemented Unicode correctly, there would
 be no difference in using an a, é, € or any character,
 what the narrow builds did.

I'm not following your grammar perfectly here, but if Python were
implementing Unicode correctly, there would be no difference between
any of those characters, which is the way a *wide* build works. With a
narrow build, there is a difference between BMP and non-BMP
characters.

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

Re: Differentiation in Python

2013-03-28 Thread David Robinow

On Thu, Mar 28, 2013 at 8:17 AM,  zingbagbam...@gmail.com wrote:
 How do I differentiate(first order and 2nd order) the following equations in 
 python. I want to differentiate C wrt Q.

 C = (Q**3)-15*(Q**2)+ 93*Q + 100


 Years ago, when I actually worked for a living, I would have
done something like this:

coeffs = [1, -15, 93, 100]
num_coeffs = len(coeffs)-1
deriv = [coeffs[i]*(num_coeffs-i) for i in range(num_coeffs)]
print(deriv)


The above is somewhat obscure and requires one to add
some documentation.  Who wants to do that?

Below is a version using numpy. You get the numpy docs
for free.

import numpy as np
p = np.poly1d(coeffs)
deriv_np = np.polyder(p)
print(deriv_np)
# or
print(list(deriv_np))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: No errors displayed but i blank scren nstead.

Will someone help me out here please?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Small program ideas

2013-03-28 Thread PMT

Em sábado, 16 de fevereiro de 2013 03h22min41s UTC, eli m  escreveu:
 Any small program ideas? I would prefer to stick to command line ones. Thanks.

What about this one? 

Do you know how to do the elevator simulation?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: No errors displayed but i blank scren nstead.

2013-03-28 Thread Mark Lawrence


On 28/03/2013 18:37, Νίκος Γκρ33κ wrote:

Will someone help me out here please?



I suggest you take a course in diplomacy, but not one given by me :)

--
If you're using GoogleCrap™ please read this 
http://wiki.python.org/moin/GoogleGroupsPython.


Mark Lawrence

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

Re: No errors displayed but i blank scren nstead.

Well i dont like people taking to me this way espceially when iam tryign 2 days 
for something and thats changing from 2.6 = 3.2.3

I follow advice as long as i can understand whats being said to me.

So if someone wants to help by asking me to try things please do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Lazy evaluated

2013-03-28 Thread Habibutsu


For example, we have  following code:

01|def foo():
02|return 1
03|
04|value = foo()
05|
06|if value == 1:
07|print value,- equal 1
08|
09|if isinstance(value, int):
10|print value,- is int
11|else:
12|print value,- is not int

Task is to create lazy evaluation for function 'foo'.
For decision this task we create special function 'lazy' which turn 
original function into a lazy evaluated function by means of creating 
proxy object that evaluated value if needed. We add following code:


01|def lazy(func):
02|
03|class ProxyLazy(object):
04|_result_value = None
05|
06|@property
07|def result_value(self):
08|if self._result_value is not None:
09|return self._result_value
10|self._result_value = self.func(*self.args, **self.kw)
11|return self._result_value
12|
13|def __str__(self):
14|return str(self.result_value)
15|
16|def __cmp__(self, other):
17|return cmp(self.result_value, other)
18|
19|# and other __unicode__, __eq__, __ne__ and so on
20|
21|def wrapper(*args, **kw):
22|proxy = ProxyLazy()
23|proxy.func = func
24|proxy.args = args
25|proxy.kw = kw
26|return proxy
27|
28|return wrapper
29|
30|lazy_foo = lazy(foo)
31|value = lazy_foo()

Unfortunately, this method not allow to use 'isinstance' for check type. 
We can create other variant of function 'lazy' is 'lazy_promise' in 
which additional parameter will be passed with type of result value. 
After we can create 'LazyMetaClass' with helping of which will be 
created 'ProxyLazy'


01|def lazy_promise(func, resultclass):
02|
03|class LazyMetaClass(type):
04|def __new__(cls, name, bases, attrs):
05|return super(LazyMetaClass, cls).__new__(cls, name, 
(resultclass,), attrs)

06|
07|class ProxyLazy(object):
08|__metaclass__ = LazyMetaClass
...
35|lazy_foo = lazy_promise(foo, int)
36|value = lazy_foo()

And everything seems to work, but appear other questions. If original 
function return different types - what to do in this case? Where i am 
wrong? What other way to do that. Was no idea to create keyword 'lazy' 
in Python?


Thanks
--
http://mail.python.org/mailman/listinfo/python-list

Re: Cannot run a single MySQLdb execute....

Τη Πέμπτη, 28 Μαρτίου 2013 4:51:16 μ.μ. UTC+2, ο χρήστης David M Chess έγραψε:
 Νίκος Γκρ33κ nikos...@gmail.com
 :
 
 
 
  What paramstyle are you using?
 
 
 
 Yes it is Chris, but i'am not sure what exactly are you asking me.
 
 Please if you cna pout it even simper for me, thank you.
 
 
 
 For instance:
 
 
 
  import MySQLdb
 
  MySQLdb.paramstyle
 
 'format'
 
 


ni...@superhost.gr [~]# /usr/bin/python3
Python 3.2.3 (default, May 23 2012, 18:47:48) 
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type help, copyright, credits or license for more information.
 import MySQLdb
 MySQLdb.paramstyle
'format'

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread rurpy

On 03/28/2013 01:48 AM, Steven D'Aprano wrote:
 On Wed, 27 Mar 2013 22:42:18 -0700, rusi wrote:
 More seriously Ive never seen anyone -- cause or person -- aided by
 the use of excessively strong language.
 
 Of course not. By definition, if it helps, it wasn't *excessively* strong 
 language.

For someone who delights in pointing out the logical errors 
of others you are often remarkably sloppy in your own logic.

Of course language can be both helpful and excessively strong.
That is the case when language less strong would be
equally or more helpful.

 IOW I repeat my support for Ned's request: Ad hominiem attacks are not
 welcome, irrespective of the context/provocation.
 
 Insults are not ad hominem attacks.

Insults may or may not be ad hominem attacks.  There is nothing 
mutually exclusive about those terms.

 You sir, are a bounder and a cad. Furthermore, your 
 argument is wrong, because of reasons.
 
 may very well be an insult, but it also may be correct, and the reasons 
 logically valid.

Those are two different statements.  The first is an ad hominem 
attack and is not welcome here.  The second is an acceptable 
response.

 Your argument is wrong, because you are a bounder 
 and a cad.
 
 is an ad hominem fallacy, because even bounders and cads may tell the 
 truth occasionally, or be correct by accident.

That it is a fallacy does not mean it is not also an attack.

 I find it interesting that nobody has yet felt the need to defend JMF, 
 and tell me I was factually incorrect about him (as opposed to merely 
 impolite or mean-spirited).

Nothing interesting about it at all.  Most of us (perhaps
unlike you) are not interested in discussing the personal
characteristics of posters here (in contrast to discussing
the technical opinions they post).

Further, liar is both so non-objective and so pejoratively 
emotive that it is a word much more likely to be used by 
someone interested in trolling than in a serious discussion, 
so most sensible people here likely would not bite.

[...] 
 I would rather that you called me a liar to my face 
 and gave me the opportunity to respond, than for you to ignore everything 
 I said.

Even if you personally would prefer someone to respond by 
calling you a liar, your personal preferences do not form 
a basis for desirable posting behavior here.

But again you're creating a false dichotomy.  Those are not 
the only two choices.  A third choice is neither ignore you 
nor call you a liar but to factually point out where you are 
wrong, or (if it is a matter of opinion) why one holds a 
different opinion.  That was the point Ned Deily was making 
I believe.

 I hope that we all agree that we want a nice, friendly, productive 
 community where everyone is welcome. 

I hope so too but it is likely that some people want a place 
to develop and assert some sense of influence, engage in verbal 
duels, instigate arguments, etc.  That can be true of regulars
here as well as drive-by posters.

 But some people simply cannot or 
 will not behave in ways that are compatible with those community values. 
 There are some people whom we *do not want here* 

In other words, everyone is NOT welcome.

 -- spoilers and messers, 
 vandals and spammers and cheats and liars and trolls and crackpots of all 
 sorts. 

Where those terms are defined by you and a handful of other 
voracious posters.  Troll in particular is often used to 
mean someone who disagrees with the borg mind here, or who 
says anything negative about Python, or who due attitude or
lack of full English fluency do not express themselves in 
a sufficiently submissive way.

 We only disagree as to the best way to make it clear to them that 
 they are not welcome so long as they continue their behaviour.

No, we disagree on who fits those definitions and even 
how tolerant we are to those who do fit the definitions.
The policing that you and a handful of other self-appointed
net-cops try to do is far more obnoxious that the original 
posts are.

 [1] Although sadly, given the reality of communication on the Internet, 
 sometimes kill-filing is the least-worst option.

Please, please, killfile jmfauth, ranting rick, xaw lee and 
anyone else you don't like so that the rest of us can be spared 
the orders of magnitude larger, more disruptive and more offensive
posts generated by your (plural) responses to them.

Believe or not, most of the rest of us here are smart enough to
form our own opinions of such posters without you and the other
c.l.p truthsquad members telling us what to think. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Ned Deily

In article 
captjjmozdhsmuqx7vcpuii2bwrcnzcx76pm-6unb1duq4do...@mail.gmail.com,
 Chris Angelico ros...@gmail.com wrote:
 I'd rather this list have some vinegar than it devolve into
 uselessness. Or, worse, if there's a hard-and-fast rule about
 courtesy, devolve into aspartame... everyone's courteous in words but
 hates each other underneath. Or am I taking the analogy too far? :)

I think you are positing false choices.  No one - at least I'm not - is 
advocating to avoid challenging false or misleading statements in the 
interests of maintaining some false see how well we all get along 
facade.  The point is we can have meaningful, hard-nosed discussions 
without resorting to personal insults, i.e. flaming.  I think the 
discussion in this topic over the past 24 hours or so demonstrates that.

-- 
 Ned Deily,
 n...@acm.org

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 18:55, Chris Angelico ros...@gmail.com wrote:
 On Fri, Mar 29, 2013 at 4:48 AM, jmfauth wxjmfa...@gmail.com wrote:
  If Python had imlemented Unicode correctly, there would
  be no difference in using an a, é, € or any character,
  what the narrow builds did.

 I'm not following your grammar perfectly here, but if Python were
 implementing Unicode correctly, there would be no difference between
 any of those characters, which is the way a *wide* build works. With a
 narrow build, there is a difference between BMP and non-BMP
 characters.

 ChrisA



The wide build (I never used) is in my mind as correct as
the narrow build. It just covers a different range in unicode
(the whole range).

Claiming that the narrow build is buggy, because it does not
cover the whole unicode is not correct.

Unicode does not stipulate, one has to cover the whole range.
Unicode expects that every character in a range behaves the same
way. This is clearly not realized with the flexible string
representation. An user should not be somehow penalized
simply because it not an ascii user.

If you take the fonts in consideration (btw a problem nobody
is speaking about) and you ensure your application, toolkit, ...
is MES-X or WGL4 compliant, your are also deliberately (and
correctly) working with a restriced unicode range.

jmf


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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Benjamin Kaplan

On Thu, Mar 28, 2013 at 10:48 AM, jmfauth wxjmfa...@gmail.com wrote:
 On 28 mar, 17:33, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wxjmfa...@gmail.com wrote:
  The flexible string representation takes the problem from the
  other side, it attempts to work with the characters by using
  their representations and it (can only) fails...

 This is false.  As I've pointed out to you before, the FSR does not
 divide characters up by representation.  It divides them up by
 codepoint -- more specifically, by the *bit-width* of the codepoint.
 We call the internal format of the string ASCII or Latin-1 or
 UCS-2 for conciseness and a point of reference, but fundamentally
 all of the FSR formats are simply byte arrays of *codepoints* -- you
 know, those things you keep harping on.  The major optimization
 performed by the FSR is to consistently truncate the leading zero
 bytes from each codepoint when it is possible to do so safely.  But
 regardless of to what extent this truncation is applied, the string is
 *always* internally just an array of codepoints, and the same
 algorithms apply for all representations.

 -

 You know, we can discuss this ad nauseam. What is important
 is Unicode.

 You have transformed Python back in an ascii oriented product.

 If Python had imlemented Unicode correctly, there would
 be no difference in using an a, é, € or any character,
 what the narrow builds did.

 If I am practically the only one, who speakes /discusses about
 this, I can ensure you, this has been noticed.

 Now, it's time to prepare the Asparagus, the jambon cru
 and a good bottle a dry white wine.

 jmf


You still have yet to explain how Python's string representation is
wrong. Just how it isn't optimal for one specific case. Here's how I
understand it:

1) Strings are sequences of stuff. Generally, we talk about strings as
either sequences of bytes or sequences of characters.

2) Unicode is a format used to represent characters. Therefore,
Unicode strings are character strings, not byte strings.

2) Encodings  are functions that map characters to bytes. They
typically also define an inverse function that converts from bytes
back to characters.

3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I
mentioned in the previous point. It happens to be one of the five
standard encodings that is defined for all characters in the Unicode
standard (the others being the little and big endian variants of
UTF-16 and UTF-32).

4) The internal representation of a character string DOES NOT MATTER.
All that matters is that the API represents it as a string of
characters, regardless of the representation. We could implement
character strings by putting the Unicode code-points in binary-coded
decimal and it would be a Unicode character string.

5) The String type that .NET and Java (and unicode type in Python
narrow builds) use is not a character string. It is a string of
shorts, each of which corresponds to a UTF-16 code point. I know this
is the case because in all of these, the length of \u1f435 is 2 even
though it only consists of one character.

6) The new string representation in Python 3.3 can successfully
represent all characters in the Unicode standard. The actual number of
bytes that each character consumes is invisible to the user.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Ethan Furman

On 03/28/2013 12:54 PM, ru...@yahoo.com wrote:

On 03/28/2013 01:48 AM, Steven D'Aprano wrote:

On Wed, 27 Mar 2013 22:42:18 -0700, rusi wrote:

For someone who delights in pointing out the logical errors
of others you are often remarkably sloppy in your own logic.

Of course language can be both helpful and excessively strong.
That is the case when language less strong would be
equally or more helpful.

It can also be the case when language less strong would be useless.

Further, liar is both so non-objective and so pejoratively
emotive that it is a word much more likely to be used by
someone interested in trolling than in a serious discussion,
so most sensible people here likely would not bite.

Non-objective? If today poster B says X, and tomorrow poster B says s/he was unaware of X until just now, is not liar
a reasonable conclusion?

I hope that we all agree that we want a nice, friendly, productive
community where everyone is welcome.

I hope so too but it is likely that some people want a place
to develop and assert some sense of influence, engage in verbal
duels, instigate arguments, etc. That can be true of regulars
here as well as drive-by posters.

But some people simply cannot or
will not behave in ways that are compatible with those community values.
There are some people whom we *do not want here*

In other words, everyone is NOT welcome.

Correct. Do you not agree?

-- spoilers and messers,
vandals and spammers and cheats and liars and trolls and crackpots of all
sorts.

Where those terms are defined by you and a handful of other
voracious posters. Troll in particular is often used to
mean someone who disagrees with the borg mind here, or who
says anything negative about Python, or who due attitude or
lack of full English fluency do not express themselves in
a sufficiently submissive way.

I cannot speak for the borg mind, but for myself a troll is anyone who continually posts rants (such as RR XL) or who
continuously hijacks threads to talk about their pet peeve (such as jmf).

We only disagree as to the best way to make it clear to them that
they are not welcome so long as they continue their behaviour.

No, we disagree on who fits those definitions and even
how tolerant we are to those who do fit the definitions.
The policing that you and a handful of other self-appointed
net-cops try to do is far more obnoxious that the original
posts are.

I completely disagree, and I am grateful to those who bother to take the time to continually point out the errors from
those posters and to warn newcomers that those posters should not be believed.

Believe or not, most of the rest of us here are smart enough to
form our own opinions of such posters without you and the other
c.l.p truthsquad members telling us what to think.

If one of my first few posts on c.l.p netted a response from a troll I would greatly appreciate a reply from one of the
regulars saying that was a troll so I didn't waste time trying to use whatever they said, or be concerned that the
language I was trying to use and learn was horribly flawed.

If the truthsquad posts are so offensive to you, why don't you kill-file them?

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

Re: Cannot run a single MySQLdb execute....

2013-03-28 Thread Alan Meyer


On 3/27/2013 11:50 PM, Νίκος Γκρ33κ wrote:

I'am about to go nuts with python 3.2.3

Do you see somehtign wrong with the following statement?

cur.execute( '''SELECT hits FROM counters WHERE url = ?''', (page,) )
data = cur.fetchone()

because as you can see by visiting my webpage at http://superhost.gr it 
produces an error and i dont have  aclue why.

Please help. i'am using MySQLdb


Nikos,

When I try to connect to that web page I see the following error message:

ImportError: No module named pymysql 

If that's what you're getting, there's nothing wrong with your SQL or 
your cur.execute statement.  The problem is that the web server is not 
finding the pymysql module.


Is pymysql installed on the computer that is running your application? 
Can the web server module find it?


I must be missing something because, if that's the problem, your object 
named cur could not have been created successfully.  Maybe what I'm 
seeing is a new problem?


Alan
--
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 21:29, Benjamin Kaplan benjamin.kap...@case.edu wrote:
 On Thu, Mar 28, 2013 at 10:48 AM, jmfauth wxjmfa...@gmail.com wrote:
  On 28 mar, 17:33, Ian Kelly ian.g.ke...@gmail.com wrote:
  On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wxjmfa...@gmail.com wrote:
   The flexible string representation takes the problem from the
   other side, it attempts to work with the characters by using
   their representations and it (can only) fails...

  This is false.  As I've pointed out to you before, the FSR does not
  divide characters up by representation.  It divides them up by
  codepoint -- more specifically, by the *bit-width* of the codepoint.
  We call the internal format of the string ASCII or Latin-1 or
  UCS-2 for conciseness and a point of reference, but fundamentally
  all of the FSR formats are simply byte arrays of *codepoints* -- you
  know, those things you keep harping on.  The major optimization
  performed by the FSR is to consistently truncate the leading zero
  bytes from each codepoint when it is possible to do so safely.  But
  regardless of to what extent this truncation is applied, the string is
  *always* internally just an array of codepoints, and the same
  algorithms apply for all representations.

  -

  You know, we can discuss this ad nauseam. What is important
  is Unicode.

  You have transformed Python back in an ascii oriented product.

  If Python had imlemented Unicode correctly, there would
  be no difference in using an a, é, € or any character,
  what the narrow builds did.

  If I am practically the only one, who speakes /discusses about
  this, I can ensure you, this has been noticed.

  Now, it's time to prepare the Asparagus, the jambon cru
  and a good bottle a dry white wine.

  jmf

 You still have yet to explain how Python's string representation is
 wrong. Just how it isn't optimal for one specific case. Here's how I
 understand it:

 1) Strings are sequences of stuff. Generally, we talk about strings as
 either sequences of bytes or sequences of characters.

 2) Unicode is a format used to represent characters. Therefore,
 Unicode strings are character strings, not byte strings.

 2) Encodings  are functions that map characters to bytes. They
 typically also define an inverse function that converts from bytes
 back to characters.

 3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I
 mentioned in the previous point. It happens to be one of the five
 standard encodings that is defined for all characters in the Unicode
 standard (the others being the little and big endian variants of
 UTF-16 and UTF-32).

 4) The internal representation of a character string DOES NOT MATTER.
 All that matters is that the API represents it as a string of
 characters, regardless of the representation. We could implement
 character strings by putting the Unicode code-points in binary-coded
 decimal and it would be a Unicode character string.

 5) The String type that .NET and Java (and unicode type in Python
 narrow builds) use is not a character string. It is a string of
 shorts, each of which corresponds to a UTF-16 code point. I know this
 is the case because in all of these, the length of \u1f435 is 2 even
 though it only consists of one character.

 6) The new string representation in Python 3.3 can successfully
 represent all characters in the Unicode standard. The actual number of
 bytes that each character consumes is invisible to the user.

--


I shew enough examples. As soon as you are using non latin-1 chars
your optimization just became irrelevant and not only this, you
are penalized.

I'm sorry, saying Python now is just covering the whole unicode
range is not a valuable excuse. I prefer a correct version with
a narrower range of chars, especially if this range represents
the daily used chars.

I can go a step further, if I wish to write an application for
Western European users, I'm better served if I'm using a coding
scheme covering all thesee languages/scripts. What about cp1252 [*]?
Does this not remind somthing?

Python can do better, it only succeeds to do worth!

[*] yes, I kwnow, internally 

jmf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On 28 mar, 22:11, jmfauth wxjmfa...@gmail.com wrote:
 On 28 mar, 21:29, Benjamin Kaplan benjamin.kap...@case.edu wrote:









  On Thu, Mar 28, 2013 at 10:48 AM, jmfauth wxjmfa...@gmail.com wrote:
   On 28 mar, 17:33, Ian Kelly ian.g.ke...@gmail.com wrote:
   On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wxjmfa...@gmail.com wrote:
The flexible string representation takes the problem from the
other side, it attempts to work with the characters by using
their representations and it (can only) fails...

   This is false.  As I've pointed out to you before, the FSR does not
   divide characters up by representation.  It divides them up by
   codepoint -- more specifically, by the *bit-width* of the codepoint.
   We call the internal format of the string ASCII or Latin-1 or
   UCS-2 for conciseness and a point of reference, but fundamentally
   all of the FSR formats are simply byte arrays of *codepoints* -- you
   know, those things you keep harping on.  The major optimization
   performed by the FSR is to consistently truncate the leading zero
   bytes from each codepoint when it is possible to do so safely.  But
   regardless of to what extent this truncation is applied, the string is
   *always* internally just an array of codepoints, and the same
   algorithms apply for all representations.

   -

   You know, we can discuss this ad nauseam. What is important
   is Unicode.

   You have transformed Python back in an ascii oriented product.

   If Python had imlemented Unicode correctly, there would
   be no difference in using an a, é, € or any character,
   what the narrow builds did.

   If I am practically the only one, who speakes /discusses about
   this, I can ensure you, this has been noticed.

   Now, it's time to prepare the Asparagus, the jambon cru
   and a good bottle a dry white wine.

   jmf

  You still have yet to explain how Python's string representation is
  wrong. Just how it isn't optimal for one specific case. Here's how I
  understand it:

  1) Strings are sequences of stuff. Generally, we talk about strings as
  either sequences of bytes or sequences of characters.

  2) Unicode is a format used to represent characters. Therefore,
  Unicode strings are character strings, not byte strings.

  2) Encodings  are functions that map characters to bytes. They
  typically also define an inverse function that converts from bytes
  back to characters.

  3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I
  mentioned in the previous point. It happens to be one of the five
  standard encodings that is defined for all characters in the Unicode
  standard (the others being the little and big endian variants of
  UTF-16 and UTF-32).

  4) The internal representation of a character string DOES NOT MATTER.
  All that matters is that the API represents it as a string of
  characters, regardless of the representation. We could implement
  character strings by putting the Unicode code-points in binary-coded
  decimal and it would be a Unicode character string.

  5) The String type that .NET and Java (and unicode type in Python
  narrow builds) use is not a character string. It is a string of
  shorts, each of which corresponds to a UTF-16 code point. I know this
  is the case because in all of these, the length of \u1f435 is 2 even
  though it only consists of one character.

  6) The new string representation in Python 3.3 can successfully
  represent all characters in the Unicode standard. The actual number of
  bytes that each character consumes is invisible to the user.

 --

 I shew enough examples. As soon as you are using non latin-1 chars
 your optimization just became irrelevant and not only this, you
 are penalized.

 I'm sorry, saying Python now is just covering the whole unicode
 range is not a valuable excuse. I prefer a correct version with
 a narrower range of chars, especially if this range represents
 the daily used chars.

 I can go a step further, if I wish to write an application for
 Western European users, I'm better served if I'm using a coding
 scheme covering all thesee languages/scripts. What about cp1252 [*]?
 Does this not remind somthing?

 Python can do better, it only succeeds to do worth!

 [*] yes, I kwnow, internally 

 jmf

-

Addendum.

And you kwow what? Py34 will suffer from the same desease.
You are spending your time in improving chunks of bytes,
when the problem is elsewhere.
In fact you are working for peanuts, eg the replacing method.


If you are not satisfied with my examples, just pick up
the examples of GvR (ascii-string) on the bug tracker, timeit
them and you will see there is already a problem.

Better, timeit them afeter having replaced his ascii-strings
with non ascii characters...

jmf

and you will see, there is
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Fri, Mar 29, 2013 at 7:26 AM, jmfauth wxjmfa...@gmail.com wrote:
 The wide build (I never used) is in my mind as correct as
 the narrow build. It just covers a different range in unicode
 (the whole range).

Actually it does; it covers all of the Unicode range, by using
(effectively) UTF-16. Characters that cannot be represented in one
16-bit number are represented in two. That's not just covering a
different range. It's being buggy. And it's creating a way for code to
unexpectedly behave fundamentally differently on Windows and Linux
(since the most common builds for Windows were narrow and for Linux
were wide). This is a Bad Thing for Python.

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread MRAB


On 28/03/2013 21:11, jmfauth wrote:

On 28 mar, 21:29, Benjamin Kaplan benjamin.kap...@case.edu wrote:

On Thu, Mar 28, 2013 at 10:48 AM, jmfauth wxjmfa...@gmail.com wrote:
 On 28 mar, 17:33, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wxjmfa...@gmail.com wrote:
  The flexible string representation takes the problem from the
  other side, it attempts to work with the characters by using
  their representations and it (can only) fails...

 This is false.  As I've pointed out to you before, the FSR does not
 divide characters up by representation.  It divides them up by
 codepoint -- more specifically, by the *bit-width* of the codepoint.
 We call the internal format of the string ASCII or Latin-1 or
 UCS-2 for conciseness and a point of reference, but fundamentally
 all of the FSR formats are simply byte arrays of *codepoints* -- you
 know, those things you keep harping on.  The major optimization
 performed by the FSR is to consistently truncate the leading zero
 bytes from each codepoint when it is possible to do so safely.  But
 regardless of to what extent this truncation is applied, the string is
 *always* internally just an array of codepoints, and the same
 algorithms apply for all representations.

 -

 You know, we can discuss this ad nauseam. What is important
 is Unicode.

 You have transformed Python back in an ascii oriented product.

 If Python had imlemented Unicode correctly, there would
 be no difference in using an a, é, € or any character,
 what the narrow builds did.

 If I am practically the only one, who speakes /discusses about
 this, I can ensure you, this has been noticed.

 Now, it's time to prepare the Asparagus, the jambon cru
 and a good bottle a dry white wine.

 jmf

You still have yet to explain how Python's string representation is
wrong. Just how it isn't optimal for one specific case. Here's how I
understand it:

1) Strings are sequences of stuff. Generally, we talk about strings as
either sequences of bytes or sequences of characters.

2) Unicode is a format used to represent characters. Therefore,
Unicode strings are character strings, not byte strings.

2) Encodings  are functions that map characters to bytes. They
typically also define an inverse function that converts from bytes
back to characters.

3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I
mentioned in the previous point. It happens to be one of the five
standard encodings that is defined for all characters in the Unicode
standard (the others being the little and big endian variants of
UTF-16 and UTF-32).

4) The internal representation of a character string DOES NOT MATTER.
All that matters is that the API represents it as a string of
characters, regardless of the representation. We could implement
character strings by putting the Unicode code-points in binary-coded
decimal and it would be a Unicode character string.

5) The String type that .NET and Java (and unicode type in Python
narrow builds) use is not a character string. It is a string of
shorts, each of which corresponds to a UTF-16 code point. I know this
is the case because in all of these, the length of \u1f435 is 2 even
though it only consists of one character.

6) The new string representation in Python 3.3 can successfully
represent all characters in the Unicode standard. The actual number of
bytes that each character consumes is invisible to the user.


--


I shew enough examples. As soon as you are using non latin-1 chars
your optimization just became irrelevant and not only this, you
are penalized.

I'm sorry, saying Python now is just covering the whole unicode
range is not a valuable excuse. I prefer a correct version with
a narrower range of chars, especially if this range represents
the daily used chars.

I can go a step further, if I wish to write an application for
Western European users, I'm better served if I'm using a coding
scheme covering all thesee languages/scripts. What about cp1252 [*]?
Does this not remind somthing?

Python can do better, it only succeeds to do worth!

[*] yes, I kwnow, internally 


If you're that concerned about it, why don't you modify the source code so
that the string representation chooses between only 2 bytes and 4 bytes per
codepoint, and then see whether that you prefer that situation. How do
the memory usage and speed compare?
--
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Benjamin Kaplan

On Thu, Mar 28, 2013 at 2:11 PM, jmfauth wxjmfa...@gmail.com wrote:
 On 28 mar, 21:29, Benjamin Kaplan benjamin.kap...@case.edu wrote:
 On Thu, Mar 28, 2013 at 10:48 AM, jmfauth wxjmfa...@gmail.com wrote:
  On 28 mar, 17:33, Ian Kelly ian.g.ke...@gmail.com wrote:
  On Thu, Mar 28, 2013 at 7:34 AM, jmfauth wxjmfa...@gmail.com wrote:
   The flexible string representation takes the problem from the
   other side, it attempts to work with the characters by using
   their representations and it (can only) fails...

  This is false.  As I've pointed out to you before, the FSR does not
  divide characters up by representation.  It divides them up by
  codepoint -- more specifically, by the *bit-width* of the codepoint.
  We call the internal format of the string ASCII or Latin-1 or
  UCS-2 for conciseness and a point of reference, but fundamentally
  all of the FSR formats are simply byte arrays of *codepoints* -- you
  know, those things you keep harping on.  The major optimization
  performed by the FSR is to consistently truncate the leading zero
  bytes from each codepoint when it is possible to do so safely.  But
  regardless of to what extent this truncation is applied, the string is
  *always* internally just an array of codepoints, and the same
  algorithms apply for all representations.

  -

  You know, we can discuss this ad nauseam. What is important
  is Unicode.

  You have transformed Python back in an ascii oriented product.

  If Python had imlemented Unicode correctly, there would
  be no difference in using an a, é, € or any character,
  what the narrow builds did.

  If I am practically the only one, who speakes /discusses about
  this, I can ensure you, this has been noticed.

  Now, it's time to prepare the Asparagus, the jambon cru
  and a good bottle a dry white wine.

  jmf

 You still have yet to explain how Python's string representation is
 wrong. Just how it isn't optimal for one specific case. Here's how I
 understand it:

 1) Strings are sequences of stuff. Generally, we talk about strings as
 either sequences of bytes or sequences of characters.

 2) Unicode is a format used to represent characters. Therefore,
 Unicode strings are character strings, not byte strings.

 2) Encodings  are functions that map characters to bytes. They
 typically also define an inverse function that converts from bytes
 back to characters.

 3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I
 mentioned in the previous point. It happens to be one of the five
 standard encodings that is defined for all characters in the Unicode
 standard (the others being the little and big endian variants of
 UTF-16 and UTF-32).

 4) The internal representation of a character string DOES NOT MATTER.
 All that matters is that the API represents it as a string of
 characters, regardless of the representation. We could implement
 character strings by putting the Unicode code-points in binary-coded
 decimal and it would be a Unicode character string.

 5) The String type that .NET and Java (and unicode type in Python
 narrow builds) use is not a character string. It is a string of
 shorts, each of which corresponds to a UTF-16 code point. I know this
 is the case because in all of these, the length of \u1f435 is 2 even
 though it only consists of one character.

 6) The new string representation in Python 3.3 can successfully
 represent all characters in the Unicode standard. The actual number of
 bytes that each character consumes is invisible to the user.

 --


 I shew enough examples. As soon as you are using non latin-1 chars
 your optimization just became irrelevant and not only this, you
 are penalized.

 I'm sorry, saying Python now is just covering the whole unicode
 range is not a valuable excuse. I prefer a correct version with
 a narrower range of chars, especially if this range represents
 the daily used chars.

 I can go a step further, if I wish to write an application for
 Western European users, I'm better served if I'm using a coding
 scheme covering all thesee languages/scripts. What about cp1252 [*]?
 Does this not remind somthing?

 Python can do better, it only succeeds to do worth!

 [*] yes, I kwnow, internally 

 jmf

By that logic, we should all be using ASCII because it's correct for
the 127 characters that I (as an English speaker) use, and therefore
it's all that we should care about. I don't care if é counts as two
characters, it's faster and more memory efficient for all of my
strings to just count bytes. There are certain domains where
characters outside the basic multilingual plane are used. Python's job
is to be correct in all of those circumstances, not just the ones you
care about.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sudoku

2013-03-28 Thread Eric Parry

On Thursday, March 28, 2013 3:06:02 PM UTC+10:30, Dave Angel wrote:
 On 03/27/2013 11:00 PM, Eric Parry wrote:
 
  On Wednesday, March 27, 2013 6:28:01 PM UTC+10:30, Ulrich Eckhardt wrote:
 
 
 
   SNIP the double-spaced garbage that GoogleGroups put in - see 
 
 http://wiki.python.org/moin/GoogleGroupsPython 
 
 
 
  Thank you for your explanation.
 
  I noticed that in this particular puzzle when it ran out of candidates in a 
  particular cycle, it then changed the last entry to the next one in line in 
  the previous cycle. But I cannot find any code to do this.
 
  I was hoping to understand the logic so that I could re-write it in VBA for 
  excel which would enable any puzzle to be entered directly.
 
  Your comments are a big help especially the double negative aspect.
 
 
 
 
 
 Are you familiar with recursion?  Notice the last line in the function 
 
 r() calls the function r() inside a for loop.
 
 
 
 So when r() returns, you're back inside the next level up of the 
 
 function, and doing a backtrack.
 
 
 
 When the function succeeds, it will be many levels of recursion deep. 
 
 For example, if the original pattern had 30 nonzero items in it, or 51 
 
 zeroes, you'll be 51 levels of recursion when you discover a solution.
 
 
 
 If you don't already understand recursion at all, then say so, and one 
 
 or more of us will try to explain it in more depth.
 
 
 
 -- 
 
 DaveA

Thank you for that explanation.
No, I do not understand recursion. It is missing from my Python manual. I would 
be pleased to receive further explanation from anyone.
Eric.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread 88888 Dihedral

Chris Angelico於 2013年3月28日星期四UTC+8上午11時40分17秒寫道：
 On Thu, Mar 28, 2013 at 2:18 PM, Ethan Furman et...@stoneleaf.us wrote:
 
  Has anybody else thought that [jmf's] last few responses are starting to 
  sound
 
  bot'ish?
 
 
 
 Yes, I did wonder. It's like he and Dihedral have been trading
 
 accounts sometimes. Hey, Dihedral, I hear there's a discussion of
 
 Unicode and PEP 393 and Python 3.3 and Unicode and lots of keywords
 
 for you to trigger on and Python and bots are funny and this text is
 
 almost grammatical!
 
 
 
 There. Let's see if he takes the bait.
 
 
 
 ChrisA

Well, we need some cheap ram to hold 4 bytes per character 

in a text segment to be observed. 

For those not to be observed or shown, the old way still works.

Windows got this job done right to collect taxes in areas 
of different languages.

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Terry Reedy


On 3/28/2013 4:26 PM, jmfauth wrote:

Please provide references for your assertions. I have read the unicode 
standard, parts more than once, and your assertions contradict my memory.



Unicode does not stipulate, one has to cover the whole range.


I believe it does. As I remember, the recognized encodings all encode 
the entire unicode codepoint range



Unicode expects that every character in a range behaves the same
way.


I have no idea what you mean by 'same way'. Each codepoint is supposed 
to behave differently in some way. That is the reason for having 
multiple codepoints. One causes an 'a' to appear, another a 'b'. Indeed, 
the standard define multiple categories of codepoints and chars in 
different categories are supposed to act differently (or be treated 
differently). Glyphic chars versus control chars are one example.


--
Terry Jan Reedy

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

Re: Sudoku

2013-03-28 Thread Dave Angel


On 03/28/2013 06:11 PM, Eric Parry wrote:

On Thursday, March 28, 2013 3:06:02 PM UTC+10:30, Dave Angel wrote:



   SNIP



Are you familiar with recursion?  Notice the last line in the function
r() calls the function r() inside a for loop.

So when r() returns, you're back inside the next level up of the
function, and doing a backtrack.

When the function succeeds, it will be many levels of recursion deep.
For example, if the original pattern had 30 nonzero items in it, or 51
zeroes, you'll be 51 levels of recursion when you discover a solution.

If you don't already understand recursion at all, then say so, and one
or more of us will try to explain it in more depth.


  SNIP


Thank you for that explanation.
No, I do not understand recursion. It is missing from my Python manual. I would 
be pleased to receive further explanation from anyone.
Eric.



Recursion is not limited to Python.  It's a general programming term, 
and indeed applies in other situations as well.  Suppose you wanted to 
explain what the -r switch meant in the cp command.  r stands for 
recursion.


(example is from Linux.  But if you're more familiar with Windows, it's 
the /s switch in the DIR command.)


The cp command copies all the matching files in one directory to another 
one.  If the -r switch is specified, it then does the same thing to each 
subdirectory.


Notice we did NOT have to specify sub-subdirectories, since they're 
recursively implied by the first description.



Closer to the current problem, suppose you defined factorial in the 
following way:  factorial(0) is 1, by definition.  And for all n0, 
factorial(n) is n*factorial(n-1).


So to directly translate this definition to code, you write a function 
factorial() which takes an integer and returns an integer.  If the 
parameter is zero, return one.  If the parameter is bigger than zero, 
then the function calls itself with a smaller integer, building up the 
answer as needed  (untested).


def  factorial(n):
if n==0:
return 1
val = n *factorial(n-1)
return val




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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Fri, Mar 29, 2013 at 10:53 AM, Dennis Lee Bieber
wlfr...@ix.netcom.com wrote:
 On Wed, 27 Mar 2013 23:12:21 -0700, Ethan Furman et...@stoneleaf.us
 declaimed the following in gmane.comp.python.general:


 At some point we have to stop being gentle / polite / politically correct 
 and call a shovel a shovel... er, spade.

 Call it an Instrument For the Transplantation of Dirt

 (Is an antique Steam Shovel ever a Steam Spade?)

I don't know, but I'm pretty sure there's a private detective who
wouldn't appreciate being called Sam Shovel.

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

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

2013-03-28 Thread Mark Lawrence


On 28/03/2013 23:53, Dennis Lee Bieber wrote:

On Wed, 27 Mar 2013 23:12:21 -0700, Ethan Furman et...@stoneleaf.us
declaimed the following in gmane.comp.python.general:



At some point we have to stop being gentle / polite / politically correct and 
call a shovel a shovel... er, spade.


Call it an Instrument For the Transplantation of Dirt

(Is an antique Steam Shovel ever a Steam Spade?)



Surely you can spade a lot more things than dirt?

--
If you're using GoogleCrap™ please read this 
http://wiki.python.org/moin/GoogleGroupsPython.


Mark Lawrence

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

Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]]

On Thu, 28 Mar 2013 10:11:59 -0600, Ian Kelly wrote:

 On Thu, Mar 28, 2013 at 8:38 AM, Chris Angelico ros...@gmail.com
 wrote:
 PEP393 strings have two optimizations, or kinda three:

 1a) ASCII-only strings
 1b) Latin1-only strings
 2) BMP-only strings
 3) Everything else

 Options 1a and 1b are almost identical - I'm not sure what the detail
 is, but there's something flagging those strings that fit inside seven
 bits. (Something to do with optimizing encodings later?) Both are
 optimized down to a single byte per character.
 
 The only difference for ASCII-only strings is that they are kept in a
 struct with a smaller header.  The smaller header omits the utf8 pointer
 (which optionally points to an additional UTF-8 representation of the
 string) and its associated length variable.  These are not needed for
 ASCII-only strings because an ASCII string can be directly interpreted
 as a UTF-8 string for the same result.  The smaller header also omits
 the wstr_length field which, according to the PEP, differs from
 length only if there are surrogate pairs in the representation.  For an
 ASCII string, of course there would not be any surrogate pairs.


I wonder why they need care about surrogate pairs? 

ASCII and Latin-1 strings obviously do not have them. Nor do BMP-only 
strings. It's only strings in the SMPs that could need surrogate pairs, 
and they don't need them in Python's implementation since it's a full 32-
bit implementation. So where do the surrogate pairs come into this?

I also wonder why the implementation bothers keeping a UTF-8 
representation. That sounds like premature optimization to me. Surely you 
only need it when writing to a file with UTF-8 encoding? For most 
strings, that will never happen.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]

On Thu, 28 Mar 2013 12:54:20 -0700, rurpy wrote:

 Even if you personally would prefer someone to respond by calling you a
 liar, your personal preferences do not form a basis for desirable
 posting behavior here.

Whereas yours apparently are.

Thanks for the feedback, I'll take it under advisement.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]]