date:20130627

On Thursday, June 27, 2013 12:35:14 PM UTC+5:30, Russel Walker wrote:
 On Thursday, June 27, 2013 6:19:18 AM UTC+2, Thrinaxodon wrote:
snipped
 I was hoping to have a good laugh. :|
 Although I wouldn't call it hostile.

I think the python community is being educated in how to spam and troll at the 
same time.
-- 
http://mail.python.org/mailman/listinfo/python-list

looking for a linguistical/semiotic quote

I am looking for a quote 
(from Whorf/Sapir/Wittgenstein/Humboldt dunno... that 'school')

It goes something like this:

What characterizes a language is not what we can say in it but what we must -- 
like it or not -- say.


A demo of this is D Hofstadter's 
http://www.cs.virginia.edu/~evans/cs655/readings/purity.html
which by inverting sexist/racist assumptions in English, makes for a hilarious 
read.

No I am not talking politics here, just want some references for a programming 
course in which I want to point out that

- C programmers need to talk memory-mgmt whether they want to or not
- Java programmers need to talk objects/classes likewise
etc

I believe I may have seen that quote here so asking...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: looking for a linguistical/semiotic quote

2013-06-27 Thread Chris Angelico

On Thu, Jun 27, 2013 at 9:14 PM, rusi rustompm...@gmail.com wrote:
 I am looking for a quote
 (from Whorf/Sapir/Wittgenstein/Humboldt dunno... that 'school')

 It goes something like this:

 What characterizes a language is not what we can say in it but what we must 
 -- like it or not -- say.

I think you may be looking for Larry Wall's statement in his State of
the Onion talk:

http://www.perl.com/pub/2007/12/06/soto-11.html

He's comparing human and programming languages and says pretty much
what you're saying. Of couse, he's probably not the first person to
have made that remark in some form or another... so you may still be
looking for someone else.

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

Re: looking for a linguistical/semiotic quote

On Thursday, June 27, 2013 4:49:23 PM UTC+5:30, Chris Angelico wrote:
 On Thu, Jun 27, 2013 at 9:14 PM, rusi  wrote:
 
  I am looking for a quote
  (from Whorf/Sapir/Wittgenstein/Humboldt dunno... that 'school')
 
  It goes something like this:
 
  What characterizes a language is not what we can say in it but what we must 
  -- like it or not -- say.
 
 I think you may be looking for Larry Wall's statement in his State of
 the Onion talk: 
 
 http://www.perl.com/pub/2007/12/06/soto-11.html
 
 He's comparing human and programming languages and says pretty much
 what you're saying. Of couse, he's probably not the first person to
 have made that remark in some form or another... so you may still be
 looking for someone else.

Thanks. Here's the quote:

 Human languages therefore differ not so much in what you can say but in what 
 you must say. In English, you are forced to differentiate singular from 
 plural. In Japanese, you don't have to distinguish singular from plural, but 
 you do have to pick a specific level of politeness, taking into account not 
 only your degree of respect for the person you're talking to, but also your 
 degree of respect for the person or thing you're talking about.

I am still not sure he is the originator of it
If yes then he has my (single-valenced English) respect
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: looking for a linguistical/semiotic quote

2013-06-27 Thread Vlastimil Brom

2013/6/27 rusi rustompm...@gmail.com:
 I am looking for a quote
 (from Whorf/Sapir/Wittgenstein/Humboldt dunno... that 'school')

 It goes something like this:

 What characterizes a language is not what we can say in it but what we must 
 -- like it or not -- say.
 [...]

Hi,
I belive, the author is Roman Jakobson, see the respective post about
this very question:
http://linguistlist.org/issues/9/9-32.html

There seem to be several variations,
Another remarkable linguist Eugenio Coseriu mentions this in his paper
(Sprache: Strukturen und Funktionen ... Tübingen 1979, p. 119).
The German text is besides mentioning Jakobson almost fully equivalent
to you original quote:
R. Jakobson bemerkt mit Recht, daß sich die Sprachen nicht durch das,
was sie sagen können, unterscheiden, sondern durch das, was sie sagen
müssen.

http://books.google.cz/books?id=JkGCkC8RYcEC
p. 119

hth,
  vbr
-- 
http://mail.python.org/mailman/listinfo/python-list

?????? FACTS: WHY THE PYTHON LANGUAGE FAILS.

2013-06-27 Thread jj

If you insist it fails, JUST DO NOT USE IT or you create a better language.
don't just bother, it does no good.


 




--  --
??: Ben Finneyben+pyt...@benfinney.id.au;
: 2013??6??27??(??) 1:37
??: python-listpython-list@python.org; 

: Re: FACTS: WHY THE PYTHON LANGUAGE FAILS.



Thrinaxodon biolo...@yahoo.com writes:

 [?? strange fictitious dialogue ??]
 THRINAXODON IS NOW ON TWITTER.

Thrinaxodon should not bother to post such hostility here again.

-- 
 \  ??I don't want to live peacefully with difficult realities, and |
  `\ I see no virtue in savoring excuses for avoiding a search for |
_o__)real answers.?? ??Paul Z. Myers, 2009-09-12 |
Ben Finney

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

Re: Don't feed the troll...

2013-06-27 Thread Antoon Pardon


Op 25-06-13 19:25, Ian Kelly schreef:

On Mon, Jun 24, 2013 at 7:37 AM, Antoon Pardon
antoon.par...@rece.vub.ac.be  wrote:

What do you mean with not a participant in the past? As far
as I can see his first appearance was in dec 2011. That is
over a year ago. It also seems that he always find people
willing to engage with him. Is how the group treats him
not also an aspect in deciding whether he belongs or not?


Although it's true that he's been around for a while, it has in my
mind only been very recently that his posts have started to become a
problem.


Fine. All the more reason to regard him as part of the group rather
than outside the group IMO.

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

Re: Don't feed the troll...

2013-06-27 Thread Ian Kelly

On Wed, Jun 26, 2013 at 1:46 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
 But you didn't even go to the trouble of trying to find out
 what those concerns would be and how strong people feel about
 them. You just took your assumptions about those concerns for
 granted and proceeded from there.

Jumping back in here, I for one don't give a hoot about their
concerns, beyond the basic assumption that they feel the same way I do
about Nikos' threads and wish that he would leave.  I just want to
maintain a positive and welcoming atmosphere around here.  I expect
that most of the posters here are adults and can fend for themselves
regarding their own concerns, and I'm not interested in being the list
mom.  You on the other hand seem to want to treat the list like a
playground.  If that's what you want to do, then by all means go for
it; just leave me out of it.

 If you need some sort of public show, then I will publicly
 state that I too have been very frustrated with many of
 Nikos' posts and I am greatly sympathetic to the desire to
 tell the SOB to go take a flying fuck.  That not withstanding
 I believe that responding that way does not help anything
 and is destructive.


 You really should learn the difference between telling and showing.

Copy...

 Why should I care about the rational you gave. It is based on
 your own assumptions, on how you weight the possible outcomes against
 each other. Someone who doesn't care about trolls or even may
 enjoy observing a heated exchange may come to an entirely different
 conclusion on what behaviour is good for the group in case he
 extrapolated his own preferences on the group.

 And you may not have purposely made things up to justify your
 proposal, but how you went about it, that is probably what you
 actually did. Because that is what we as humans generally do
 in this kind of situations.

Made things up?  This response to the situation is not just our own
assumptions at work, but the collective experience of the Internet,
going back decades.

http://rationalwiki.org/wiki/Don%27t_feed_the_Troll

 Now as far as I am concerned you can be as blunt as you want to
 be. I just don't understand why you think you should be so
 careful to Nikos, while at the same time you saw no need for
 careful wording here.

Nobody is suggesting that we should make any effort to try to avoid
hurting Nikos' feelings, contrary to what you seem to be implying
here.  Be as blunt as you want with him, but please recognize that
troll baiting /does not work/ as a means of making the troll go away
and only serves to further degrade the list.

Nor do I think that it is a bad thing to be blunt about it with those
who are dampening the environment.  As I said above, the posters here
are mostly adults, most of whom I think are not so emotionally fragile
that they would wilt because of a simple reprimand on the Internet (or
if they really /can't/ take it, then perhaps they should have thought
about that before they started dishing it).

 Your argument is next to useless. You rarely make people change behaviour by
 showing your argument is correct. If your goal is influencing people into
 behaving more as you would like, focussing
 on your argument instead of empathising on their frustration is
 more likely to antagonise the people whose behaviour you would
 like to change than to get them to cooperate.

...paste.

You really should learn the difference between telling and showing.

 Second, I *am* concerned in that I find a lot of Nikos's responses
 frustrating and I realize other people feel the same.

 Stop telling you are concerned. Start showing.

How?  By joining in with the flaming and being just as
counter-productive?  I'm not going to try to show my concern because
it is not important to me whether others can see it.

 But that
 does not mean that giving into emotion and filling this group
 up with all sort of negative hostile hate-mail is the right thing
 to do.  Silence is a better option overall (IMO).  There are three
 decades of internet experience that agree.

 Do you have mumbers on that? Otherwise those three decades of internet
 don't mean much.

The only actual study on the topic that I'm aware of is this one:

http://www.guardian.co.uk/education/2011/jun/13/internet-trolls-improbable-research
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: looking for a linguistical/semiotic quote

On Thursday, June 27, 2013 5:40:39 PM UTC+5:30, Vlastimil Brom wrote:
 Hi,
 
 I belive, the author is Roman Jakobson, see the respective post about
 this very question:
 http://linguistlist.org/issues/9/9-32.html

Thanks!

 
 There seem to be several variations,
 Another remarkable linguist Eugenio Coseriu mentions this in his paper
 (Sprache: Strukturen und Funktionen ... Tübingen 1979, p. 119).
 
 The German text is besides mentioning Jakobson almost fully equivalent
 
 to you original quote:
 R. Jakobson bemerkt mit Recht, daß sich die Sprachen nicht durch das,
 was sie sagen können, unterscheiden, sondern durch das, was sie sagen
 müssen.
 
 http://books.google.cz/books?id=JkGCkC8RYcEC
 p. 119

My German does not go way beyond: Vielen Dank (for the first)!
-- 
http://mail.python.org/mailman/listinfo/python-list

Why is the argparse module so inflexible?

2013-06-27 Thread Andrew Berg

I've begun writing a program with an interactive prompt, and it needs to parse 
input from the user. I thought the argparse module would be
great for this, but unfortunately it insists on calling sys.exit() at any sign 
of trouble instead of letting its ArgumentError exception
propagate so that I can handle it. Overriding ArgumentParser.error doesn't 
really help since methods like parse_known_args just send a
message to be relayed to the user as an argument after swallowing ArgumentError 
(which does have useful information in its attributes). If I
wanted to figure out what actually caused the exception to be raised, I'd have 
to parse the message, which is ugly at best. I understand
that most people do want argparse to just display a message and terminate if 
the arguments supplied aren't useful, but there's a lot of
potential in the module that is crippled outside the main use case. I have to 
wonder why a module that is meant to be imported would ever
call sys.exit(), even if that is what the caller would normally do if presented 
with an exception.
-- 
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Limit Lines of Output

2013-06-27 Thread Joshua Landau

On 27 June 2013 00:57, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 On Wed, 26 Jun 2013 10:09:13 -0700, rusi wrote:

 On Wednesday, June 26, 2013 8:54:56 PM UTC+5:30, Joshua Landau wrote:
 On 25 June 2013 22:48, Gene Heskett  wrote:
  On Tuesday 25 June 2013 17:47:22 Joshua Landau did opine:

 I did not.

 I guess Joshua is saying that saying ≠ opining

 But it is. From WordNet:

 opine
 v 1: express one's opinion openly and without fear or
  hesitation; John spoke up at the meeting [syn: opine,
  speak up, speak out, animadvert, sound off]

To give context;

On 25 June 2013 22:48, Gene Heskett ghesk...@wdtv.com (incorrectly) wrote:
 On Tuesday 25 June 2013 17:47:22 Joshua Landau did opine:

  On 25 June 2013 21:22, Bryan Britten britten.br...@gmail.com wrote:
   Ah, I always forget to mention my OS on these forums. I'm running
   Windows.
 
  Supposedly, Windows has more
  [http://superuser.com/questions/426226/less-or-more-in-windows],

 Yes, but less is more than more.

  For Linux+less; this works:
 
  from subprocess import Popen, PIPE
  less = Popen(less, stdin=PIPE)
  less.stdin.write(b\n.join(This is line number
  {}.format(i).encode(UTF-8) for i in range(1000)))
  less.wait()

As you can see, my quoted text contained no *opinions*, at least of
the nuance that opine refers to.

 Admittedly we cannot tell what Joshua's mental state was at the time he
 responded to Bryan, he may have been absolutely terrified for all we
 know, but there's no sign of this fear, and no reason to think that he
 hesitated, given that his response came through a mere nine minutes after
 Bryan's comment.

That's taking a very analytic turn...

To clarify; I did have little hesitation but that was not the grounds
to my objection.

 Or if you prefer the Collaborative International Dictionary of English:

 Opine \O*pine\, v. t.  i. [imp.  p. p. Opined; p. pr.  vb.
n. Opining.] [L. opinari, p. p. opinatus; akin to opinus
(in comp.) thinking, and perh. to E. apt: cf. F. opiner.]
To have an opinion; to judge; to think; to suppose. --South.
[1913 Webster]

As this accurately sums up, to opine requires one to judge in some
form, or to be opinionated; these are not things I did; I rather
just referenced someone's work without openly judging it and stated
(objectively so, you shall find) that some code worked.

 [Or is he opining?]

 That's just his opinion, man.

 *wink*


--

(I wasn't expecting this to spawn so much discourse.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FACTS: WHY THE PYTHON LANGUAGE FAILS.

2013-06-27 Thread Ian


On 27/06/2013 11:52, rusi wrote:

On Thursday, June 27, 2013 12:35:14 PM UTC+5:30, Russel Walker wrote:

On Thursday, June 27, 2013 6:19:18 AM UTC+2, Thrinaxodon wrote:

snipped

I was hoping to have a good laugh. :|
Although I wouldn't call it hostile.

I think the python community is being educated in how to spam and troll at the 
same time.

I to have problems spolling.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Joshua Landau

On 27 June 2013 13:54, Andrew Berg robotsondr...@gmail.com wrote:
 I've begun writing a program with an interactive prompt, and it needs to 
 parse input from the user. I thought the argparse module would be
 great for this, but unfortunately it insists on calling sys.exit() at any 
 sign of trouble instead of letting its ArgumentError exception
 propagate so that I can handle it. Overriding ArgumentParser.error doesn't 
 really help since methods like parse_known_args just send a
 message to be relayed to the user as an argument after swallowing 
 ArgumentError (which does have useful information in its attributes). If I
 wanted to figure out what actually caused the exception to be raised, I'd 
 have to parse the message, which is ugly at best. I understand
 that most people do want argparse to just display a message and terminate if 
 the arguments supplied aren't useful, but there's a lot of
 potential in the module that is crippled outside the main use case. I have to 
 wonder why a module that is meant to be imported would ever
 call sys.exit(), even if that is what the caller would normally do if 
 presented with an exception.

 import sys
 try: sys.exit()
... except SystemExit: pass
...


That said, you might want to try docopt [http://docopt.org/] if you
have qualms with ArgParse.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Roy Smith

In article mailman.3924.1372337705.3114.python-l...@python.org,
 Andrew Berg robotsondr...@gmail.com wrote:

 I've begun writing a program with an interactive prompt, and it needs to 
 parse input from the user. I thought the argparse module would be
 great for this, but unfortunately it insists on calling sys.exit() at any 
 sign of trouble instead of letting its ArgumentError exception
 propagate so that I can handle it.

 [...] there's a lot of potential in the module that is crippled 
 outside the main use case.

Having used (and written) a number of different ways of dealing with CLI 
parsing (in several languages), I can tell you that argparse is pretty 
cool.  CLI parsing is amazingly complicated.  Argparse turns that into a 
job which is only moderately complicated and slightly annoying.  
Compared to the alternatives, that's a big win.

Can you give us a concrete example of what you're trying to do?

You might look into type=.  It's normally used for things like 
type=int or type=float, but it could give it any user-defined 
function as a type and this essentially becomes a hook to insert your 
own code into the middle of the processing.  Sometimes that can be 
warped into doing all sorts of useful things.
-- 
http://mail.python.org/mailman/listinfo/python-list

خطاب الرئيس محمد مرسي كاملا يوم 26-6-2013

2013-06-27 Thread 23alagmy

خطاب الرئيس محمد مرسي كاملا يوم 26-6-2013

https://www.facebook.com/pages/%D9%86%D8%AA%D8%A7%D8%A6%D8%AC-%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AD%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%AC%D8%A7%D9%85%D8%B9%D8%A7%D8%AA-%D9%88%D8%A7%D8%AC%D8%AA%D9%85%D8%A7%D8%B9%D9%8A%D8%A7%D8%AA/299719160065550?ref=hl
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class factory question

2013-06-27 Thread Joshua Landau

On 26 June 2013 14:09, Tim jtim.arn...@gmail.com wrote:
 I am extending a parser and need to create many classes that are all 
 subclassed from the same object (defined in an external library).  When my 
 module is loaded I need all the classes to be created with a particular name 
 but the behavior is all the same. Currently I have a bunch of lines like this:

 class Vspace(Base.Command): pass
 class Boldpath(Base.Command): pass

 There are a bunch of lines like that.
 Is there a better way? Something like

 newclasses = ['Vspace', 'Boldpath', ... ]
 for name in newclasses:
 tmp = type(name, (Base.Command,) {})
 tmp.__name__ = name

 Is there a more pythonic way?

I've just realised -- why on earth are you doing this? Surely there's
a better way than having 50 identical classes. :/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making a pass form cgi = webpy framework

2013-06-27 Thread Νίκος


Στις 25/6/2013 9:00 μμ, ο/η ru...@yahoo.com έγραψε:

On 06/23/2013 07:44 PM, Νίκος wrote: Why use mako's approach which requires 2 
files(an html template and the

actual python script rendering the data) when i can have simple print
statements inside 1 files(my files.py script) ?
After all its only one html table i wish to display.


Good question.  Sometimes your way is best.

The main advantage of using templates is that the template contains
only html (mostly) and the cgi code contains only python (mostly).

The idea is that you can look at the template and see only the
kind of code (html) that affects how the page looks.  With some
template systems you can edit the template files with a html
editor and do the page design visually.  Even in a text editor
it is usually easier to see the how the html works without
spurious stuff like code.

And when you look at the cgi code, you see only the Python code
that is needed to get the variable data that is displayed in the
page without the distraction of a lot of html stuff.


I still cant make up my mind what i'm to use.

a) keep my existing Python cgi way that embed print ''' statements 
within python code to displays mostly tables?


b) use a mentioned html templating schema like i.e. mako?

c) use a micro web framework like flask?

Can someone please provide simple example of (b) and (c) to help me 
realizes the differences of html tamplates compared to frameworks?


Because the latter is still unclear to me as to what exactly is and 
behave so i cant tell if i'm to use it or not.



--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: class factory question

2013-06-27 Thread Tim

On Thursday, June 27, 2013 9:16:50 AM UTC-4, Joshua Landau wrote:
 On 26 June 2013 14:09, Tim wrote:
 
  I am extending a parser and need to create many classes that are all 
  subclassed from the same object (defined in an external library).  When my 
  module is loaded I need all the classes to be created with a particular 
  name but the behavior is all the same. Currently I have a bunch of lines 
  like this:
 
  class Vspace(Base.Command): pass 
  class Boldpath(Base.Command): pass 
  
  There are a bunch of lines like that. 
  Is there a better way? Something like
  newclasses = ['Vspace', 'Boldpath', ... ]
  for name in newclasses:
  tmp = type(name, (Base.Command,) {})
  tmp.__name__ = name
 
  Is there a more pythonic way?

 I've just realised -- why on earth are you doing this? Surely there's
 a better way than having 50 identical classes. :/

The reason is that I'm using a parser that creates a DOM from a LaTeX file. The 
plasTeX package (http://plastex.sourceforge.net/) provides the library to 
accomplish that. The parser needs to know how to consume some custom-defined 
tokens (like \Vspace, \Boldpath, etc). The behavior for these is all the same 
so they're subclassed from one base class, but they need to have these 
particular names so  the parser knows how to consume them when encountered in 
the source file. That is, for every custom command the parser encounters, it 
looks for a class of that name in order to tokenize it.

I agree that this is an abnormal circumstance and normally I would just 
subclass in the normal way. But I think this situation is different enough that 
it is okay to break a convention.

thanks for thinking about this.
--Tim
-- 
http://mail.python.org/mailman/listinfo/python-list

How to make a web framework

2013-06-27 Thread gamesbrainiac

I've used web frameworks, but I don't know how they work. Is there anywhere 
that I can learn how this all works from scratch?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Andrew Berg

On 2013.06.27 08:08, Roy Smith wrote:
 Can you give us a concrete example of what you're trying to do?
The actual code I've written so far isn't easily condensed into a short simple 
snippet.
I'm trying to use argparse to handle all the little details of parsing and 
verifying arguments in the precmd hook for a cmd.Cmd child class.
argparse's help system is more sophisticated than cmd's help and does all the 
work of verifying arguments.
The problem I keep running into is that I can't handle any bad input very well. 
I would have to override every method that catches
ArgumentError in order to get a useful exception that I would then handle.
If I input something that begins with '-' that isn't recognized, parse_args 
doesn't even raise the exception; it just quits. In this case,
the message gets mangled if error is overridden, and I don't know why.

 You might look into type=.  It's normally used for things like 
 type=int or type=float, but it could give it any user-defined 
 function as a type and this essentially becomes a hook to insert your 
 own code into the middle of the processing.  Sometimes that can be 
 warped into doing all sorts of useful things.
I don't think that would solve my problem, but it would probably be quite 
useful.
-- 
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class factory question


On 06/27/2013 09:37 AM, Tim wrote:

On Thursday, June 27, 2013 9:16:50 AM UTC-4, Joshua Landau wrote:

On 26 June 2013 14:09, Tim wrote:


I am extending a parser and need to create many classes that are all subclassed 
from the same object (defined in an external library).  When my module is 
loaded I need all the classes to be created with a particular name but the 
behavior is all the same. Currently I have a bunch of lines like this:

 class Vspace(Base.Command): pass
 class Boldpath(Base.Command): pass

There are a bunch of lines like that.
Is there a better way? Something like
 newclasses = ['Vspace', 'Boldpath', ... ]
 for name in newclasses:
 tmp = type(name, (Base.Command,) {})
 tmp.__name__ = name

Is there a more pythonic way?


I've just realised -- why on earth are you doing this? Surely there's
a better way than having 50 identical classes. :/


The reason is that I'm using a parser that creates a DOM from a LaTeX file. The 
plasTeX package (http://plastex.sourceforge.net/) provides the library to 
accomplish that. The parser needs to know how to consume some custom-defined 
tokens (like \Vspace, \Boldpath, etc). The behavior for these is all the same 
so they're subclassed from one base class, but they need to have these 
particular names so  the parser knows how to consume them when encountered in 
the source file. That is, for every custom command the parser encounters, it 
looks for a class of that name in order to tokenize it.

I agree that this is an abnormal circumstance and normally I would just 
subclass in the normal way. But I think this situation is different enough that 
it is okay to break a convention.

thanks for thinking about this.
--Tim



I don't think you broke the convention, that parser did.

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

Devnagari Unicode Conversion Issues

2013-06-27 Thread darpan6aya

How can i convert text of the following type 

à¤¨à¥à¤ªà¤¾à¤²à¥

into devnagari unicode in Python 2.7?
-- 
http://mail.python.org/mailman/listinfo/python-list

Running programs on mobile phones

2013-06-27 Thread Mok-Kong Shen



Could one write Python codes and have them run on one's own mobile
phone? If yes, are there some good literatures? Thanks in advance.

M. K. Shen
--
http://mail.python.org/mailman/listinfo/python-list

Re: Devnagari Unicode Conversion Issues

2013-06-27 Thread MRAB


On 27/06/2013 16:05, darpan6aya wrote:

How can i convert text of the following type

 à¤¨à¥‡à¤ªà¤¾à¤²à¥€

into devnagari unicode in Python 2.7?


Is that a bytestring? In other words, is its type 'str'?

If so, you need to decode it. That particular string is UTF-8:

 print à¤¨à¥‡à¤ªà¤¾à¤²à¥€.decode(utf-8)
नेपाली

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

Re: How to make a web framework

2013-06-27 Thread Fábio Santos

On 27 Jun 2013 14:49, gamesbrain...@gmail.com wrote:

 I've used web frameworks, but I don't know how they work. Is there
anywhere that I can learn how this all works from scratch?

Write CGI scripts. It is the most raw way to program for the web. That way
you can dig into what frameworks do for you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Devnagari Unicode Conversion Issues

2013-06-27 Thread darpan6aya

That worked out. I was trying to encode it the entire time. 
Now I realise how silly I am. 

Thanks MRAB. Once Again. :D
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to make a web framework

On Thursday, June 27, 2013 8:44:36 PM UTC+5:30, Fábio Santos wrote:
 On 27 Jun 2013 14:49, gamesb...@gmail.com wrote:
  I've used web frameworks, but I don't know how they work. Is there anywhere 
  that I can learn how this all works from scratch?

 Write CGI scripts. It is the most raw way to program for the web. That way 
 you 
 can dig into what frameworks do for you.

Cant argue with the correctness of this advice.  Its still a bit low level.

Slightly more hi-level but not yet into framework-land is to take the basic 
components of web-design and study minimalist implementations separately.

Note: I know very little of this area -- used RoR for a couple of months many 
years ago. This is just to get the ball rolling and have more experienced folks 
amend my suggestions!

- url-mapping
- template engines
- Database-ORM
- MVC design pattern 

One more general advice based on my experience [And if it looks condescending, 
please forgive me!] Many people who come to a programming language like python 
from web-framework experience dont know enough programming.  They then cover up 
that lack by learning more and more of the framework but not enough of the 
underlying language.  This may get you along for a while but eventually is 
suboptimal
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class factory question

2013-06-27 Thread Irmen de Jong

On 27-6-2013 15:48, Dave Angel wrote:

 The behavior for these is all the same so they're subclassed
 from one base class, but they need to have these particular names so  the 
 parser knows
 how to consume them when encountered in the source file. That is, for every 
 custom
 command the parser encounters, it looks for a class of that name in order to 
 tokenize it.
  ^

How does it look for a class?
Can you perhaps override the way it looks for a class of that name?
So that you can instead return something sensible rather than having to define 
one of 50
almost identical classes...


Irmen

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

Re: Running programs on mobile phones


On 06/27/2013 11:11 AM, Mok-Kong Shen wrote:


Could one write Python codes and have them run on one's own mobile
phone? If yes, are there some good literatures? Thanks in advance.

M. K. Shen



I've not tried it, but that's what QPython is supposed to do.

http://qpython.com/


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

Re: Why is the argparse module so inflexible?


On 06/27/2013 09:49 AM, Andrew Berg wrote:

On 2013.06.27 08:08, Roy Smith wrote:

Can you give us a concrete example of what you're trying to do?

The actual code I've written so far isn't easily condensed into a short simple 
snippet.
I'm trying to use argparse to handle all the little details of parsing and 
verifying arguments in the precmd hook for a cmd.Cmd child class.
argparse's help system is more sophisticated than cmd's help and does all the 
work of verifying arguments.
The problem I keep running into is that I can't handle any bad input very well. 
I would have to override every method that catches
ArgumentError in order to get a useful exception that I would then handle.
If I input something that begins with '-' that isn't recognized, parse_args 
doesn't even raise the exception; it just quits.


No, it raises the SystemExit exception.  if you don't catch it, then the 
program exits.  Perhaps it's not clear to you, but sys.exit() just 
raises the SystemExit exception, as  Joshua pointed out.



In this case,
the message gets mangled if error is overridden, and I don't know why.



I can't help there.


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

Re: Devnagari Unicode Conversion Issues

On 06/27/2013 11:39 AM, darpan6aya wrote:

That worked out. I was trying to encode it the entire time.
Now I realise how silly I am.

Thanks MRAB. Once Again. :D

you're not silly, it's a complex question. MRAB is good at guessing
which part is messing you up.

However, when you're writing a real Python program with a real text
editor, and when you're not using a newsgroup in between to mangle or
unmangle things, you have a few things to match up to get it right.

The file is just a bunch of bytes. Those bytes are being inserted in
there by your editor, and interpreted by the compiler. So if you have a
non-ASCII character on your keyboard and you hit it, the editor will
decode it (from Unicode to byte(s)) and put it in the file. If you tell
the editor to use utf-8, then you also want to tell the compiler to
decode it using utf-8.

The most polite way to do that looks something like:
# -*- coding: encoding-name -*-
# -*- coding: utf-8 -*-

http://docs.python.org/release/2.7.5/reference/lexical_analysis.html#encoding-declarations

Once you've got that straight, you don't need to explicitly decode byte
strings. You can just use

uThis is my string

with whatever characters you need. As long as the declarations match,
this should just work. If the data comes from a byte string other
than a literal string, you might need the more verbose form.

Your original message was sent in Western (ISO 8859-1), and MRAB's
response was in utf-8, and my mail program decoded the string the same
way. However, I don't know anything about Devnagari, so I can't say if
it looked reasonable here.

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

Re: class factory question

2013-06-27 Thread Tim

On Thursday, June 27, 2013 11:56:24 AM UTC-4, Irmen de Jong wrote:
 On 27-6-2013 15:48, Dave Angel wrote:
  The behavior for these is all the same so they're subclassed
  from one base class, but they need to have these particular names so  the 
  parser knows
  how to consume them when encountered in the source file. That is, for 
  every custom
  command the parser encounters, it looks for a class of that name in order 
  to tokenize it.
   ^ 
 
 How does it look for a class? 
 Can you perhaps override the way it looks for a class of that name? 
 So that you can instead return something sensible rather than having to 
 define one of 50
 almost identical classes...  
 Irmen

hmm, the package author describes inheriting like I was doing in the first 
place. With a parser, I really don't know any better way but then I'm not a 
parsing expert. I will delve into the code and try to get a better handle on 
how the parser finds the definitions it needs in order to tokenize the input.

thanks!
--Tim

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

Python ZeldaII sequel - mapeditor

2013-06-27 Thread Turtle Wizard

Hi all,

I made a simple map editor for using in pyZeldaII overworld maps, 
it's fastly written.
You can download it here : http://github.com/pygame-pyLevelMaker

pyZeldaII can be found here : http://github.com/pygame-pyZeldaII

Enjoy,
Turtle Wizard

-- 
Time heals.
my blog : http://thediaryofelvishhealer.blogspot.be/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python ZeldaII sequel - mapeditor

2013-06-27 Thread elvish . healer

Scuzzy,

the links are : http://github.com/zork9/pygame-pyLevelMaker
and http://github.com/zork9/pygame-pyZeldaII

You can download them with git.

Screenshots of the level editor can be found on my blog, see sig.

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

Re: 回复： FACTS: WHY THE PYTHON LANGUAGE FAILS.

2013-06-27 Thread woooee

Any programming language is only as good as the person who is using it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Terry Reedy


On 6/27/2013 8:54 AM, Andrew Berg wrote:

I've begun writing a program with an interactive prompt, and it needs
to parse input from the user.  I thought the argparse module would be
great for this,


It is outside argparse's intended domain of application -- parsing 
command line arguments. The grammar for a valid string of command line 
arguments is quite restricted.


Argparse is not intended for interactive processing of a domain-specific 
language (DSL). There are other parsers for that. But if the grammar for 
your DSL is restricted to what argparse can handle, using it is an 
interesting idea. But you need non-default usage for the non-default 
context.


 but unfortunately it insists on calling sys.exit() at

any sign of trouble instead of letting its ArgumentError exception
propagate so that I can handle it.


When one tell argparse that something is *required*, that means I do 
not want to see the user's input unless it passes this condition. After 
seeing an error message, the user can edit the command line and re-enter.


If you do not mean 'required' in the sense above, do not say so.
Catching SystemExit is another way to say 'I did not really mean 
required, in the usual mean of that term.'.


--
Terry Jan Reedy

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

Re: Why is the argparse module so inflexible?


On 06/27/2013 02:05 PM, Terry Reedy wrote:

On 6/27/2013 8:54 AM, Andrew Berg wrote:

I've begun writing a program with an interactive prompt, and it needs
to parse input from the user.  I thought the argparse module would be
great for this,


It is outside argparse's intended domain of application -- parsing
command line arguments. The grammar for a valid string of command line
arguments is quite restricted.

Argparse is not intended for interactive processing of a domain-specific
language (DSL). There are other parsers for that. But if the grammar for
your DSL is restricted to what argparse can handle, using it is an
interesting idea. But you need non-default usage for the non-default
context.

  but unfortunately it insists on calling sys.exit() at

any sign of trouble instead of letting its ArgumentError exception
propagate so that I can handle it.


When one tell argparse that something is *required*, that means I do
not want to see the user's input unless it passes this condition. After
seeing an error message, the user can edit the command line and re-enter.

If you do not mean 'required' in the sense above, do not say so.
Catching SystemExit is another way to say 'I did not really mean
required, in the usual mean of that term.'.



That last sentence is nonsense.  If one is parsing the line the user 
enters via raw_input(), catching SystemExit so the program doesn't abort 
is perfectly reasonable.  The user should be returned to his prompt, 
which in this case is probably another loop through raw_input().


Or perhaps entering a bad password should blow the circuit breaker?

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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Terry Reedy


On 6/27/2013 2:18 PM, Dave Angel wrote:

On 06/27/2013 02:05 PM, Terry Reedy wrote:

On 6/27/2013 8:54 AM, Andrew Berg wrote:

I've begun writing a program with an interactive prompt, and it needs
to parse input from the user.  I thought the argparse module would be
great for this,


It is outside argparse's intended domain of application -- parsing
command line arguments. The grammar for a valid string of command line
arguments is quite restricted.

Argparse is not intended for interactive processing of a domain-specific
language (DSL). There are other parsers for that. But if the grammar for
your DSL is restricted to what argparse can handle, using it is an
interesting idea. But you need non-default usage for the non-default
context.

  but unfortunately it insists on calling sys.exit() at

any sign of trouble instead of letting its ArgumentError exception
propagate so that I can handle it.


When one tell argparse that something is *required*, that means I do
not want to see the user's input unless it passes this condition. After
seeing an error message, the user can edit the command line and re-enter.

If you do not mean 'required' in the sense above, do not say so.
Catching SystemExit is another way to say 'I did not really mean
required, in the usual mean of that term.'.



That last sentence is nonsense.


Not if you understand what I said.

 If one is parsing the line the user  enters via raw_input(),

input(), in 3.x

 catching SystemExit so the program doesn't abort

is perfectly reasonable.  The user should be returned to his prompt,
which in this case is probably another loop through raw_input().


Right, because 'required' means something a little different in the 
interactive context.


I don't know if all the information in the original ArgumentError 
exception is transferred to the SystemExit exception. I expect not, and 
if so, and if multiple people are using argparse this way, it would be 
reasonable to request on the tracker that its current sys.exit behavior 
become default but optional in 3.4+. There might even be an issue 
already if one searched.


--
Terry Jan Reedy

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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Ethan Furman

On 06/27/2013 11:39 AM, Terry Reedy wrote:

On 6/27/2013 2:18 PM, Dave Angel wrote:

On 06/27/2013 02:05 PM, Terry Reedy wrote:

On 6/27/2013 8:54 AM, Andrew Berg wrote:

I've begun writing a program with an interactive prompt, and it needs
to parse input from the user. I thought the argparse module would be
great for this,

It is outside argparse's intended domain of application -- parsing
command line arguments. The grammar for a valid string of command line
arguments is quite restricted.

Argparse is not intended for interactive processing of a domain-specific
language (DSL). There are other parsers for that. But if the grammar for
your DSL is restricted to what argparse can handle, using it is an
interesting idea. But you need non-default usage for the non-default
context.

but unfortunately it insists on calling sys.exit() at

any sign of trouble instead of letting its ArgumentError exception
propagate so that I can handle it.

When one tell argparse that something is *required*, that means I do
not want to see the user's input unless it passes this condition. After
seeing an error message, the user can edit the command line and re-enter.

If you do not mean 'required' in the sense above, do not say so.
Catching SystemExit is another way to say 'I did not really mean
required, in the usual mean of that term.'.

That last sentence is nonsense.

Not if you understand what I said.

If one is parsing the line the user enters via raw_input(),

input(), in 3.x

catching SystemExit so the program doesn't abort
is perfectly reasonable. The user should be returned to his prompt,
which in this case is probably another loop through raw_input().

Right, because 'required' means something a little different in the interactive
context.

I don't know if all the information in the original ArgumentError exception is
transferred to the SystemExit exception.
I expect not, and if so, and if multiple people are using argparse this way, it
would be reasonable to request on the
tracker that its current sys.exit behavior become default but optional in 3.4+.
There might even be an issue already if
one searched.

If the OP is writing an interactive shell, shouldn't `cmd` be used instead of `argparse`? argparse is, after all,
intended for argument parsing of command line scripts, not for interactive work.

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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Robert Kern


On 2013-06-27 17:02, Dave Angel wrote:

On 06/27/2013 09:49 AM, Andrew Berg wrote:

On 2013.06.27 08:08, Roy Smith wrote:

Can you give us a concrete example of what you're trying to do?

The actual code I've written so far isn't easily condensed into a short simple
snippet.
I'm trying to use argparse to handle all the little details of parsing and
verifying arguments in the precmd hook for a cmd.Cmd child class.
argparse's help system is more sophisticated than cmd's help and does all the
work of verifying arguments.
The problem I keep running into is that I can't handle any bad input very
well. I would have to override every method that catches
ArgumentError in order to get a useful exception that I would then handle.
If I input something that begins with '-' that isn't recognized, parse_args
doesn't even raise the exception; it just quits.


No, it raises the SystemExit exception.  if you don't catch it, then the program
exits.  Perhaps it's not clear to you, but sys.exit() just raises the SystemExit
exception, as  Joshua pointed out.


Internally, the parser raises ArgumentError which has some useful pieces of 
information, specifically, the name of the argument that failed to parse. 
Unfortunately, it catches that error in parse_known_args(), then formats that 
information into a message string to pass to the error() method, which by 
default raises SystemExit with just that message string. It is somewhat 
difficult to override the parse_known_args() to not lose that information from 
the ArgumentError because you will have to copy-paste the rest of the code in there.


So yes, you can override the error() method or catch SystemExit if all you want 
is the formatted message string, but I have to agree that there is a missed 
opportunity to make argparse more widely usable for other command-line like 
parsing tasks[1].


[1] As an existence proof, I offer you one that I wrote for handling IPython's 
%magic commands. I just needed the formatted string, so I could just get away 
with overriding error().


https://github.com/ipython/ipython/blob/master/IPython/core/magic_arguments.py

--
Robert Kern

I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth.
  -- Umberto Eco

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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Jason Swails

On Thu, Jun 27, 2013 at 2:50 PM, Ethan Furman et...@stoneleaf.us wrote:


 If the OP is writing an interactive shell, shouldn't `cmd` be used instead
 of `argparse`?  argparse is, after all, intended for argument parsing of
 command line scripts, not for interactive work.


He _is_ using cmd.  He's subclassed cmd.Cmd and trying to use argparse to
handle argument parsing in the Cmd.precmd method to preprocess the user
input.

Let's say that one of the user's commands requires an integer but they give
a float or a string by accident: I believe the OP wants ArgumentParser to
pass the appropriate ArgumentError exception up to the calling routine
rather than catching it and calling ArgumentParser.error(), thereby
destroying information about the exception type and instead requiring him
to rely on parsing the far less reliable error message (since it's
reasonable to expect that kind of thing to change from version to version).
 This way his calling routine can indicate to the user what was wrong with
the last command and soldier on without bailing out of the program (or
doing something ugly like catching a SystemExit and parsing argparse's
error message).

As it stands now, ArgumentParser has only limited utility in this respect
since all parsing errors result in a SystemExit exception being thrown.
 Having subclassed cmd.Cmd myself in one of my programs and written my own
argument parsing class to service it, I can appreciate what the OP is
trying to do (and it's clever IMO).  While argparse was not specifically
designed for what the OP is trying to do, it would satisfy his needs nicely
except for the previously mentioned issue.

An alternative is, of course, to simply subclass ArgumentParser and copy
over all of the code that catches an ArgumentError to eliminate the
internal exception handling and instead allow them to propagate the call
stack.

All the best,
Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Grant Edwards

On 2013-06-27, Jason Swails jason.swa...@gmail.com wrote:

 He _is_ using cmd.  He's subclassed cmd.Cmd and trying to use
 argparse to handle argument parsing in the Cmd.precmd method to
 preprocess the user input.

[...]

 Having subclassed cmd.Cmd myself in one of my programs and written my
 own argument parsing class to service it, I can appreciate what the
 OP is trying to do (and it's clever IMO).

Unfortunately, when writing software, being clever turns out to be A
Bad Thing(tm) as often as not.  ;)

-- 
Grant Edwards   grant.b.edwardsYow! ... I want to perform
  at   cranial activities with
  gmail.comTuesday Weld!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Chris Angelico

On Fri, Jun 28, 2013 at 8:19 AM, Grant Edwards invalid@invalid.invalid wrote:
 On 2013-06-27, Jason Swails jason.swa...@gmail.com wrote:

 He _is_ using cmd.  He's subclassed cmd.Cmd and trying to use
 argparse to handle argument parsing in the Cmd.precmd method to
 preprocess the user input.

 [...]

 Having subclassed cmd.Cmd myself in one of my programs and written my
 own argument parsing class to service it, I can appreciate what the
 OP is trying to do (and it's clever IMO).

 Unfortunately, when writing software, being clever turns out to be A
 Bad Thing(tm) as often as not.  ;)

I don't see that it needs to be, in this case. Fundamentally, what's
the difference between:

foo@bar:~$ progname subcommand blah blah
foo@bar:~$ progname subcommand blah blah
foo@bar:~$ progname subcommand blah blah

and

foo@bar:~$ progname
progname subcommand blah blah
progname subcommand blah blah
progname subcommand blah blah
progname ^D

? Seems to me your subcommands should be allowed to use argparse.

Yes, it's somewhat less usual usage. But it isn't inconceivable.

Why raise an exception, then catch it and raise SystemExit? Surely
*that* is the unusual behaviour - why not just let an ArgumentError
propagate up?

But with the module doing what it does, I'd say catching SystemExit is
the right thing to do. Deserves a code comment, but perfectly right.

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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Steven D'Aprano

On Thu, 27 Jun 2013 12:02:22 -0400, Dave Angel wrote:

 On 06/27/2013 09:49 AM, Andrew Berg wrote:
 On 2013.06.27 08:08, Roy Smith wrote:
 Can you give us a concrete example of what you're trying to do?
 The actual code I've written so far isn't easily condensed into a short
 simple snippet. I'm trying to use argparse to handle all the little
 details of parsing and verifying arguments in the precmd hook for a
 cmd.Cmd child class. argparse's help system is more sophisticated than
 cmd's help and does all the work of verifying arguments. The problem I
 keep running into is that I can't handle any bad input very well. I
 would have to override every method that catches ArgumentError in order
 to get a useful exception that I would then handle. If I input
 something that begins with '-' that isn't recognized, parse_args
 doesn't even raise the exception; it just quits.
 
 No, it raises the SystemExit exception.  if you don't catch it, then the
 program exits.  Perhaps it's not clear to you, but sys.exit() just
 raises the SystemExit exception, as  Joshua pointed out.

[rant]
I think it is lousy design for a framework like argparse to raise a 
custom ArgumentError in one part of the code, only to catch it elsewhere 
and call sys.exit. At the very least, that ought to be a config option, 
and off by default.

Libraries should not call sys.exit, or raise SystemExit. Whether to quit 
or not is not the library's decision to make, that decision belongs to 
the application layer. Yes, the application could always catch 
SystemExit, but it shouldn't have to.


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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Cameron Simpson

On 27Jun2013 11:50, Ethan Furman et...@stoneleaf.us wrote:
| If the OP is writing an interactive shell, shouldn't `cmd` be used
| instead of `argparse`?  argparse is, after all, intended for
| argument parsing of command line scripts, not for interactive work.

This is specious.

I invoke command line scripts interactively. There's no special case here.

If argparse is raising a useful and inspectable bad argument
exception, why not let it out? Catching that argument and wrapping
it in something opaque seems unhelpful.  After all, if the caller
really wanted to abort on bad arguments the caller would simply not
catch that exception.  There's no need to transmute it into a
whole-program abort.

If Terry's assertion is that the OP has told argparse he never wants
to see bad input, how does one turn that off?

To add to the use case stats, I also subclass cmd and parse interactive
command lines. I'm beginning to be pleased I'm still using Getopt
for that instead of feeling I'm lagging behind the times.

Cheers,
-- 
Cameron Simpson c...@zip.com.au

If it can't be turned off, it's not a feature. - Karl Heuer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making a pass form cgi = webpy framework

2013-06-27 Thread Cameron Simpson

On 27Jun2013 16:32, Νίκος ni...@superhost.gr wrote:
| a) keep my existing Python cgi way that embed print ''' statements
| within python code to displays mostly tables?

I'd argue against this approach. Like hand constructing SQL, this
is rife with opportunity to make syntax errors, either outright by
mistyping HTML or accidentally by badly escaping content that is
not supposed to be HTML but happens to contain HTML marker characters
like .

When I generate HTML I usually make a structure of lists and dicts
that gets converted to HTML. Someone doing a nontrivial amount of
HTML would use a templating system of some kind I imagine; I don't
generate HTML very often.

Pick a simple framework or templating engine and try it. I have no
recommendations to make in this area myself.

Cheers,
-- 
Cameron Simpson c...@zip.com.au

I'm behind a corporate Exchange Server which seems to have
changed recently to converting everything it sees to HTML. 
How embarrassing. - Dan Espen des...@telcordia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Cameron Simpson

On 27Jun2013 22:49, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 
wrote:
| [rant]
| I think it is lousy design for a framework like argparse to raise a 
| custom ArgumentError in one part of the code, only to catch it elsewhere 
| and call sys.exit. At the very least, that ought to be a config option, 
| and off by default.
| 
| Libraries should not call sys.exit, or raise SystemExit. Whether to quit 
| or not is not the library's decision to make, that decision belongs to 
| the application layer. Yes, the application could always catch 
| SystemExit, but it shouldn't have to.

+1
-- 
Cameron Simpson c...@zip.com.au

There is more stupidity than hydrogen in the universe, and it has a
longer shelf life.  - Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is the semantics meaning of 'object'?

2013-06-27 Thread alex23


On 26/06/2013 9:19 AM, Mark Janssen wrote:

Did you ever hear of the Glass Bead Game?


Which was Hesse's condemnation of the 
pure-academic-understanding-unbound-by-pragmatic-use approach as mental 
masturbation, _not_ a recommendation for how human knowledge should 
work. If you think otherwise, you might want to read the last few 
chapters again.


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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Tim Chase

On 2013-06-28 09:02, Cameron Simpson wrote:
 On 27Jun2013 11:50, Ethan Furman et...@stoneleaf.us wrote:
 | If the OP is writing an interactive shell, shouldn't `cmd` be used
 | instead of `argparse`?  argparse is, after all, intended for
 | argument parsing of command line scripts, not for interactive
 work.
 
 I invoke command line scripts interactively. There's no special
 case here.
 
 To add to the use case stats, I also subclass cmd and parse
 interactive command lines. I'm beginning to be pleased I'm still
 using Getopt for that instead of feeling I'm lagging behind the
 times.

I too have several small utilities that use a combination of cmd.Cmd,
shlex.shlex(), and command-processing libraries.  However, much like
Cameron's code using getopt, my older code is still using optparse
which gives me the ability to override the error() method's default
sys.exit() behavior and instead raise the exception of your choice.

-tkc



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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Oscar Benjamin

On 27 June 2013 22:30, Jason Swails jason.swa...@gmail.com wrote:

 An alternative is, of course, to simply subclass ArgumentParser and copy
 over all of the code that catches an ArgumentError to eliminate the internal
 exception handling and instead allow them to propagate the call stack.

I would think it easier to wrap getopt than monkey-patch argparse in this way.


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

Re: Running programs on mobile phones

2013-06-27 Thread alex23


On 28/06/2013 1:11 AM, Mok-Kong Shen wrote:

Could one write Python codes and have them run on one's own mobile
phone? If yes, are there some good literatures? Thanks in advance.


Kivy is a well-documented  multi-platform approach to doing this:

http://kivy.org/

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

Re: SQL code generation from table-free boolean queries?

2013-06-27 Thread alex23


On 27/06/2013 9:17 AM, Foo Stack wrote:

Given string input such as:
 foo=5 AND a=6 AND date=now OR date='2013/6' AND bar='hello'

I am going to implement:

- boolean understanding (which operator takes precendence)
- spliting off of attributes into my function which computes their table in the 
SQL database
- piece everything together into an SQL query

However, it came to me that this is probably a very generic thing; and there 
might be a library for it.


Not a library per se, but I did see an article that did something quite 
similar using SQLAlchemy that might make a good starting point:


http://www.wiggy.net/articles/sqlalchemy-in-reverse

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

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Jason Swails

On Thu, Jun 27, 2013 at 8:22 PM, Tim Chase python.l...@tim.thechases.comwrote:

 On 2013-06-28 09:02, Cameron Simpson wrote:
  On 27Jun2013 11:50, Ethan Furman et...@stoneleaf.us wrote:
  | If the OP is writing an interactive shell, shouldn't `cmd` be used
  | instead of `argparse`?  argparse is, after all, intended for
  | argument parsing of command line scripts, not for interactive
  work.
 
  I invoke command line scripts interactively. There's no special
  case here.
 
  To add to the use case stats, I also subclass cmd and parse
  interactive command lines. I'm beginning to be pleased I'm still
  using Getopt for that instead of feeling I'm lagging behind the
  times.

 I too have several small utilities that use a combination of cmd.Cmd,
 shlex.shlex(), and command-processing libraries.  However, much like
 Cameron's code using getopt, my older code is still using optparse
 which gives me the ability to override the error() method's default
 sys.exit() behavior and instead raise the exception of your choice.


There's nothing in argparse preventing this.  There's still an
ArgumentParser.error() method that you can override to raise an exception.
 The problem is that the original exception ArgumentParser raised when it
hit a parsing error was lost as soon as the parsing routine caught said
exception.

Therefore, your new error() method must parse the message being passed to
it in order to determine what error occurred and raise the corresponding
exception of your choice, or simply settle with telling the user there was
a generic argument parsing error that they have to figure out.

Being a prolific user of argparse myself (I use it or optparse in nearly
every script I write, although I greatly prefer argparse), I recognize it
as an incredibly feature-packed, convenient, easy-to-use library.  It's too
bad that the utility of this library for non-commandline argument parsing
is limited by a seemingly unnecessary feature.

Of course, in RRsPy4k this whole module will just be replaced with raise
PyWart('All interfaces must be graphical') and this whole thread will be
moot. :)

All the best,
Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making a pass form cgi = webpy framework

2013-06-27 Thread Νίκος


Στις 28/6/2013 2:08 πμ, ο/η Cameron Simpson έγραψε:

On 27Jun2013 16:32, Νίκος ni...@superhost.gr wrote:
| a) keep my existing Python cgi way that embed print ''' statements
| within python code to displays mostly tables?

I'd argue against this approach. Like hand constructing SQL, this
is rife with opportunity to make syntax errors, either outright by
mistyping HTML or accidentally by badly escaping content that is
not supposed to be HTML but happens to contain HTML marker characters
like .

When I generate HTML I usually make a structure of lists and dicts
that gets converted to HTML. Someone doing a nontrivial amount of
HTML would use a templating system of some kind I imagine; I don't
generate HTML very often.

Pick a simple framework or templating engine and try it. I have no
recommendations to make in this area myself.


Can you explain to me the difference of the former and latter?

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: FACTS: WHY THE PYTHON LANGUAGE FAILS.

2013-06-27 Thread Jason Friedman

 I was hoping to have a good laugh. :|

  Although I wouldn't call it hostile.

 I think the python community is being educated in how to spam and troll at
 the same time.


It is possible the OP has a mental disease, which is about as funny as
heart disease and cancer and not blameworthy.  This is the poster's website
from a previous post on this forum:  http://thrinaxodon.wordpress.com.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the argparse module so inflexible?

2013-06-27 Thread Andrew Berg

I appreciate the responses from everyone. I knew I couldn't be the only who 
thought this behavior was unnecessarily limiting.

I found a ticket on the bug tracker. A patch was even submitted, but obviously 
it didn't make it into 3.3.
Hopefully, it will make it into 3.4 with some prodding.
http://bugs.python.org/issue9938
-- 
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1
-- 
http://mail.python.org/mailman/listinfo/python-list

[issue9625] argparse: Problem with defaults for variable nargs when using choices

2013-06-27 Thread paul j3


paul j3 added the comment:

I've added 2 more tests, 

one with default='c', which worked before.

one with default=['a','b'], which only works with this change.

http://bugs.python.org/issue16878 is useful reference, since it documents
the differences between nargs=? and nargs=*, and their handling of
their defaults.

--
Added file: http://bugs.python.org/file30709/issue9625_1.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9625
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword

2013-06-27 Thread Ned Deily


Changes by Ned Deily n...@acm.org:


--
nosy: +rhettinger

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18313
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18312] make distclean deletes files under .hg directory

2013-06-27 Thread STINNER Victor


Changes by STINNER Victor victor.stin...@gmail.com:


--
versions: +Python 3.3 -Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18312
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18312] make distclean deletes files under .hg directory

2013-06-27 Thread STINNER Victor


STINNER Victor added the comment:

Extract of GNU standards:

# make distclean
#  Delete all files from the current directory that are created by
#  configuring or building the program.  If you have unpacked the
#  source and built the program without creating any other files,
#  `make distclean' should leave only the files that were in the
#  distribution.

Python should only remove files generated by the build process: Makefile, 
pyconfig.h, *.o, etc. But not files generated by Mercurial (.orig, .rej), 
backup files (.old, .bak), nor any other files which is not generated by the 
build. These files may be important for the developer (Mercurial keeps modified 
files after hg revert --all for example).

If someone wants an hardcore cleaner, the command can be kept, but please, 
under a different name.

I use make distclean when I change compiler options (rerun Makefile), when a 
new C file is added (calling make is usually not enough, and I prefer to 
restart from a clean source tree), or more generally when Python doesn't 
compile for an unknown reason. For example, make distclean was need when the 
new _stat (Modules/_stat.c) module was added.

R. David Murray wrote on python-dev: We also sometimes ask someone reporting 
an issue to do a make distclean and recompile (...).

Here is a patch simply removing the find -exec rm {}; command from make 
distclean. Remaining commands:

--
# Make things extra clean, before making a distribution:
# remove all generated files, even Makefile[.pre]
# Keep configure and Python-ast.[ch], it's possible they can't be generated
distclean: clobber
for file in Lib/test/data/* ; do \
if test $$file != Lib/test/data/README; then rm $$file; fi; \
done
-rm -f core Makefile Makefile.pre config.status \
Modules/Setup Modules/Setup.local Modules/Setup.config \
Modules/ld_so_aix Modules/python.exp Misc/python.pc
-rm -f python*-gdb.py
--

--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file30710/make_distclean.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18312
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18312] make distclean deletes files under .hg directory

2013-06-27 Thread Marc-Andre Lemburg


Marc-Andre Lemburg added the comment:

On 27.06.2013 09:36, STINNER Victor wrote:
 
 STINNER Victor added the comment:
 
 Extract of GNU standards:
 
 # make distclean
 #  Delete all files from the current directory that are created by
 #  configuring or building the program.  If you have unpacked the
 #  source and built the program without creating any other files,
 #  `make distclean' should leave only the files that were in the
 #  distribution.
 
 Python should only remove files generated by the build process: Makefile, 
 pyconfig.h, *.o, etc. But not files generated by Mercurial (.orig, .rej), 
 backup files (.old, .bak), nor any other files which is not generated by the 
 build. These files may be important for the developer (Mercurial keeps 
 modified files after hg revert --all for example).
 
 If someone wants an hardcore cleaner, the command can be kept, but please, 
 under a different name.

Hmm, but distclean is exactly the kind of cleaner it's meant to be:
you use the command to prepare for a source code distribution and
you don't want any backup files or failed patch traces in your
source code distribution.

Perhaps we should introduce a softer version that leaves the
files you mention in untouched, so it can be used by developers,
e.g. make devclean.

--
nosy: +lemburg

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18312
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18309] Make python slightly more relocatable

2013-06-27 Thread Mathias Fröhlich


Mathias Fröhlich added the comment:

Hi Eric,

Thanks for looking at that ticket so fast!

Reassigning this to 3.4 is great.

In general, yes I can already do what I need more or less. This is the reason 
why I can be fine with about every python version.

The point I bring up this change that I believe I am doing this at an 
unappropriate place as I need to know some internals of python when I do so and 
that I think that other can probably also benefit from this idea/change.
What I currently do is to write an application that just uses python*.so as an 
embedded interpreter and this precompiled application might be relocated to 
about everywhere - just where it is unpacked.
We are currently using the same sort of code to find out where the python*so 
file is and we use Py_SetPythonHome to set is to the directory where the so 
file resides.

Why are we doing this?
So, it takes the idea that is currently in the standard python interpreter. 
This one tries to be relocatable (means: pack the installation directory and 
unpack that somewhere else and be still able to run) by looking at argv[0] and 
dereferencing symbolic links until it arrives at a real file.
Now suppose you want to embed python, then you do no longer use the standard 
python interpreter program. You may also use a different installation layout 
for basic things like bin and lib. So you end up with an application that is no 
longer able to find its provided python modules by looking at the applications 
path.
But instead of starting from the path of the interpreter (which is not used in 
this case) or the application itself you could start from the python library 
path and look for your python installation relative to that. So as long as you 
stick with the relative file layout of everything that is python related (and 
only what is python related, the python.so and the modules) when you pack and 
unpack your precompiled application this would just work.

So, put that in short:
Instead of dynamically finding the the python module path relative to 
.../bin/python try to find the python relative to .../lib/libpython34.so.
The benefit of that would be that every application that embeds python and 
needs to be relocatable will just work in the way that today only the standard 
python interpreter works.

I try to get all of the PEP you pointed me to.
As I am seeing this longer document the first time, I am not sure if I missed 
something there, but in that framework of this my proposal would probably 
influence the initial setting of 

sys.prefix (?)

if this is not already provided from the embedding application.

And yes I am perfectly fine with a different or more general approach.
The initially attached patch is something that tried to integrate into the 
current checked in code as I understood it.

Greetings

Mathias

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18309
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16487] Allow ssl certificates to be specified from memory rather than files.

2013-06-27 Thread Kristján Valur Jónsson


Kristján Valur Jónsson added the comment:

Thanks for your comments Christian.
You don't check ERR_GET_LIB() in some places.
Do you have a particular place in mind?

About DER.  As I understand, currently _ssl only supports PEM.  If that is the 
case, then supporting DER should, IMHO, be a separate patch.  It will probably 
involve adding an argument to the functions.

Both DER and PEM files are binary formats.  the PEM is base64 encoded ascii 
with some strict ascii headers and footers.  As such, the encoding is quite 
explicit.
I am not sure that automatic conversion from unicode to ascii should be 
undertaken on the C level, particularly if the intention later is to support 
DER, which is pure binary and where string has no place.

I'll have a look at your patch as well, haven't gotten round to do that yet.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16487
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16487] Allow ssl certificates to be specified from memory rather than files.

2013-06-27 Thread Christian Heimes


Christian Heimes added the comment:

I found two places:

if (ERR_GET_REASON(err) == X509_R_CERT_ALREADY_IN_HASH_TABLE) {
if (ERR_GET_REASON(err) == PEM_R_BAD_BASE64_DECODE)


AFAIK the _ssl module only supports PEM certs for loading. On the other hands 
cert data can only be retrieved as dict representation or binary DER data, e.g. 
getpeercert(binary_form=True) - DER bytes. It's a bit of a puzzle to me.

It feels a bit strange to treat PEM certs as binary data, especially since the 
SSL module treats PEM as ASCII unicode. For example DER_cert_to_PEM_cert() 
accepts bytes and returns str, PEM_cert_to_DER_cert() converts str to bytes.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16487
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16487] Allow ssl certificates to be specified from memory rather than files.

2013-06-27 Thread Antoine Pitrou


Antoine Pitrou added the comment:

 It feels a bit strange to treat PEM certs as binary data, especially
 since the SSL module treats PEM as ASCII unicode. For example
 DER_cert_to_PEM_cert() accepts bytes and returns str,
 PEM_cert_to_DER_cert() converts str to bytes.

I agree that PEM is logically text (i.e. unicode). Also, having the
unicode == PEM, bytes == DER distinction sounds reasonably practical.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16487
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13483] Use VirtualAlloc to allocate memory arenas

2013-06-27 Thread Martin v . Löwis


Changes by Martin v. Löwis mar...@v.loewis.de:


--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13483
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13483] Use VirtualAlloc to allocate memory arenas

2013-06-27 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 44f455e6163d by Martin v. Löwis in branch 'default':
Issue #13483: Use VirtualAlloc in obmalloc on Windows.
http://hg.python.org/cpython/rev/44f455e6163d

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13483
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16113] Add SHA-3 (Keccak) support

2013-06-27 Thread Christian Heimes


Christian Heimes added the comment:

Hi Aaron,

it's a tempting idea but I have to decline. The API is deliberately limited to 
the NIST interface. Once OpenSSL gains SHA-3 support we are going to use it in 
favor for the reference implementation. I don't expect OpenSSL to provide the 
full sponge API.

I also like to keep all options open so I can switch to a different and perhaps 
smaller implementation in the future. The reference implementation is huge and 
the binary is more than 400 KB. For comparison the SHA-2 384 + 512 module's 
binary is just about 60 KB on a 64bit Linux system.

Once a a new API has been introduced it's going to take at least two minor 
Python release and about four to five years to remove it.

But I could add a more flexible interface to Keccak's sponge to my standalone 
sha3 module https://pypi.python.org/pypi/pysha3 ...

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16113
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16487] Allow ssl certificates to be specified from memory rather than files.

2013-06-27 Thread Kristján Valur Jónsson


Kristján Valur Jónsson added the comment:

Ok, thanks.
The consistency argument is strong, also Antoine's suggestion to use the return 
type of read() as a discriminant.

also please excuse me because I am not a habitual user of Python 3 and haven't 
become used to the str/binary dichotomy yet.  I didn´t know, for instance, 
about io.BytesIO until I found to my horror that io.StringIO.read() would 
output unicode (i.e str).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16487
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16487] Allow ssl certificates to be specified from memory rather than files.

2013-06-27 Thread Christian Heimes


Christian Heimes added the comment:

EVE Online is still using Python 2.7? You gotta hurry up or Guido will beat you 
with Dropbox's 3.x port. :)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16487
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18312] make distclean deletes files under .hg directory


Eric V. Smith added the comment:

My plan is to just fix this issue, right now, by changing the find command to 
be:
   find $(srcdir)/[a-zA-Z]* ...

That fixes this bug and keeps the current functionality.

If someone wants to open another issue about changing what distclean does, I 
think that's okay. I suggest discussing it on python-dev first.

--
assignee:  - eric.smith

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18312
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18309] Make python slightly more relocatable

2013-06-27 Thread Nick Coghlan


Nick Coghlan added the comment:

The way we figure out where to find the standard library is crazy, and creating 
the infrastructure to start making it less crazy is actually one of the prime 
motivations for PEP 432 :)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18309
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18314] Have os.unlink remove junction points

2013-06-27 Thread Kim Gräsman


New submission from Kim Gräsman:

os.unlink currently raises a WindowsError (Access Denied) if I attempt to 
unlink an NTFS junction point.

It looks trivial to allow Py_DeleteFileW [1] to remove junction points as well 
as proper symbolic links, as far as I can tell.

For example, the ntfslink-python library [2] only checks if both 
FILE_ATTRIBUTE_DIRECTORY and FILE_ATTRIBUTE_REPARSE_POINT are set.

RemoveDirectoryW is documented to handle junction points transparently, so it 
should just be a matter of passing the path on if it's a junction point or a 
symbolic link.

My motivation for this is that I have used external tools to create junction 
points, and am now switching to symbolic links. When deleting a directory, I 
need to do:

try:
os.unlink(link_path)
except WindowsError as detail:
# BACKWARD COMPATIBILITY HACK
if detail.winerror == 5:
_delete_junction_point(link_path)
else:
raise

which is a little funky. It seems like os.unlink semantics work just as well 
for junction points, even if they can't be created with os.symlink.

Love it/hate it?

[1] http://hg.python.org/cpython/file/44f455e6163d/Modules/posixmodule.c#l4105
[2] 
https://github.com/Juntalis/ntfslink-python/blob/2f6ff903f9b22942de8aa93a32a3d817124f359e/ntfslink/internals/__init__.py#L32

--
components: Windows
messages: 191945
nosy: Kim.Gräsman
priority: normal
severity: normal
status: open
title: Have os.unlink remove junction points
type: behavior
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18314] Have os.unlink remove junction points

2013-06-27 Thread Kim Gräsman


Kim Gräsman added the comment:

Also, I believe the reason os.unlink raises access denied is because a 
junction point does not currently qualify as a directory  link, so its path 
is passed directly to DeleteFileW, which in turn refuses to delete a directory.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering

2013-06-27 Thread Łukasz Langa


Łukasz Langa added the comment:

The reason why I think it's wrong to special-case ABCs that are
explicitly in the MRO is that it's only one of four methods of virtual
subclassing:

1. Explicit MRO;

2. Abstract functionality implicitly implemented without any form of
   registration;

3. abc.register();

4. One of the above on a base of the type in question.

This creates more possibilities for conflicts than just the example
described in my last message. For instance, what's the preferred ABC
here, Iterable or Sized?

   class E(Sized):
  ...   def __len__(self):
  ... return 0
  ...   def __iter__(self):
  ... for i in []:
  ...   yield i

My answer is: neither. E equally is-a Sized and is-a Iterable. If the
dispatcher favors one over the other, you will get people upset about
the decision, no matter which one it is.

Note that the conflict arises only for multiple ABCs which end up *on
the same level* of the MRO. For instance in the example below the
dispatch always chooses the Iterable implementation (the functionality
appears directly on F, whereas Sized appears on a base):

   class HasSize(Sized):
  ...   def __len__(self):
  ... return 0
  ...
   class F(HasSize):
  ...   def __iter__(self):
  ... for i in []:
  ...   yield i

If we wanted to favor the ABCs that are explicitly in the MRO, what
should we choose in this case? If we say Sized, then it breaks the
whole idea of arranging the ABCs next to the class that first implements
them in the MRO.

But it gets better! Suppose you have a generic function with
implementations for Sized and Callable. Which implementation should we
choose for class G?

   class G(MutableMapping):
  ...   def __call__(self):
  ... return None
  ...   # the rest of the MutableMapping implementation

Seems like Sized because it is explicitly in the MRO, right? What about
H then?

   class H(dict):
  ...   def __call__(self):
  ... return None

Well, now it's suddenly Callable because Sized is only a virtual base
class. I don't think we should let that happen.

It all comes down to the question whether you consider ABCs to be bases
FOR REAL or only sort-of-but-not-really. I believe they're real bases
regardless of the method of registration. Implicit implementation and
abc.register() doesn't make the base any less real.

All in all, the user will ask: Hey, it's true, I have a tricky type
that subclasses both an ABC1 and an ABC2 and singledispatch raises
a RuntimeError. How do I make this work? The answer is simple: just
register a more specific implementation on the generic function, even if
it simply selects one of the existing ones:

  generic_func.register(TrickyType, generic_func.dispatch(ABC2))

Explicit is better than implicit.

--
Added file: http://bugs.python.org/file30711/issue18244.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18244
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword


Eric V. Smith added the comment:

I'm not sure what you're saying. Given the function definition, the way you're 
calling it is incorrect, and the error messages explain why.

Are you saying that these ways to call repeatfunc() are documented somewhere 
that needs fixing? I couldn't find that on the itertools documentation.

--
nosy: +eric.smith

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18313
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword


Changes by Eric V. Smith e...@trueblade.com:


--
status: open - pending

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18313
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword

2013-06-27 Thread py.user


Changes by py.user bugzilla-mail-...@yandex.ru:


--
status: open - pending

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18313
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword

2013-06-27 Thread py.user


py.user added the comment:

it should be: def repeatfunc(func, times, *args):
and None for times described in the docstring

--
status: pending - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18313
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18313] In itertools recipes repeatfunc() defines a non-keyword argument as keyword


Eric V. Smith added the comment:

I see. You can't call repeatfunc() and specify times with a named argument 
because of *args. Interesting. I'll let Raymond weigh in.

--
status: pending - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18313
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16251] pickle special methods are looked up on the instance rather than the type

2013-06-27 Thread Eric Snow


Eric Snow added the comment:

A backward compatible solution would be to do lookup on the class after trying 
the instance (and that came back None or isn't callable).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16251
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18315] bufsize parameter not documented in 2.7.5


New submission from Terrel Shumway:

for line in fileinput.input(files,inplace,backup,rU):
  File /usr/lib/python2.7/fileinput.py, line 253, in next
line = self.readline()
  File /usr/lib/python2.7/fileinput.py, line 346, in readline
self._buffer = self._file.readlines(self._bufsize)
TypeError: an integer is required

According to the documentation, my code was correct. But somewhere along the 
line, someone added a 'bufsize' parameter and didn't update the docstrings.

It's an easy fix, but I'll have to investigate when this broke.

--
assignee: docs@python
components: Documentation
messages: 191952
nosy: Terrel.Shumway, docs@python
priority: normal
severity: normal
status: open
title: bufsize parameter not documented in 2.7.5
type: behavior
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18315
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18315] bufsize parameter not documented in 2.7.5


Terrel Shumway added the comment:

http://hg.python.org/cpython/file/4dbbf322a9df/Lib/fileinput.py

In the process, I added an optional bufsize argument to the input()
function and the FileInput class.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18315
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18315] bufsize parameter not documented in 2.7.5

2013-06-27 Thread R. David Murray


R. David Murray added the comment:

A quick look at the VCS history indicates bufsize has been in there for a long 
time.  The sphinx docs are wrong as well.  This is correctly documented in 
python3, apparently as part of the conversion from [] notation to keyword 
notation in d143eb624cf5.

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18315
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18315] bufsize parameter not documented in 2.7.5


Terrel Shumway added the comment:

http://hg.python.org/cpython/file/68c776ba5ea5/Lib/fileinput.py

This is where the incorrect docstrings get added.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18315
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering

2013-06-27 Thread Guido van Rossum


Guido van Rossum added the comment:

Hm. I interpret explicit is better than implicit very differently.  I see a 
strict priority ordering from better to worse, in cases that would otherwise be 
ambiguous:

1. explicit base class (ABC or otherwise)

2. ABC explicitly registered

3. ABC implicitly inferred from presence of special method

I'm all for using all the other heuristics and rules you describe: inferred 
ABCs occur at the level where they are introduced, for example, and if two 
different ABCs are both inferred at the same level or both registered at the 
same level, that should be considered ambiguous.  But if one ABC is listed as 
an explicit base at some level and another is registered or implicit at the 
same level, the explicit base should just win -- just as if both ABCs were 
explicitly listed, the one listed first wins.

So the rule should be that registered and inferred bases are only considered 
after explicit bases at the same level.  (If you want the registered class to 
be preferred, you should add it as an explicit base instead -- and if you don't 
own the code, you should respect the choice of its author, or do something 
using subclassing.)

If it were me, explicitly registered ABCs would also trump inferred ABCs -- 
after all an inferred ABC is far from obvious to most readers and might even be 
an accident, and the situation can be rectified by explicit registration.

IOW, I disagree with your claim that Class C is-a Sized just as well as it 
is-a Iterable.  C is a Sized *more* than an Iterable because Size is an 
explicitly listed base class and Iterable is added through registration.  Same 
if Iterable were inferred.

(Just to be clear, this only applies if the ambiguity occurs at a single level. 
 ABCs explicitly listed, registered, or inferred at some base class have 
explicitly lower priority.)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18244
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16487] Allow ssl certificates to be specified from memory rather than files.

2013-06-27 Thread Kristján Valur Jónsson


Kristján Valur Jónsson added the comment:

2.7 is the pinnacle of pythonic achievement.  Particularly our branch of it :)
One day we'll move, I'm sure, when there is an opportune moment.  For example, 
if we were to start supporting a new game, a new platform. But for now, if it 
ain't broke, we won't fix it.

In fact, today I was asked about python for the ps4... It might be worth taking 
a look at porting p3k for that and making a clean break :)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16487
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18315] bufsize parameter not documented in 2.7.5


Terrel Shumway added the comment:

Here is a patch against the 2.7 branch.  It will probably also apply to 2.6 if 
anyone cares.

--
keywords: +patch
Added file: http://bugs.python.org/file30712/fileinput-document-bufsize.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18315
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18315] bufsize parameter not documented in 2.7.5