Am 09.07.2010 00:01, schrieb Fred Drake:
> On Thu, Jul 8, 2010 at 5:42 PM, Alexander Belopolsky
> wrote:
>> I am against mark-up in doc-strings, but this problem can be easily
>> solved by placing a magic character at __doc__[0] to indicate that the
>> rest is (mini)reST.
Ugh. :)
> Or __docform
On Fri, Jul 09, 2010 at 02:23:40PM +1000, Steven D'Aprano wrote:
> > Is this is valid ftp url?
> >
> > # file://ftp.example.com/blah.txt (an ftp URL)
> >
> > My answer is no. When we have the scheme specifically mentioned as
> > file:// it is no point in considering it as ftp url (which should
> >
On Fri, 9 Jul 2010 01:52:32 pm Senthil Kumaran wrote:
> Strictly not a Python question, but I wanted to know from the
> experience of others in this list.
>
> Is this is valid ftp url?
>
> # file://ftp.example.com/blah.txt (an ftp URL)
>
> My answer is no. When we have the scheme specifically menti
Strictly not a Python question, but I wanted to know from the
experience of others in this list.
Is this is valid ftp url?
# file://ftp.example.com/blah.txt (an ftp URL)
My answer is no. When we have the scheme specifically mentioned as
file:// it is no point in considering it as ftp url (which
Steve Holden writes:
> That is _so_ Python 2 ;-)
High praise!
___
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.co
On Thu, Jul 8, 2010 at 5:46 PM, Nick Coghlan wrote:
..
> So include something along the lines of "globals()[obj.__name__] =
> obj" in the name hacking loop to make the test classes more
> discoverable? Good idea.
>
As often happens, a good idea turns quite ugly when facing real world
realities.
Nick Coghlan wrote:
On Fri, Jul 9, 2010 at 7:54 AM, MRAB wrote:
You should be able to replace:
import re
with:
import regex as re
and still have everything work the same, ie it's backwards compatible
with re.
That's not what I'm asking. I'm asking what happens if you take an
existin
Hi,
I'm trying to fix Python to support undecodable bytes in the Python path since
some months ago. My first try was really huge and sometimes ugly. When it was
possible, I extracted some short and simple patches and applied them to py3k
(sometimes with an issue, sometimes directly in the svn).
Fred Drake wrote:
> On Thu, Jul 8, 2010 at 5:42 PM, Alexander Belopolsky
> wrote:
>> I am against mark-up in doc-strings, but this problem can be easily
>> solved by placing a magic character at __doc__[0] to indicate that the
>> rest is (mini)reST.
>
> Or __docformat__ can be set appropriately.
On Fri, Jul 9, 2010 at 7:54 AM, MRAB wrote:
> You should be able to replace:
>
> import re
>
> with:
>
> import regex as re
>
> and still have everything work the same, ie it's backwards compatible
> with re.
That's not what I'm asking. I'm asking what happens if you take an
existing Python
On Thu, Jul 8, 2010 at 5:42 PM, Alexander Belopolsky
wrote:
> I am against mark-up in doc-strings, but this problem can be easily
> solved by placing a magic character at __doc__[0] to indicate that the
> rest is (mini)reST.
Or __docformat__ can be set appropriately. See:
http://www.python
Nick Coghlan wrote:
On Fri, Jul 9, 2010 at 5:52 AM, MRAB wrote:
Hi all,
I re-implemented the re module, adding new features and speed
improvements. It's available at:
http://pypi.python.org/pypi/regex
under the name "regex" so that it can be tried alongside "re".
I'd be interested in any
On Thu, 08 Jul 2010 20:52:44 +0100
MRAB wrote:
>
> I'd be interested in any comments or feedback. How does it compare with
> "re" in terms of speed on real-world data? The benchmarks suggest it
> should be faster, or at worst comparable.
Can you publish these benchmarks somewhere?
(or send them
2010/7/8 MRAB :
> Hi all,
>
> I re-implemented the re module, adding new features and speed
> improvements. It's available at:
>
> http://pypi.python.org/pypi/regex
>
> under the name "regex" so that it can be tried alongside "re".
>
> I'd be interested in any comments or feedback. How does it c
On Fri, Jul 9, 2010 at 5:24 AM, Alexander Belopolsky
wrote:
> Yes, this is definitely an improvement over my current datetime patch
> [1]_, but it still requires a custom test_main() and does not make the
> test cases discoverable by alternative unittest runners. I think that
> can be fixed by in
On Thu, Jul 8, 2010 at 5:21 PM, Georg Brandl wrote:
..
> Problem is, in the case of help() we have no way of knowing whether the
> given __doc__ string is supposed to be (mini)reST.
I am against mark-up in doc-strings, but this problem can be easily
solved by placing a magic character at __doc__[
On Thu, Jul 8, 2010 at 5:21 PM, Georg Brandl wrote:
> Problem is, in the case of help() we have no way of knowing whether the
> given __doc__ string is supposed to be (mini)reST. Of course, reverting
> to showing the plain content on parsing errors is one possibility, but
> I can still imagine in
On Fri, Jul 9, 2010 at 5:52 AM, MRAB wrote:
> Hi all,
>
> I re-implemented the re module, adding new features and speed
> improvements. It's available at:
>
> http://pypi.python.org/pypi/regex
>
> under the name "regex" so that it can be tried alongside "re".
>
> I'd be interested in any commen
Am 08.07.2010 17:44, schrieb Martin Geisler:
> Steve Holden writes:
>
>> Martin Geisler wrote:
>>> "Stephen J. Turnbull" writes:
>>>
Just ask Martin, there are too many possibilities here to worry
about. If maybe we want it, and he is willing to contribute the
parts he wrote to P
On Thu, Jul 8, 2010 at 3:29 PM, Antoine Pitrou wrote:
> On Fri, 9 Jul 2010 00:59:02 +1000
> Nick Coghlan wrote:
..
> I don't really like the proliferation of module test helpers, it only
> makes things confusing and forces you to switch between more files in
> your editor. By contrast, the subcla
Hi all,
I re-implemented the re module, adding new features and speed
improvements. It's available at:
http://pypi.python.org/pypi/regex
under the name "regex" so that it can be tried alongside "re".
I'd be interested in any comments or feedback. How does it compare with
"re" in terms of s
On Fri, 9 Jul 2010 00:59:02 +1000
Nick Coghlan wrote:
> py_module_tests = support.import_fresh_module('moduletester',
> fresh=['modulename'], blocked=['_modulename'])
> c_module_tests = support.import_fresh_module('moduletester',
> fresh=['modulename', '_modulename'])
I don't really like the prol
On Thu, Jul 8, 2010 at 10:59 AM, Nick Coghlan wrote:
..
> I realised during the day that my suggested approach was more
> complicated than is actually necessary - once the existing tests have
> been moved to a separate module, *that test module* can itself be
> imported twice, once with the python
On Thu, Jul 8, 2010 at 07:59, Nick Coghlan wrote:
> On Thu, Jul 8, 2010 at 9:13 AM, Benjamin Peterson wrote:
>> 2010/7/7 Nick Coghlan :
>>> On Thu, Jul 8, 2010 at 7:56 AM, Michael Foord
>>> wrote:
Using a class decorator to duplicate each _test_ into two test_* methods
sounds like a
On Wed, Jul 7, 2010 at 15:17, Terry Reedy wrote:
> On 7/7/2010 3:32 PM, Brett Cannon wrote:
>
>> That's the idea. We already have contributors from the various VMs who
>> has commit privileges, but they all work in their own repos for
>> convenience. My hope is that if we break the stdlib out into
[Sending this to Python-Dev, as it might very well be of interest as the sprints
are focused on Python "core" tasks]
The PSF is happy to open our first call for applications for sprint funding!
Have you ever had a group of people together to hack towards a common goal?
You've hosted a sprint!
Ha
Steve Holden writes:
> Martin Geisler wrote:
>> "Stephen J. Turnbull" writes:
>>
>>> Just ask Martin, there are too many possibilities here to worry
>>> about. If maybe we want it, and he is willing to contribute the
>>> parts he wrote to Python under Python's license, then we can worry
>>> abo
On Fri, Jul 9, 2010 at 12:59 AM, Nick Coghlan wrote:
> for obj in module.itervalues():
> if isinstance(obj, unittest,TestCase):
Hmm, isn't there a never-quite-made-it-into-the-Zen line about "syntax
shall not look like grit on Tim's monitor"? (s/,/./ in that second
line)
Cheers,
Nick.
On Thu, Jul 8, 2010 at 9:13 AM, Benjamin Peterson wrote:
> 2010/7/7 Nick Coghlan :
>> On Thu, Jul 8, 2010 at 7:56 AM, Michael Foord
>> wrote:
>>> Using a class decorator to duplicate each _test_ into two test_* methods
>>> sounds like a good approach.
>>
>> Note that parameterised methods have
[Antoine Pitrou]
> I don't think 2.7 should get any change at all here. Only 3.2 should be
> modified. As Tim said, difflib works ok for its intended use (regular
> text diffs).
That was the use case that drove the implementation, but it's going
too far to say that was the only "intended" case. I
Martin Geisler wrote:
> "Stephen J. Turnbull" writes:
>
>> Benjamin Peterson writes:
>> > 2010/7/7 Stephen J. Turnbull :
>> > > Antoine Pitrou writes:
>> > >
>> > > > > http://selenic.com/hg/file/tip/mercurial/minirst.py
>> > > >
>> > > > Given that Mercurial is GPL, this is probably o
On Wed, 07 Jul 2010 21:45:30 -0400
Terry Reedy wrote:
>
> > Except that ctypes doesn't help provide C extensions at all. It only
> > helps provide wrappers around existing C libraries, which is quite a
> > different thing.
> > Which, in the end, makes the original suggestion meaningless.
>
> To
On Wed, 07 Jul 2010 21:04:17 -0400
Terry Reedy wrote:
>
> In other words, I see three options for 2.7.1+:
[...]
I don't think 2.7 should get any change at all here. Only 3.2 should be
modified. As Tim said, difflib works ok for its intended use (regular
text diffs). Making it work for other uses
"Stephen J. Turnbull" writes:
> Benjamin Peterson writes:
> > 2010/7/7 Stephen J. Turnbull :
> > > Antoine Pitrou writes:
> > >
> > > > > http://selenic.com/hg/file/tip/mercurial/minirst.py
> > > >
> > > > Given that Mercurial is GPL, this is probably of no use to us,
> > > > unfortu
Am 07.07.2010 23:04, schrieb Georg Brandl:
> Am 07.07.2010 20:40, schrieb Barry Warsaw:
>
>> Getting back to this after the US holiday. Thanks for running these numbers
>> Scott. I've opened a bug in the Python tracker and attached my latest patch:
>>
>> http://bugs.python.org/issue9193
>>
>>
35 matches
Mail list logo
