Re: [Python-Dev] What to do with languishing patches?

[Georg Brandl]

Am 20.07.2010 06:37, schrieb Stephen J. Turnbull:
> Mark Lawrence writes:
> 
>  > Is this the same login as for the issue tracker or is a new one needed?
> 
> It's different.  Both trackers are supposed to support OpenID logins,
> I believe.  (However, there are somewhat frequent reports of
> difficulties with it; I don't know if the system is fully debugged.  I
> think most people are OK, but making a new login is the sure path.)

The meta tracker doesn't support OpenID (it's a very plain roundup
without customization).   The OpenID support of the Python tracker is
quite mature now, or so I've heard.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] OpenID login for Roundup bug trackers (was: What to do with languishing patches?)

[Ben Finney]

"Stephen J. Turnbull"  writes:

> Mark Lawrence writes:
>
> > On 18/07/2010 23:38, Alexander Belopolsky wrote:
> > > The direct link [to the “meta-tracker”] is
> > > http://psf.upfronthosting.co.za/roundup/meta/
> >
> > Is this the same login as for the issue tracker or is a new one
> > needed?
>
> It's different. Both trackers are supposed to support OpenID logins, I
> believe.

The tracker at http://psf.upfronthosting.co.za/roundup/meta/>
doesn't mention OpenID on its login form, so I must assume it doesn't
currently support it.

The Python bug tracker http://bugs.python.org/> does support
arbitrary OpenID for authentication. It didn't in the recent past, so
I'm very glad to see that it does now. I can finally get an account
there without the hassle of managing a site-specific auth set.

> (However, there are somewhat frequent reports of difficulties with it;
> I don't know if the system is fully debugged. I think most people are
> OK, but making a new login is the sure path.)

It worked for me so far on http://bugs.python.org/>, logging in
with my OpenID and then going through the registration process.

Thanks for drawing my attention to that; if the people who made OpenID
auth happen are observing this, then thank you all very much!

Any hope of feeding those changes back upstream so it's available to all
Roundup users at some point?

-- 
 \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\ so, Brain, but first you'd have to take that whole bridge |
_o__) apart, wouldn't you?” —_Pinky and The Brain_ |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python-dev signal-to-noise processing question

[Oleg Broytman]

On Mon, Jul 19, 2010 at 04:08:00PM -0600, average wrote:
> Wha?  How could this not be the right place?  He's not asking about
> USING python, but asking: WHERE in the PYTHON CODE BASE does the
> signal get checked?
> 
> A-bit-miffed-at-the-cold-shoulderly yours,
> 
> Marcos  (wink wink)

   I know, the task of sending answers like I've sent is quite
unappreciated. I know, the meaning of my answer is rude because, in short,
it's simply "Please, go away", and however I stress the "please" part it's
still "go away". If I were a help seeker it'd be quite a hard blow for me
to receive such an answer. Yes, I know.
   Still, two other alternatives are even worse. The first alternative is
to not answer "using" questions at all; quite rude. The second is answer
all questions and make the developers quit the list and found a new quiet
one.
   I don't see any other alternative, do you? Of those three - which one
do you prefer?
   The original question was about using python, that's my understanding.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenID login for Roundup bug trackers

[Martin v. Löwis]

Thanks for drawing my attention to that; if the people who made OpenID
auth happen are observing this, then thank you all very much!


You're welcome!


Any hope of feeding those changes back upstream so it's available to all
Roundup users at some point?


Hope dies last.

It's main foundation is an openid library that I wrote 
(http://pypi.python.org/pypi/openid2rp). As for the roundup integration, 
I likely won't have much time to contribute it back.


Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[岳帅杰]

Sorry, I don't know what is the "no constant arguments" guideline refers to.
Could you give me some more explanation?

By the way, I feel adding separate functions is not quiet worthy for such a
function.

On Tue, Jul 20, 2010 at 7:11 AM, Greg Ewing wrote:

> Ray Allen wrote:
>
>  I think both os.mkdir() and os.makedirs() should add a keyword argument to
>> suppress the "OSError: [Errno 17] File exists".
>>
>
> This could be seen as violating the "no constant arguments"
> guideline. Maybe separate function would be better?
>
>
> --
> Greg
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ysj.ray%2Bpython-dev%40gmail.com
>



-- 
Ray Allen
Best wishes!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Steven D'Aprano]

On Tue, 20 Jul 2010 06:49:44 pm 岳帅杰 wrote:
> Sorry, I don't know what is the "no constant arguments" guideline
> refers to. Could you give me some more explanation?

It refers to the guideline that you shouldn't have a single function 
with two (or more) different behaviour and an argument that does 
nothing but select between them. Here is a toy example:

def change_case(s, make_upper=True):
if make_upper:
return s.upper()
else:
return s.lower()


> By the way, I feel adding separate functions is not quiet worthy for
> such a function.

I tend to agree. Perhaps all we need is a recipe in the docs:

try:
os.makedirs(path)
except OSError, e:
if e.errno != 17:
raise

I think that's all it takes to get the behaviour wanted without any 
false negatives, and four lines is short enough to use in-place, or if 
you prefer it's easy enough to wrap it in a function in your own 
module. Not everything needs to be a built-in.

I'm -0 on adding an argument to os.makedirs, +0 on adding a variant 
function to os, and +0.5 on adding the variant to the shutil module.


-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] tracker contribution

[R. David Murray]

On Mon, 19 Jul 2010 00:06:32 +0100, Mark Lawrence  
wrote:
> You all might have gathered that I'm very dispirited by the negative 
> attitudes that I get from a relatively small minority of Python people. 
>   I might as well quit because it doesn't do my mental health a great 
> deal of good.  That minority will of course be very happy to see me go 
> because they'll be able to sit back on their loathsome, spotty behinds 
> picking blackheads and resort to the usual "we're far too busy to do 
> anything" routine.  You might understand that I don't completely agree 
> with this.

Mark, please understand that (as far as I can tell) the "small minority
of people" of whom you are speaking here, who have offered advice on how
to make your triage work more helpful to the Python community, are some
of the most *active* Python committers and community participants.

I think the best thing for your mental health would be to see if you can
just ignore things that seem negative, and see if there's any useful
advice in what is said.  And if you don't find the opinions useful,
then you don't.  The essence of community is cooperation, and cooperation
can't happen without communication; and yes, some of it is going to sound
negative (and some of it will even *be* negative...that's human nature,
as your message demonstrates).  Which I think you have done, since I've
seen you put into practice some of the suggestions that were made.

I regret that I haven't been able to follow your prolific work closely
(in fact, I have had to stop following the bugs list, I now just watch
the new bugs list...not just due to the volume, but because of my other
commitments, but the volume certainly contributed, unfortunately[*]).
I especially regret that because I was the one who gave you developer
privs on the tracker, and so I have something of a responsibility to so.
I'm relying on the positive feedback that you are getting here to assuage
my guilt for not paying closer attention to your work, and also on the
fact that I have seen the quality of your work improve over time from
the bugs I have reviewed that you've commented on.

--
R. David Murray  www.bitdance.com

[*] I think this may be a source of some of the discomfort you have
sensed.  I had been used to being able to keep up with the bugs list,
but even before you started your work I was already thinking that that
wasn't going to work for much longer...as Python becomes more popular, the
number of bug reports increases, and as we add more committers and gather
more people who are actively helping out, the message traffic increases.
This is *good*:  it means we are getting more done (well, at least if
we can continue to add committers it does), but it also means that it
is no longer possible for a part time volunteer to keep an overview
of the bug/patch activity.  The danger, of course, is that more things
will slip through the cracksbut this is not, as you have observed,
a new problem.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Nick Coghlan]

On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano  wrote:
> I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
> function to os, and +0.5 on adding the variant to the shutil module.

shutil seems like the place for it to me. The subtlety of getting the
error suppression correct makes it worth implementing this once and
for all I think.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Curious datetime method

[Anders Sandvig]

> I wonder why would anyone want to use datetime.today() instead of
> datetime.now()?

Because this method is also present in datetime.date. Thus, you can
reference stuff like  d.today().day without caring whether d is a date
or a datetime object.


Anders
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Isaac Morland]

On Tue, 20 Jul 2010, Steven D'Aprano wrote:


I tend to agree. Perhaps all we need is a recipe in the docs:

try:
   os.makedirs(path)
except OSError, e:
   if e.errno != 17:
   raise


What if the path or a parent of it already exists as a file?  If one has 
requested -p I believe one typically wants this to be an error.  And I 
assume that one would not use the literal 17 in production code.


Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[R. David Murray]

I'd go with putting it in shutil.  We could also add a function there
that wraps up the recipe in issue 9311 to work around the quirks of
os.access on FreeBSD (and possibly other platforms).

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python-dev signal-to-noise processing question

[Steve Holden]

On 7/20/2010 11:59 AM, Oleg Broytman wrote:
> On Mon, Jul 19, 2010 at 04:08:00PM -0600, average wrote:
>> Wha?  How could this not be the right place?  He's not asking about
>> USING python, but asking: WHERE in the PYTHON CODE BASE does the
>> signal get checked?
>>
>> A-bit-miffed-at-the-cold-shoulderly yours,
>>
>> Marcos  (wink wink)
> 
>I know, the task of sending answers like I've sent is quite
> unappreciated. I know, the meaning of my answer is rude because, in short,
> it's simply "Please, go away", and however I stress the "please" part it's
> still "go away". If I were a help seeker it'd be quite a hard blow for me
> to receive such an answer. Yes, I know.

No, the reply is fine as far as it goes, and I am sure the poster did
get a reply from c.l.py, but his question revealed a thirst for
knowledge not usually evidenced in non-dev inquiries.

>Still, two other alternatives are even worse. The first alternative is
> to not answer "using" questions at all; quite rude. The second is answer
> all questions and make the developers quit the list and found a new quiet
> one.
>I don't see any other alternative, do you? Of those three - which one
> do you prefer?
>The original question was about using python, that's my understanding.

Could we perhaps include a link to the material for Python devs, just so
people realise that although they are being sent away for good reason,
if they are interested in joining the dev community there is material to
help and guide them.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python-dev signal-to-noise processing question

[Alexander Belopolsky]

On Tue, Jul 20, 2010 at 6:59 AM, Oleg Broytman  wrote:
..
>   I know, the task of sending answers like I've sent is quite
> unappreciated. I know, the meaning of my answer is rude because, in short,
> it's simply "Please, go away", and however I stress the "please" part it's
> still "go away". If I were a help seeker it'd be quite a hard blow for me
> to receive such an answer. Yes, I know.
>   Still, two other alternatives are even worse. The first alternative is
> to not answer "using" questions at all; quite rude. The second is answer
> all questions and make the developers quit the list and found a new quiet
> one.
>   I don't see any other alternative, do you? Of those three - which one
> do you prefer?

People dislike canned responses no matter how friendly and polite they
sound.   I believe python-dev tradition is to redirect the poster to
python-list but still include at least a hint to what the answer to
his or her question is.   I believe this works fairly well.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Fred Drake]

On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano  wrote:
> It refers to the guideline that you shouldn't have a single function
> with two (or more) different behaviour and an argument that does
> nothing but select between them.

In particular, when that argument is almost never given a variable
value, but is specified using a constant at the call site.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Éric Araujo]

Le 18/07/2010 23:17, Alexander Belopolsky a écrit :
> On Sun, Jul 18, 2010 at 5:02 PM, Mark Lawrence  
> wrote:
>> Maybe going off on a tangent, but I find it frustrating because you (plural)
>> can't find a given module on the issue tracker.  Say I'm looking for issues
>> relating to smtplib, all I can do is look in the title of the issue.  Have I
>> missed something, or is there a need to have subsections so that if Lib is
>> selected, you can then find the appropriate module?
> 
> I don't think you missed anything and I would also find this feature
> useful.  For example, I recently took interest in datetime and pickle
> modules, but other than full text search, there was no way to find all
> issues related to either of these two modules.  The "Components" list
> is somewhat arbitrary with narrow components such as ctypes and broad
> components such a Lib.

When I suggested such a modules list on
, R. David Murray
replied “This has been suggested and rejected a number of times on
python-dev” but I have been unable to find those discussions.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Curious datetime method

[Alexander Belopolsky]

On Tue, Jul 20, 2010 at 9:57 AM, Anders Sandvig
 wrote:
>> I wonder why would anyone want to use datetime.today() instead of
>> datetime.now()?
>
> Because this method is also present in datetime.date. Thus, you can
> reference stuff like  d.today().day without caring whether d is a date
> or a datetime object.

For this particular use it is not necessary for today() method to have
covariant returns.  In other words, if datetime.today() returned a
date object in the same way as date.today() does, you could still
write  d.today().day.  Moreover, since today() is a class method, the
result does not depend on d, so you can simply do date.today().day.

A more interesting use case would be a function that tells whether d
is in the future:

def isfuture(d):
  return d > d.today()

Here covariant return is necessary because you cannot compare datetime
to date and even if you could, this is probably not what you want in
this case.

This implementation of isfuture() has a problem: it does not work with
aware datetime objects.  To make that work, we would need today(tz)
method that can account for a timezone, or better have now(tz=None)
available as a date class method:

def isfuture(d):
  return d > d.now(d.tzinfo)

Furthermore, this use case does not explain the need to have
datetime.today() respect overriding of fromtimestamp() in datetime
subclasses or having to reproduce datetime.fromtimestamp(time.time())
with all its undefined behavior that comes with floating point
timestamps.

In the ideal world, I would like today() to accept tz and always
return date object while adding "covariant" now([tz]) method to date
and possibly even time class.  (The later is the subject of
http://bugs.python.org/issue8902).

In the real world where we have to take backward compatibility into
account, I would like to make today() and now() to be the same: both
taking optional tz argument, both available as either date or datetime
methods and both covariant.  the justification for having two methods
doing exactly the same will be just readability: date.today() and
datetime.now() are more readable than date.now() and datetime.today().
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Ron Adam]

On 07/20/2010 10:43 AM, Fred Drake wrote:

On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano  wrote:

It refers to the guideline that you shouldn't have a single function
with two (or more) different behaviour and an argument that does
nothing but select between them.


In particular, when that argument is almost never given a variable
value, but is specified using a constant at the call site.


I was thinking it should have been two functions, but I realized there is 
more subtleties involved than simply just reusing a directory that already 
exists.



One possibility might be...

mkdir(path [, allow=None, mode=0777])

Where None can be replaced with one or more of the following.

'exists' dir can already exist  (with same permissions as mode)
'case'   dir case can be different. (Windows)
'files'  dir can have files in it.

... or a string containing the initials.


It doesn't fall under the single constant rule if done this way.


Ron







___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Michael Foord]

On 20/07/2010 14:43, Nick Coghlan wrote:

On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano  wrote:
   

I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
function to os, and +0.5 on adding the variant to the shutil module.
 

shutil seems like the place for it to me. The subtlety of getting the
error suppression correct makes it worth implementing this once and
for all I think.
   


Really - so we have two almost identical functions with slightly 
different behaviour in different standard library modules? Aren't the 
Python APIs for working with files and paths confused enough already. 
That seems crazy to me and a switch on os.makedirs much more sensible.


Michael

Cheers,
Nick.


   



--
http://www.ironpythoninaction.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Ron Adam]

On 07/20/2010 11:47 AM, Ron Adam wrote:



On 07/20/2010 10:43 AM, Fred Drake wrote:

On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano
wrote:

It refers to the guideline that you shouldn't have a single function
with two (or more) different behaviour and an argument that does
nothing but select between them.


In particular, when that argument is almost never given a variable
value, but is specified using a constant at the call site.


I was thinking it should have been two functions, but I realized there
is more subtleties involved than simply just reusing a directory that
already exists.


One possibility might be...

mkdir(path [, allow=None, mode=0777])

Where None can be replaced with one or more of the following.

'exists' dir can already exist (with same permissions as mode)
'case' dir case can be different. (Windows)
'files' dir can have files in it.



Add

  'path', Complete path as -p option does.



... or a string containing the initials.


It doesn't fall under the single constant rule if done this way.


Ron


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Fred Drake]

On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam  wrote:
> It doesn't fall under the single constant rule if done this way.

If the value for 'allow' were almost always given as a constant, this
would be an argument for three functions instead of one.

The guideline has little to do with the type of the value, but the
number of possible values ("small") and whether they're normally given
as constants in the code.

If there's more than one, and combinations then to vary, then keeping
them as args makes sense.

Also, if we don't know what we want the functionality to be, as you
suggest, then worry about that is premature.  :-)  Let's decide on the
required functionality first.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] :program: markup in .rst documentation

[Eli Bendersky]

While fixing the :option: markup in the library docs
(http://bugs.python.org/issue9312), another question came up:

In a few places, documenting a program execution with options was made with:

:program:`python regrtest.py` :option:`test_spam.py`

Since my patch had the :option: markup removed, this became:

:program:`python regrtest.py test_spam.py`

However, according to Éric Araujo's comment, due to the intention of
the :program: markup this should actually just say:

``python regrtest.py test_spam.py``

Which way to choose? I will update my patch to reflect this.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] :program: markup in .rst documentation

[Alexander Belopolsky]

On Tue, Jul 20, 2010 at 1:16 PM, Eli Bendersky  wrote:
..
>
> ``python regrtest.py test_spam.py``
>
> Which way to choose? I will update my patch to reflect this.

Sorry to add the third way to the mix, but shouldn't the recommended
way to run a module as a script be python -m modname?  As in

$ python -m test.regrtest test_spam
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] :program: markup in .rst documentation

[Fred Drake]

Switching to "python -m" is generally good where it applies (as in this case).

The original intent for :option: and :program: were in their use as
references rather than in sample command lines.

Georg should be the final arbiter, but I'd be in favor of ``...`` for
command lines.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] :program: markup in .rst documentation

[Éric Araujo]

> Sorry to add the third way to the mix, but shouldn't the recommended
> way to run a module as a script be python -m modname?  As in
> 
> $ python -m test.regrtest test_spam

This is true but orthogonal to our problem, which is that
:program:`python -m thing` is wrong if I understood the doc rightly and
should be replaced by ``python -m thing``.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Does trace modules have a unit test?

[Eli Bendersky]

I've opened issue 9315 (http://bugs.python.org/issue9315) to address
the lack of unit tests for the trace.py module. I hope to get to it in
a few days and add some tests.

As Terry wrote in the beginning of this thread, Lib/test/test_trace.py
currently tests the sys.settrace module, so the tests of trace.py
should find a new home. Does Lib/test/test_trace_module.py make sense
or is something else preferable?

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python-dev signal-to-noise processing question

[Terry Reedy]

On 7/20/2010 6:59 AM, Oleg Broytman wrote:


I know, the task of sending answers like I've sent is quite
unappreciated.


*I* appreciate it. I mostly do not respond to such because I expect you 
or Aahz will.



I know, the meaning of my answer is rude because, in short,
it's simply "Please, go away", and however I stress the "please" part it's
still "go away". If I were a help seeker it'd be quite a hard blow for me
to receive such an answer. Yes, I know.


1. I suggested one improvement to the canned response in my previous 
post: expand 'using' to 'using or understanding'.


2. Here is another: mention that Python developers who are willing to 
answer non-development questions already participate on 
python-list/gmane.comp.python.general to answer such questions there.


3. That brings up: also mention gmane.comp.python.general, for those 
like me who prefer the newsgroup interface.


4. Alexander Belopolsky wrote:
"People dislike canned responses no matter how friendly and polite they
sound.   I believe python-dev tradition is to redirect the poster to
python-list but still include at least a hint to what the answer to
his or her question is."

I believe you *did* do that, but it was easily missed. So: end the 
boilerplate with

-

and put hints here so they stand out.


Still, two other alternatives are even worse. The first alternative is
to not answer "using" questions at all; quite rude. The second is answer
all questions and make the developers quit the list and found a new quiet
one.


I brought up that same possibility.


I don't see any other alternative, do you? Of those three - which one
do you prefer?
The original question was about using python, that's my understanding.


I agree that it appeared to be, but it was phrased in terms of 
understanding its operation, hence the claim that it was not, and hence 
suggestion 1) above.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Terry Reedy]

On 7/20/2010 12:49 PM, Michael Foord wrote:

On 20/07/2010 14:43, Nick Coghlan wrote:

On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano
wrote:

I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
function to os, and +0.5 on adding the variant to the shutil module.

shutil seems like the place for it to me. The subtlety of getting the
error suppression correct makes it worth implementing this once and
for all I think.


Really - so we have two almost identical functions with slightly
different behaviour in different standard library modules? Aren't the
Python APIs for working with files and paths confused enough already.
That seems crazy to me and a switch on os.makedirs much more sensible.


Guido has twice approved changing os.makedirs.
First 2 1/2 years ago in
http://bugs.python.org/msg58924  from
http://bugs.python.org/issue1675
and recently in this thread
http://mail.python.org/pipermail/python-dev/2010-July/102027.html
which lead to
http://bugs.python.org/issue9299
Both issues have a patch and I reviewed their major similarities and 
minor differences in

http://bugs.python.org/msg110770

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Does trace modules have a unit test?

[Reid Kleckner]

On Tue, Jul 20, 2010 at 10:51 AM, Eli Bendersky  wrote:
> As Terry wrote in the beginning of this thread, Lib/test/test_trace.py
> currently tests the sys.settrace module, so the tests of trace.py
> should find a new home. Does Lib/test/test_trace_module.py make sense
> or is something else preferable?

IMO you should just rename test_trace.py to test_settrace.py, and put
the trace.py tests in test_trace.py.

Reid
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Bill Janssen]

Michael Foord  wrote:

> On 20/07/2010 14:43, Nick Coghlan wrote:
> > On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano  
> > wrote:
> >
> >> I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
> >> function to os, and +0.5 on adding the variant to the shutil module.
> >>  
> > shutil seems like the place for it to me. The subtlety of getting the
> > error suppression correct makes it worth implementing this once and
> > for all I think.
> >
> 
> Really - so we have two almost identical functions with slightly
> different behaviour in different standard library modules? Aren't the
> Python APIs for working with files and paths confused enough
> already. That seems crazy to me and a switch on os.makedirs much more
> sensible.

Yep, me too.

Bill

> 
> Michael
> > Cheers,
> > Nick.
> >
> >
> >
> 
> 
> -- 
> http://www.ironpythoninaction.com/
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[R. David Murray]

On Tue, 20 Jul 2010 17:45:42 +0200,  wrote:

On 18/07/2010 23:17, Alexander Belopolsky wrote:
> On Sun, Jul 18, 2010 at 5:02 PM, Mark Lawrence  
> wrote:
>> Maybe going off on a tangent, but I find it frustrating because you (plural)
>> can't find a given module on the issue tracker.  Say I'm looking for issues
>> relating to smtplib, all I can do is look in the title of the issue.  Have I
>> missed something, or is there a need to have subsections so that if Lib is
>> selected, you can then find the appropriate module?
>
> I don't think you missed anything and I would also find this feature
> useful.  For example, I recently took interest in datetime and pickle
> modules, but other than full text search, there was no way to find all
> issues related to either of these two modules.  The "Components" list
> is somewhat arbitrary with narrow components such as ctypes and broad
> components such a Lib.

When I suggested such a modules list on
, R. David Murray
replied “This has been suggested and rejected a number of times on
python-dev” but I have been unable to find those discussions.

During the most recent discussion I can remember, I thought I remembered
Stephen Trumble saying that they'd tried that in xemacs and it really
hadn't worked very well.  Since he now says he thinks it's a good idea
(or more likely I misremembered what he said the first time), it sounds
like we should consider it again.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Does trace modules have a unit test?

[Alexander Belopolsky]

On Tue, Jul 20, 2010 at 2:12 PM, Reid Kleckner  wrote:
..
> IMO you should just rename test_trace.py to test_settrace.py, and put
> the trace.py tests in test_trace.py.

+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Ron Adam]

On 07/20/2010 12:00 PM, Fred Drake wrote:

On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam  wrote:

It doesn't fall under the single constant rule if done this way.


If the value for 'allow' were almost always given as a constant, this
would be an argument for three functions instead of one.

The guideline has little to do with the type of the value, but the
number of possible values ("small") and whether they're normally given
as constants in the code.

If there's more than one, and combinations then to vary, then keeping
them as args makes sense.

Also, if we don't know what we want the functionality to be, as you
suggest, then worry about that is premature.  :-)  Let's decide on the
required functionality first.


That makes sense. :-)

Another things that comes to mind, is it may make sense to choose either 
strict, and have args to *allow* different cases, or to choose lenient, and 
have args to *restrict* different cases.


That keeps it somewhat less confusing, and doesn't require memorization to 
remember what the mixed mode default might be.  (Unless we use a single 
combination 99% of the time, then that probably *should* be the default.)


Ron

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Alexander Belopolsky]

On Tue, Jul 20, 2010 at 2:16 PM, R. David Murray  wrote:
..
> During the most recent discussion I can remember, I thought I remembered
> Stephen Trumble saying that they'd tried that in xemacs and it really
> hadn't worked very well.  Since he now says he thinks it's a good idea
> (or more likely I misremembered what he said the first time), it sounds
> like we should consider it again.

The only problem I can see with this feature is how to design a usable
UI.  Have you ever cursed these extra clever address forms that make
you select a state from a drop-down list of 50 if not a country from
the list of 100+?  A text field with auto-completion/correction and
validation would be the best, but may get cluttered if multiple
modules are affected.  We actually have similar usability issue with
the nosy list.  The + button was a great addition, but I would also
like to see a user list integration that would allow me to add other
by real name or by approximate username spelling.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python-dev signal-to-noise processing question

[Oleg Broytman]

On Tue, Jul 20, 2010 at 01:51:07PM -0400, Terry Reedy wrote:
> On 7/20/2010 6:59 AM, Oleg Broytman wrote:
> 1. I suggested one improvement to the canned response in my previous  
> post: expand 'using' to 'using or understanding'.

   I changed wording to "if you're having problems learning, understanding
or using Python"

> 2. Here is another: mention that Python developers who are willing to  
> answer non-development questions already participate on  
> python-list/gmane.comp.python.general to answer such questions there.

   Good addition, thank you! I'll add something like "there are Python
developers who participate on python-list/comp.lang.python".

> 3. That brings up: also mention gmane.comp.python.general, for those  
> like me who prefer the newsgroup interface.

   It is referenced at http://www.python.org/community/lists/ and my text
points to http://www.python.org/community/; I think it's enough.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Oleg Broytman]

On Tue, Jul 20, 2010 at 02:53:53PM -0400, Alexander Belopolsky wrote:
> Have you ever cursed these extra clever address forms that make
> you select a state from a drop-down list of 50 if not a country from
> the list of 100+?

   Well, I have never, because in any of these drop-down lists I can press
a few first letters of the name and the cursor jumps to the country. I
often select countries in such lists in web browsers.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Alexander Belopolsky]

On Tue, Jul 20, 2010 at 3:05 PM, Oleg Broytman  wrote:
..
>   Well, I have never, because in any of these drop-down lists I can press
> a few first letters of the name and the cursor jumps to the country. I
> often select countries in such lists in web browsers.

Really?  What smartphone are you using?  :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Oleg Broytman]

On Tue, Jul 20, 2010 at 03:13:41PM -0400, Alexander Belopolsky wrote:
> On Tue, Jul 20, 2010 at 3:05 PM, Oleg Broytman  wrote:
> ..
> >   Well, I have never, because in any of these drop-down lists I can press
> > a few first letters of the name and the cursor jumps to the country. I
> > often select countries in such lists in web browsers.
> 
> Really?  What smartphone are you using?  :-)

   Are you developing an interface for smartphones? Wouldn't it hurt
usability for desktops/notebooks?

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Alexander Belopolsky]

On Tue, Jul 20, 2010 at 3:38 PM, Oleg Broytman  wrote:
..
>> Really?  What smartphone are you using?  :-)
>
>   Are you developing an interface for smartphones? Wouldn't it hurt
> usability for desktops/notebooks?

You missed the smiley in my response.  But seriously, I do find the
interfaces that work well on smartphones to improve usability for
desktops/notebooks.

Back on the topic, I don't think a drop-down list of all modules is
workable even in browsers that display them as combo boxes.  How many
modules do we have in std lib?  About 100? Maybe more.  What if the
bug affects several modules?  What if the patch modifies several
modules?  Do we want to allow selection of multiple modules for the
given issue?  The components window is already hard to use if you want
to select say both Extension Modules and Windows.  This is with just
about 20 entries.   Imagine over 100 entries there.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Oleg Broytman]

On Tue, Jul 20, 2010 at 04:27:45PM -0400, Alexander Belopolsky wrote:
> On Tue, Jul 20, 2010 at 3:38 PM, Oleg Broytman  wrote:
> ..
> >> Really?  What smartphone are you using?  :-)
> >
> >   Are you developing an interface for smartphones? Wouldn't it hurt
> > usability for desktops/notebooks?
> 
> You missed the smiley in my response.

   I am a well-known wet blanket. (-:

> But seriously, I do find the
> interfaces that work well on smartphones to improve usability for
> desktops/notebooks.

   Sometimes they do and sometimes they don't. Big screen(s) and a wheeled
multi-button mouse allow quite a different interface compared to small
screen and single-finger taps.

> Back on the topic, I don't think a drop-down list of all modules is
> workable even in browsers that display them as combo boxes.  How many
> modules do we have in std lib?  About 100? Maybe more.  What if the
> bug affects several modules?  What if the patch modifies several
> modules?  Do we want to allow selection of multiple modules for the
> given issue?  The components window is already hard to use if you want
> to select say both Extension Modules and Windows.  This is with just
> about 20 entries.   Imagine over 100 entries there.

   In this particular case I'd rather tend to agree - an editable
single-line box to enter space-*and*-comma-separated modules list would be
the best interface.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] MSDN subscription extensions?

[David Bolen]

As one of the beneficiaries of the efforts (much appreciated) last
year to obtain Microsoft MSDN subscriptions for developers/testers (in
my case, primarily buildbot operation), I was wondering if anyone
might know if those subscriptions will be able to be renewed this
year?

-- David

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Terry Reedy]

In any case, a module list should be separate from components.

On 7/20/2010 4:43 PM, Oleg Broytman wrote:


In this particular case I'd rather tend to agree - an editable
single-line box to enter space-*and*-comma-separated modules list would be
the best interface.


An interesting idea.
In any case, a module list should be separate from components. A custom 
app would only allow entry there if Lib is a selected component. Such 
could also use a selecton screen with multiple columns rather than a 
single column. But we are limited to what can be done with a web 
interface. If Lib is not selected and modules are entered, Lib could be 
autoselected as it is unlikely that one would type in module names if it 
should not be. A back-end check against would be nice, but would suffer 
from the update problem, as well as module name changes.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] MSDN subscription extensions?

[Brian Curtin]

On Tue, Jul 20, 2010 at 16:53, David Bolen  wrote:

> As one of the beneficiaries of the efforts (much appreciated) last
> year to obtain Microsoft MSDN subscriptions for developers/testers (in
> my case, primarily buildbot operation), I was wondering if anyone
> might know if those subscriptions will be able to be renewed this
> year?
>
> -- David
>

I'll add your name to the list, wait a few days for others to respond, then
contact Microsoft together as a group. For anyone else out there with a
current subscription which will be expiring soon, email me privately and
I'll get you going with an extension.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Does trace modules have a unit test?

[Nick Coghlan]

On Wed, Jul 21, 2010 at 4:18 AM, Alexander Belopolsky
 wrote:
> On Tue, Jul 20, 2010 at 2:12 PM, Reid Kleckner  
> wrote:
> ..
>> IMO you should just rename test_trace.py to test_settrace.py, and put
>> the trace.py tests in test_trace.py.
>
> +1

Yep, we're pretty free to rename stuff as required inside the test
suite. The only real exception is test.support, as that's a documented
standard library module.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Nick Coghlan]

On Wed, Jul 21, 2010 at 4:53 AM, Alexander Belopolsky
 wrote:
> The only problem I can see with this feature is how to design a usable
> UI.  Have you ever cursed these extra clever address forms that make
> you select a state from a drop-down list of 50 if not a country from
> the list of 100+?  A text field with auto-completion/correction and
> validation would be the best, but may get cluttered if multiple
> modules are affected.  We actually have similar usability issue with
> the nosy list.  The + button was a great addition, but I would also
> like to see a user list integration that would allow me to add other
> by real name or by approximate username spelling.

Despite the nosy list's issues, I think it is actually a better model
here than the components list.

That is:
- comma separated list in main form that you can just type into
- separate search form that pops up to allow multiple selections

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Cameron Simpson]

On 20Jul2010 17:49, Michael Foord  wrote:
| On 20/07/2010 14:43, Nick Coghlan wrote:
| >On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano  
wrote:
| >>I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
| >>function to os, and +0.5 on adding the variant to the shutil module.
| >shutil seems like the place for it to me. The subtlety of getting the
| >error suppression correct makes it worth implementing this once and
| >for all I think.
| 
| Really - so we have two almost identical functions with slightly
| different behaviour in different standard library modules?

Three if you count os.mkdir itself as well.

| Aren't
| the Python APIs for working with files and paths confused enough
| already. That seems crazy to me and a switch on os.makedirs much
| more sensible.

+1 from me. Hasn't the BDFL blessed this particular suggestion too?

Disclaimer: I am _not_ a dev.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

I am not a free man, I am a number. - Beirne Konarski 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Guido van Rossum]

On Tue, Jul 20, 2010 at 11:35 PM, Cameron Simpson  wrote:
> On 20Jul2010 17:49, Michael Foord  wrote:
> | On 20/07/2010 14:43, Nick Coghlan wrote:
> | >On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano  
> wrote:
> | >>I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
> | >>function to os, and +0.5 on adding the variant to the shutil module.
> | >shutil seems like the place for it to me. The subtlety of getting the
> | >error suppression correct makes it worth implementing this once and
> | >for all I think.
> |
> | Really - so we have two almost identical functions with slightly
> | different behaviour in different standard library modules?
>
> Three if you count os.mkdir itself as well.
>
> | Aren't
> | the Python APIs for working with files and paths confused enough
> | already. That seems crazy to me and a switch on os.makedirs much
> | more sensible.
>
> +1 from me. Hasn't the BDFL blessed this particular suggestion too?

Now I have. :-) -1 on a new function (despite the constant-argument
guideline) and +1 on a flag. If it weren't for backwards compatibility
I'd just change os.makedirs() to act like mkdir -p period, but the
last opportunity we had for that was Python 3.0.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Georg Brandl]

Am 20.07.2010 23:09, schrieb Terry Reedy:
> In any case, a module list should be separate from components.
> 
> On 7/20/2010 4:43 PM, Oleg Broytman wrote:
> 
>> In this particular case I'd rather tend to agree - an editable
>> single-line box to enter space-*and*-comma-separated modules list would be
>> the best interface.
> 
> An interesting idea.

And hardly a new idea :)  I don't know how often I've now proposed tags
for tracker issues...

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Greg Ewing]

岳帅杰 wrote:
Sorry, I don't know what is the "no constant arguments" guideline refers 
to. Could you give me some more explanation?


It's a rule of thumb that Guido says he uses when
designing an API. If in the majority of use cases for
a proposed function, one of its arguments would always
be a constant that chooses between two or more different
behaviours, then it would probably be better to have
separate functions for each of the behaviours.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Greg Ewing]

Steven D'Aprano wrote:

Perhaps all we need is a recipe in the docs:

try:
os.makedirs(path)
except OSError, e:
if e.errno != 17:
raise


I don't like writing code that depends on particular
errno values, because I don't trust it to work cross-
platform.

Also it seems suboptimal to require people to use a
recipe like this to get the behaviour that is wanted
in the overwhelming majority of cases.

I don't see what would be so bad about adding a new
function for this. Think of it as correcting the mistake
of not making makedirs() behave this way from the
beginning.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mkdir -p in python

[Ray Allen]

>
> I don't see what would be so bad about adding a new

function for this. Think of it as correcting the mistake

of not making makedirs() behave this way from the

beginning.


If you want to add a new function,  then what its name should be? I guess it
should be too similar as existing ones. It's confusing for using because
they have similar names and do the same major things except exception. For
users it's easier to remember one function than tow. If we want to correct a
mistake, it's better not to import another mistake.


I don't like writing code that depends on particular

errno values, because I don't trust it to work cross-

platform.

I think in this case, the errno is generate by c standard library, which can
be seen as cross-platform.





>
>
> --
> Greg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ysj.ray%2Bpython-dev%40gmail.com
>



-- 
Ray Allen
Best wishes!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Stephen J. Turnbull]

R. David Murray writes:

 > During the most recent discussion I can remember, I thought I remembered
 > Stephen Trumble saying that they'd tried that in xemacs and it really
 > hadn't worked very well.  Since he now says he thinks it's a good idea
 > (or more likely I misremembered what he said the first time), it sounds
 > like we should consider it again.

No, you didn't misremember.  I changed my mind.  Now I know more about
*why* it didn't appeal to me at the time: the UI for links and
multilinks with large numbers of selectable value, and we had a poor
configuration of nosy lists, so people weren't getting on the right
issues.  So, I don't recommend it with the stock Roundup UI if there
are going to be more modules than would fit on a page (50), and the UI
is somewhat annoying for as few as 20 checkboxes.

Unfortunately, I can't offer a patch, but the basic things that need
to be done are (1) make the "multilink input" window multicolumn (you
could get 100 module names to fit in the window, but 50 should be
plenty for this purpose), and (2) bump the limit on entries per page
so they all fit on one page.

Also, it would be nice if there were a UI to make oneself "auto-nosy"
on certain modules.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What to do with languishing patches?

[Stephen J. Turnbull]

Oleg Broytman writes:

 > > Back on the topic, I don't think a drop-down list of all modules is
 > > workable even in browsers that display them as combo boxes.  How many
 > > modules do we have in std lib?  About 100? Maybe more.  What if the
 > > bug affects several modules?  What if the patch modifies several
 > > modules?  Do we want to allow selection of multiple modules for the
 > > given issue?

Roundup has a multilink type which allows selection of multiple items.
The input interface is a list of checkboxes formatted as a two-column
HTML table (checkbox and module name), not a combo box (which doesn't
allow a list of selections).

XEmacs uses such a multilink for its 147 Modules (in Python's tracker,
that would be Components).  For me, with my most frequently affected
modules living at the top of the first page of the module list I have
no problem with the multilink interface; it's when I need to find a
library on the second or third page that things get frustrating.

About 50 items with checkboxes should fit easily in a popup window in
table form if there were multiple columns (say four or five); it just
hasn't been coded yet.  And there's no reason the table has to fit in
the window.  A scrolling table would be fine for this, as long as the
total height wasn't more than about 3 times that of the window.  I
would guess that a table of checkboxes could easily handle a multilink
with about 200 options, and would be usable both by newbies and
triagers.  Possibly active developers would find the one-line text-
entry more efficient, but I think it would be a close race:

 >In this particular case I'd rather tend to agree - an editable
 > single-line box to enter space-*and*-comma-separated modules list
 > would be the best interface.

For active developers, yes.  But this is unhelpful for people who
aren't hyper-familiar with the component list or who can't spell.  The
checkboxes are also faster when doing triage, at least if the relevant
component is in the first screen.  Maybe with enough Javascript to
give autocompletion and validation, a space/comma-separated list would
be OK, but I'm dubious.  Also, some of our users are able to pick out
which modules seem to be involved from backtraces in error messages,
but not without a list.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com