Sounds like a good idea to try to remove redundant cookies *and* to
remove most occasional use of non-ASCII characters outside comments
(except for unittests specifically trying to test Unicode features).
Personally I would use \xXX escapes instead of spelling out the
characters in shlex.py, for ex
On Mon, Jul 19, 2010 at 12:21 AM, Alexander Belopolsky
wrote:
> On Mon, Jul 19, 2010 at 12:12 AM, Eli Bendersky wrote:
> ..
>> stdout output can be captured, but what about the .cover files? Can a Python
>> unit test create temporary files in tmp/ (or somewhere else) as part of its
>> testing, or
On Mon, Jul 19, 2010 at 12:12 AM, Eli Bendersky wrote:
..
> stdout output can be captured, but what about the .cover files? Can a Python
> unit test create temporary files in tmp/ (or somewhere else) as part of its
> testing, or is this forbidden?
>
That's perfectly fine. Grep in the Lib/test di
On Mon, Jul 19, 2010 at 07:02, Terry Reedy wrote:
> In reviewing
> http://bugs.python.org/issue9282
> the issue came up, where is the unit test for trace.py?
>
> test/test_trace.py is actually a test of the line trace facility of
> sys.settrace (and should have been called test_linetrace or test_
In reviewing
http://bugs.python.org/issue9282
the issue came up, where is the unit test for trace.py?
test/test_trace.py is actually a test of the line trace facility of
sys.settrace (and should have been called test_linetrace or
test_settrace). The only trace import Eli could find in Lib/test
On Sun, Jul 18, 2010 at 11:46 PM, Eli Bendersky wrote:
..
> However, I wonder what this means for backwards compatibility. Is it valid
> to switch trace.py to use the newer command-line argument parsing module
> that's only available in the newest versions of Python? I guess it could be
> since tr
On Mon, Jul 19, 2010 at 06:40, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> On Sun, Jul 18, 2010 at 11:28 PM, Eli Bendersky wrote:
> > .. So a policy has to be define regarding the
> > correct usage of these directives/markups, and probably documented in
> > Doc/documenting/mar
On Sun, Jul 18, 2010 at 11:28 PM, Eli Bendersky wrote:
> .. So a policy has to be define regarding the
> correct usage of these directives/markups, and probably documented in
> Doc/documenting/markup.rst
I wonder if in addition to documenting proper markup you could add an
option to argparse to g
On Mon, Jul 19, 2010 at 05:57, Eli Bendersky wrote:
> On Sat, Jul 17, 2010 at 16:44, Éric Araujo wrote:
>
>> > The "--help" option appears as a hyperlink leading to
>> > http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help,
>> which is
>> > hardly relevant or useful. [...]
>> >
>>
On 7/18/2010 5:05 PM, Alexander Belopolsky wrote:
On Sun, Jul 18, 2010 at 4:32 PM, Paul Moore wrote:
On 18 July 2010 20:57, Glyph Lefkowitz wrote:
..
This is what branches are for.
When the X.Y release cycle starts, there should be a branch for X.Y. Any
"would be applied" patches can simply
On Sat, Jul 17, 2010 at 16:44, Éric Araujo wrote:
> > The "--help" option appears as a hyperlink leading to
> > http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help,
> which is
> > hardly relevant or useful. [...]
> >
> > -h/:option:`--help`
> >print a short usage message and ex
On 7/18/2010 7:42 PM, Georg Brandl wrote:
That phrasing implies that there is purpose behind letting issues rot.
Believe me that this is not the case.
This seems like a good place to mention that doc issues have become a
bright spot in the last few years, with a couple of days turnaround not
Tim Golden wrote:
That said, it's not clear just how far the stdlib should go to
mimic every switch and option of shell commands...
I don't think it's a matter of mimicking switches just because
they're there.
The operation of "make sure this directory and all its parents
exist" is very commo
On Sun, Jul 18, 2010 at 7:06 PM, Mark Lawrence wrote:
..
> What am I meant to do when as happened earlier today, I see an issue that
> was first raised two years ago, then a year later the OP has asked what if
> anything is happening? Leave it? That's a great advert for Python.
>
> How do I apply
Am 18.07.2010 00:45, schrieb Mark Lawrence:
> On 17/07/2010 22:57, Terry Reedy wrote:
>> On 7/17/2010 8:41 AM, Mark Lawrence wrote:
>>
>>> IIRC Terry Reedy is also interested in moving IDLE forward.
>>
>> Interested, yes. But until either a) I can commit patches, or b) there
>> is someone who will
I was looking at the inspect module and noticed that it's source
starts with "# -*- coding: iso-8859-1 -*-". I have checked and there
are no non-ascii characters in the file. There are several other
modules that still use the cookie:
Lib/ast.py:# -*- coding: utf-8 -*-
Lib/getopt.py:# -*- codin
On 18/07/2010 22:24, Jesse Noller wrote:
On Sun, Jul 18, 2010 at 5:22 PM, Nick Coghlan wrote:
On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence wrote:
I'm extremely offended by your comments. I'll just back off and let the
number of outstanding bugs grow and grow and grow, until such time as
On Sun, Jul 18, 2010 at 6:10 PM, "Martin v. Löwis" 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
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 Li
Hello list, resurrecting a rather old thread from here:
http://mail.python.org/pipermail/python-dev/2009-August/091450.html
I've actually come across a use case where faster zipfile decryption
would be very helpful to me (though one could certainly argue that it's
a frivolous case). I'm writing
On Sun, Jul 18, 2010 at 5:22 PM, Nick Coghlan wrote:
> On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence
> wrote:
>> I'm extremely offended by your comments. I'll just back off and let the
>> number of outstanding bugs grow and grow and grow, until such time as people
>> get fed up with Python an
On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence wrote:
> I'm extremely offended by your comments. I'll just back off and let the
> number of outstanding bugs grow and grow and grow, until such time as people
> get fed up with Python and go to (say) Ruby.
Please don't take it that way - Antoine a
[Removing idle-dev from CC]
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 titl
On Sun, Jul 18, 2010 at 4:32 PM, Paul Moore wrote:
> On 18 July 2010 20:57, Glyph Lefkowitz wrote:
..
>> This is what branches are for.
>> When the X.Y release cycle starts, there should be a branch for X.Y. Any
>> "would be applied" patches can simply be applied to trunk without
>> interrupting
On 18/07/2010 18:46, Alexander Belopolsky wrote:
On Sat, Jul 17, 2010 at 7:45 PM, Mark Lawrence wrote:
On 17/07/2010 22:57, Terry Reedy wrote:
..
I am certainly reluctant to recruit others to help, as I did for #9222,
if there will be no action indefinitely.
This is standard Python behavou
On 18 July 2010 20:57, Glyph Lefkowitz wrote:
>
> On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote:
>
> We already have "posponed" and "remind" resolutions, but these are
> exclusive of "accepted". I think there should be a clear way to mark
> the issue "accepted and would be applied if X
On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote:
> We already have "posponed" and "remind" resolutions, but these are
> exclusive of "accepted". I think there should be a clear way to mark
> the issue "accepted and would be applied if X.Y was out already."
> Chances are one of the resol
On 18/07/2010 15:34, Antoine Pitrou wrote:
Hello Mark,
On Sun, 18 Jul 2010 00:45:09 +0100
Mark Lawrence wrote:
On 17/07/2010 22:57, Terry Reedy wrote:
On 7/17/2010 8:41 AM, Mark Lawrence wrote:
IIRC Terry Reedy is also interested in moving IDLE forward.
Interested, yes. But until either
On 07/18/2010 05:52 PM, Reid Kleckner wrote:
> Usual disclaimer: python-dev is for the development *of* python, not
> *with*. See python-list, etc.
Moving to python-list. Please keep discussion there.
>
> That said, def declares new functions or methods, so you can't put
> arbitrary expressions
On Sat, Jul 17, 2010 at 7:45 PM, Mark Lawrence wrote:
> On 17/07/2010 22:57, Terry Reedy wrote:
..
>> I am certainly reluctant to recruit others to help, as I did for #9222,
>> if there will be no action indefinitely.
>>
>
> This is standard Python behavour. The worst case I've come across is a
>
Antoine,
You've just saved me from composing essentially the same message. I
am top-posting because I have very little to add.
Mark,
I actually reviewed the issues that got closed thanks to your "bumping
them up". That was 30+ issues over the last week or two. Quite
impressive. However, I s
Usual disclaimer: python-dev is for the development *of* python, not
*with*. See python-list, etc.
That said, def declares new functions or methods, so you can't put
arbitrary expressions in there like type(f).__mul__ .
You can usually assign to things like that though, but in this case
you run
Dear python-dev,
In mathematical notation, f*g = z->f(g(z)) and f^n = f*f*f... (n
times). I often run into situations in python where such operators
could result in cleaner code. Eventually, I decided to implement it
myself and see how it worked in practice.
However, my intuitive implementation [
Hello Mark,
On Sun, 18 Jul 2010 00:45:09 +0100
Mark Lawrence wrote:
> On 17/07/2010 22:57, Terry Reedy wrote:
> > On 7/17/2010 8:41 AM, Mark Lawrence wrote:
> >
> >> IIRC Terry Reedy is also interested in moving IDLE forward.
> >
> > Interested, yes. But until either a) I can commit patches, or
On Sun, Jul 18, 2010 at 11:30 AM, Tim Golden wrote:
> On 17/07/2010 11:03 PM, Peng Yu wrote:
>>
>> I don't see that there is a function in the library that mimic the
>> behavior of 'mkdir -p'. If 'makedirs' is used, it will generate an
>> error if the file already exists. There are some functions
On 17/07/2010 14:44, Eli Bendersky wrote:
On Sat, Jul 17, 2010 at 16:26, Michael Foord
mailto:fuzzy...@voidspace.org.uk>> wrote:
On 17/07/2010 14:23, Eli Bendersky wrote:
Hello,
I'm currently working, together with Terry Reedy, on improving
the documentation of the trace mo
On 17/07/2010 11:03 PM, Peng Yu wrote:
I don't see that there is a function in the library that mimic the
behavior of 'mkdir -p'. If 'makedirs' is used, it will generate an
error if the file already exists. There are some functions available
on the website to close the gap. But I'd prefer this is
On 17/07/2010 23:03, Peng Yu wrote:
I don't see that there is a function in the library that mimic the
behavior of 'mkdir -p'. If 'makedirs' is used, it will generate an
error if the file already exists. There are some functions available
on the website to close the gap. But I'd prefer this is in
On 18/07/2010 00:25, ipatrol6...@yahoo.com wrote:
I was reading
http://msdn.microsoft.com/en-us/library/ms684863%28v=VS.85%29.aspx and
http://stackoverflow.com/questions/89228/how-to-call-external-command-in-python#2251026
when I realized that the process creation flags for subprocess.Popen
on
I was reading
http://msdn.microsoft.com/en-us/library/ms684863%28v=VS.85%29.aspx and
http://stackoverflow.com/questions/89228/how-to-call-external-command-in-python#2251026
when I realized that the process creation flags for subprocess.Popen on
Windows are not specified anywhere in the standard
On Sun, Jul 18, 2010 at 3:12 PM, Petre Galan wrote:
> PyNumber_Long is the right interface as it's the right way to do it.
> PyNumber_Index allows me to compute a value as index in slicing, value that
> may be different that the integer behaviour of object. PyNumber_Index is
> serving
> it's purp
41 matches
Mail list logo
