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
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 18/07/2010 00:25, [email protected] 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
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 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 14:44, Eli Bendersky wrote:
On Sat, Jul 17, 2010 at 16:26, Michael Foord
mailto:[email protected]>> 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 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
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
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 [
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
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
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
>
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 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 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 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 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 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
[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 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
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
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
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
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
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
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
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
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
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 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
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 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 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 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 06:40, Alexander Belopolsky <
[email protected]> 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: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
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 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_
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 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
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
41 matches
Mail list logo
