Re: [Python-Dev] Extended Buffer Interface/Protocol

[Neil Hodgson]

   I have developed a split vector type that implements the buffer protocol at
http://scintilla.sourceforge.net/splitvector-1.0.zip

   It acts as a mutable string implementing most of the sequence
protocol as well as the buffer protocol. splitvector.SplitVector('c')
creates a vector containing 8 bit characters and
splitvector.SplitVector('u') is for Unicode.

   A writable attribute bufferAppearence can be set to 0 (default) to
respond to buffer protocol calls by moving the gap to the end and
returning the address of all of the data. Setting bufferAppearence to
1 responds as a two segment buffer. I haven't found any code that
understands responding with two segments. sre and file.write handle
SplitVector fine when it responds as a single segment:

import re, splitvector
x = splitvector.SplitVector("c")
x[:] = "The life of brian"
r = re.compile("l[a-z]*", re.M)
print x
y = r.search(x)
print y.group(0)
x.bufferAppearence = 1
y = r.search(x)
print y.group(0)

   produces

The life of brian
life
Traceback (most recent call last):
  File "qt.py", line 9, in 
y = r.search(x)
TypeError: expected string or buffer

   It is likely that adding multi-segment ability to sre would
complexify and slow it down. OTOH multi-segment buffers may be
well-suited to scatter/gather I/O calls like writev.

   Neil
___
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] Exceptions for readonly attributes

[Guido van Rossum]

Sounds like something maybe to do in 3.0.

On 3/23/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Re:  www.python.org/sf/1687163
>
> I noticed that RO members raise a TypeError upon an attempted write.  In 
> contrast, we get an AttributeError when writing to a readonly property or to 
> a readonly method (such as those for builtin types).
>
> IMO, the TypeError should really be an AttributeError.  However, changing it 
> makes four of the tests fail.
>
> The question for you guys is whether or not to make the fix.
>
>
> Raymond
> ___
> 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/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.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] Final (final?) update to patch about socket timeout...

[Facundo Batista]

Facundo Batista wrote:

> Tests failed because of this commit *only* in "alpha Tru64 5.1 trunk" 
> buildbot.

Also it fails in "g4 osx.4 trunk". In all the other platforms it works
ok.


> The test that failed is one that does:
>
> sock = socket.create_connection((HOST, PORT), timeout=10)
> self.assertEqual(sock.gettimeout(), 10)

Which is very strange, because this is the third test in
"testTimeoutAttribute" (this method actually tries different ways of
calling the function, no real functionality). 

In other tests, sometimes fail in the second test of the method.

In the test setUp() method, I'm setting the serving socket up, with a
listen(1). 

I can try to to put a listen(5). I can try to reorder the tests. I can
try a lot of things to see why there's a problem here.

But I do not have access to any of both architectures (Alpha and G4).
And I don't want to try everything through commits in the repository
(or should I?).

I do not want to leave these failing tests. I'll fix them, or comment
them out (actually, the tests are very superficial).

What do you do in these cases? How do you deal with failing test cases
in platforms to which you do not have access?

Thanks!

-- 
.   Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/


___
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] RFC - GoogleSOC proposal -cleanupurllib

[Senthil]

Hi All,
I have written a proposal to cleanup urllib as part of Google SoC. I
am attaching the file 'soc1' with this email. Requesting you to go
through the proposal and provide any feedback which I can incorporate
in my submission.

Thanks,
Senthil

--
O.R.Senthil Kumaran
http://phoe6.livejournal.com


soc1
Description: Binary data
___
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] Exceptions for readonly attributes

[Raymond Hettinger]

Re:  www.python.org/sf/1687163

I noticed that RO members raise a TypeError upon an attempted write.  In 
contrast, we get an AttributeError when writing to a readonly property or to a 
readonly method (such as those for builtin types).

IMO, the TypeError should really be an AttributeError.  However, changing it 
makes four of the tests fail.

The question for you guys is whether or not to make the fix.


Raymond
___
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] Proposal: Allow any mapping after ** in calls

[Alexander Belopolsky]

Python allows arbitrary sequences after * in calls, but an expression
following ** must be a (subclass of) dict.  I believe * and ** should
be treated similarly and since f(*UserList(..)) is valid,
f(**UserDict(..)) should be valid as well.

Of course, I can work around this limitation by writing
f(**dict(UserDict(..))), but this is unnatural given that I don't have
to do f(*tuple(UserList(..))).

I have submitted a patch on SF that makes Python accept arbitrary
mappings after **.

See
.
___
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] Final (final?) update to patch about socket timeout...

[Facundo Batista]

Facundo Batista wrote:

> Guido van Rossum wrote:
>
>> Looks good. I forget -- can you check this in yourself? If so, do it!
>> If not, let me know and I'll do it for you. Thanks for doing this!
>
> Done. You're welcome.

Tests failed because of this commit *only* in "alpha Tru64 5.1 trunk" buildbot.

The test that failed is one that does:

sock = socket.create_connection((HOST, PORT), timeout=10)
self.assertEqual(sock.gettimeout(), 10)

And failed with timeout, obviously because it couldn't connect to itself in 10 
seconds.  The "connect to itself" part is implemented in the very same way 
(i.e. copied) that in the rest of the tests, even using the same port and 
everything. 

Note that the previous regression test, in this machine, also failed in 
test_socket, *before* my commit.

My questions are: could this machine be so loaded that it couldn't connect in 
10 seconds? Or something is happening in this machine/architecture?

Shall I try to increment the timeout to 60, in these tests (where actually the 
timeout can be anything) to see what happens?

Regards,

-- 
.   Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/


___
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] Hindsight on Py_UNICODE_WIDE?

[M.-A. Lemburg]

On 2007-03-23 19:18, Jason Orendorff wrote:
> Scheme is adding Unicode support in an upcoming standard:
> (DRAFT) http://www.r6rs.org/document/lib-html/r6rs-lib-Z-H-3.html
> 
> I have two questions for the python-dev team about Python's Unicode
> experiences.  If it's convenient, please take a moment to reply.
> Thanks in advance.
> 
> 1.  In hindsight, what do you think about PEP 261, the Py_UNICODE_WIDE
> build option?  On balance, has this been good, bad, or indifferent?
> What's good/bad about it?

Having narrow and wide builds introduces a level of complexity
that seems unnecessary. Few people ever use non-BMP code points
and the ones who do can easily get away with UTF-16 surrogates.

Most Unixes have chosen to go with UCS4 as storage format, so
you have little choice if you want to take advantage of mapping
directly to wchar on Unix.

Windows has chosen UTF-16 as internal storage format and wchar
is 16-bit on that platform.

You may also want to consider looking at PEP 263:

   http://www.python.org/dev/peps/pep-0263

Source code encoding is a great thing ! You can now write native
Unicode in Python source code.

The only downside is the extra complexity added by the fact
that the tokenizer in Py2 works on 8-bit characters. For this reason
we had to decode the source code to Unicode, then encode it to UTF-8,
pass it to the tokenizer and then decode the UTF-8 literal strings
for Unicode back into Unicode again.

Ideally, the tokenizer in Py3k should be rewritten to work directly on
Unicode.

> 2.  The idea of multiple string representations has come up (that is,
> where all strings are Unicode, but in memory some are 8-bit, some
> 16-bit, and some 32-bit--each string uses the narrowest possible
> representation).  This has been discussed here for Python 3000.  My
> question is:  Is this for real?  How far along is it?  How likely is
> it?

My suggestion for Scheme is not to go down that route. It adds
complexity for little added value and also makes the implementation
slower (due to the frequent conversion from one internal format
to another).

Can't comment on Py3k - I'm out of that loop.

If you want to know more about how Unicode was added to Python 2.x
and how it can be used, I suggest you read the following:

Unicode integration (one of the first PEPs ever written :-):

   http://www.python.org/dev/peps/pep-0100

Unicode in Python:

   http://www.egenix.com/files/python/EuroPython2002-Python-and-Unicode.pdf

Designing Unicode-aware Applications in Python:


http://www.egenix.com/files/python/EPC2006-Developing-Unicode-aware-applications-in-Python.pdf

Hope that helps,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 23 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Final (final?) update to patch about socket timeout...

[Guido van Rossum]

On 3/23/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Looks good. I forget -- can you check this in yourself? If so, do it!
> > If not, let me know and I'll do it for you. Thanks for doing this!
>
> Done. You're welcome.
>
> I'll start now with the patch about the *other* higher level libraries,
> :)

Great -- those should be very easy. If you feel confident you don't
have to get them reviewed before you check in.

-- 
--Guido van Rossum (home page: http://www.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] Final (final?) update to patch about socket timeout...

[Facundo Batista]

Guido van Rossum wrote:

> Looks good. I forget -- can you check this in yourself? If so, do it!
> If not, let me know and I'll do it for you. Thanks for doing this!

Done. You're welcome.

I'll start now with the patch about the *other* higher level libraries,
:)

Regards,

-- 
.   Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/


___
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] Hindsight on Py_UNICODE_WIDE?

[Guido van Rossum]

On 3/23/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> Scheme is adding Unicode support in an upcoming standard:
> (DRAFT) http://www.r6rs.org/document/lib-html/r6rs-lib-Z-H-3.html
>
> I have two questions for the python-dev team about Python's Unicode
> experiences.  If it's convenient, please take a moment to reply.
> Thanks in advance.
>
> 1.  In hindsight, what do you think about PEP 261, the Py_UNICODE_WIDE
> build option?  On balance, has this been good, bad, or indifferent?
> What's good/bad about it?

Don't ask me, I've never thought about it.

> 2.  The idea of multiple string representations has come up (that is,
> where all strings are Unicode, but in memory some are 8-bit, some
> 16-bit, and some 32-bit--each string uses the narrowest possible
> representation).  This has been discussed here for Python 3000.  My
> question is:  Is this for real?  How far along is it?  How likely is
> it?

Unlikely to happen at this point; nobody's stepped up to implement
this, and the implementation effort would be *hge* -- on top of
the already *huuge* effort of unifying str and unicode. (And no, it
would not make that effort any easier.)

-- 
--Guido van Rossum (home page: http://www.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] Final (final?) update to patch about socket timeout...

[Guido van Rossum]

Looks good. I forget -- can you check this in yourself? If so, do it!
If not, let me know and I'll do it for you. Thanks for doing this!

--Guido

On 3/23/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> ...in socket.py and httplib.py, with tests and docs.
>
> The patch is #1676823.
>
> Basically what I did now is:
>
> - Just put a timeout default to None. If None, skip settimeout() call.
>
> - Copy the exceptions behaviour that we have actually in the higher
>   level libraries, to be sure we aren't breaking anything.
>
> - The function is now public, named "create_connection".
>
> Regards,
>
> --
> .   Facundo
> .
> Blog: http://www.taniquetil.com.ar/plog/
> PyAr: http://www.python.org/ar/
>
>
> ___
> 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/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.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

[Python-Dev] Hindsight on Py_UNICODE_WIDE?

[Jason Orendorff]

Scheme is adding Unicode support in an upcoming standard:
(DRAFT) http://www.r6rs.org/document/lib-html/r6rs-lib-Z-H-3.html

I have two questions for the python-dev team about Python's Unicode
experiences.  If it's convenient, please take a moment to reply.
Thanks in advance.

1.  In hindsight, what do you think about PEP 261, the Py_UNICODE_WIDE
build option?  On balance, has this been good, bad, or indifferent?
What's good/bad about it?

2.  The idea of multiple string representations has come up (that is,
where all strings are Unicode, but in memory some are 8-bit, some
16-bit, and some 32-bit--each string uses the narrowest possible
representation).  This has been discussed here for Python 3000.  My
question is:  Is this for real?  How far along is it?  How likely is
it?

Thanks,
Jason
___
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] regexp in Python

[Mike Klaas]

On 3/23/07, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Bartlomiej Wolowiec wrote:
>
> > For some time I'm interested in regular expressions and Finite State 
> > Machine.
> > Recently, I saw that Python uses "Secret Labs' Regular Expression Engine",
> > which very often works too slow. Its pesymistic time complexity is O(2^n),
> > although other solutions, with time complexity O(n*m) ( O(n*m^2), m is the
> > length of the regular expression and n is the length of the text,
> > introduction to problem: http://swtch.com/~rsc/regexp/regexp1.html )
>
> that article almost completely ignores all the subtle capturing and left-
> to-right semantics that a perl-style engine requires, though.  trust me,
> this is a much larger can of worms than you might expect.  but if you're
> ready to open it, feel free to hack away.
>
> > major part of regular expressions
>
> the contrived example you used has nothing whatsoever to do with
> "major part of regular expressions" as seen in the wild, though.  I'd
> be much more interested in optimizations that focuses on patterns
> you've found in real code.

A fruitful direction that is not as ambitious as re-writing the entire
engine would be to add "independent group" assertions to python's RE
syntax [ (?> ... ) in perl].  They are rather handy for optimizing the
malperforming cases alluded to here (which rarely occur as the OP
posted, but tend to crop up in less malignant forms).

-Mike
___
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] Final (final?) update to patch about socket timeout...

[Facundo Batista]

...in socket.py and httplib.py, with tests and docs.

The patch is #1676823.

Basically what I did now is:

- Just put a timeout default to None. If None, skip settimeout() call.

- Copy the exceptions behaviour that we have actually in the higher
  level libraries, to be sure we aren't breaking anything.

- The function is now public, named "create_connection".

Regards,

-- 
.   Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/


___
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-checkins] r54539 - in python/trunk: Lib/string.py Misc/NEWS Objects/typeobject.c

[Jim Jewett]

(Please note that most replies should trim at least one list from the Cc)

On 3/23/07, guido.van.rossum <[EMAIL PROTECTED]> wrote:
> Note: without the change to string.py, lots of spurious warnings happen.
> What's going on there?

I assume it was a defensive measure for subclasses of both Template
and X, where X has its own metaclass (which might have an __init__
that shouldn't be ignored).

This is where cooperative classes get ugly.  You could argue that the
"correct" code is to not bother making the super call if it would go
all the way to object (or even type), but there isn't a good way to
spell that.

> +# A super call makes no sense since type() doesn't define __init__().
> +# (Or does it? And should type.__init__() accept three args?)
> +# super(_TemplateMetaclass, cls).__init__(name, bases, dct)

In this particular case, you could define a type.__init__ that did
nothing.  (If the signature were wrong, type.__new__ would have
already caught it.  If __new__ and __init__ are seeing something
different, then the change was probably intentional.)

The problem isn't really limited to type.__init__ though.  You'll
sometimes see similar patterns for __del__, close, save, etc.  The
main difference is that they have to either catch an error or check
first, since object doesn't have an implementation of those methods.
object.__init__ doesn't really do anything either, except check for
errors.  Getting rid of it should have the same effect as complaining
about parameters.

The ideal solution (discussion of which probably ought to stay on
python-ideas) might be to replace object.__init__ with some sort of
PlaceHolder object  that raises an error *unless* called through a
cooperative super.  This PlaceHolder would also be useful for
AbstractBaseClasses/Interfaces.  PlaceHolder still wouldn't deal with
the original concern of verifying that all arguments had already been
stripped and used; but the ABCs might be able to.

-jJ

> Modified: python/trunk/Lib/string.py
> ==
> --- python/trunk/Lib/string.py  (original)
> +++ python/trunk/Lib/string.py  Fri Mar 23 05:58:42 2007
> @@ -108,7 +108,9 @@
>  """
>
>  def __init__(cls, name, bases, dct):
> -super(_TemplateMetaclass, cls).__init__(name, bases, dct)
> +# A super call makes no sense since type() doesn't define __init__().
> +# (Or does it? And should type.__init__() accept three args?)
> +# super(_TemplateMetaclass, cls).__init__(name, bases, dct)
>  if 'pattern' in dct:
>  pattern = cls.pattern
>  else:
___
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] deprecate commands.getstatus()

[Titus Brown]

On Fri, Mar 23, 2007 at 10:30:37AM -0600, Steven Bethard wrote:
-> On 3/23/07, Hrvoje Nik??i?? <[EMAIL PROTECTED]> wrote:
-> > On Thu, 2007-03-22 at 13:38 -0700, Guido van Rossum wrote:
-> > > Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
-> > > the popen2 module at all, and do everything via the subprocess module.
-> > > I wonder if we should even get rid of os.system(); then there should
-> > > be a subprocess.system() instead. And do we even need os.fork(),
-> > > os.exec*(), os.spawn*()?
-> >
-> > Please don't remove os.fork and os.exec*.  Some people need to fine-tune
-> > process creation and don't need portability to non-Unix OS'es.  For
-> > them, the functions that call the underlying system API and little or
-> > nothing else are a god-send.
-> 
-> Right, but if you're really using only Posix, you can simply use
-> ``posix.fork`` and ``posix.exec*`` and then you're even being explicit
-> about the fact.

Yes, but:

http://docs.python.org/lib/module-posix.html

"""Do not import this module directly."""

Unless people want me to try to extract something coherent from the
recent discussion, I'm going to avoid doing anything with os.*
functions.  That can be done separately from the contemplated subprocess
patch, anyway.

The whole thread is here:

http://www.gossamer-threads.com/lists/engine?post=553519;list=python

and I will finish up a patch to do this:

http://www.gossamer-threads.com/lists/python/dev/555743#555743

(add get_*output* functions to subprocess, modify docs appropriately,
add 'require_success', and put in a docs deprecation for
popen2/commands).

I'll post again when I have a patch ready so there's something concrete
to complain about ;).

thanks,
--titus
___
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] deprecate commands.getstatus()

[Steven Bethard]

On 3/23/07, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-22 at 13:38 -0700, Guido van Rossum wrote:
> > Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
> > the popen2 module at all, and do everything via the subprocess module.
> > I wonder if we should even get rid of os.system(); then there should
> > be a subprocess.system() instead. And do we even need os.fork(),
> > os.exec*(), os.spawn*()?
>
> Please don't remove os.fork and os.exec*.  Some people need to fine-tune
> process creation and don't need portability to non-Unix OS'es.  For
> them, the functions that call the underlying system API and little or
> nothing else are a god-send.

Right, but if you're really using only Posix, you can simply use
``posix.fork`` and ``posix.exec*`` and then you're even being explicit
about the fact.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] deprecate commands.getstatus()

[Hrvoje Nikšić]

On Thu, 2007-03-22 at 13:38 -0700, Guido van Rossum wrote:
> Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
> the popen2 module at all, and do everything via the subprocess module.
> I wonder if we should even get rid of os.system(); then there should
> be a subprocess.system() instead. And do we even need os.fork(),
> os.exec*(), os.spawn*()?

Please don't remove os.fork and os.exec*.  Some people need to fine-tune
process creation and don't need portability to non-Unix OS'es.  For
them, the functions that call the underlying system API and little or
nothing else are a god-send.


___
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] minidom and DOM level 2

[Jason Orendorff]

On 3/23/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jason Orendorff schrieb:
> > The lib ref claims that minidom supports DOM Level 1.  Does anyone
> > know what parts of Level 2 are not implemented?  I wasn't able to find
> > anything offhand.
>
> I now looked at it closely, and the only thing missing from DOM Level
> 2 Core (that I could find) is the EntityReference interface, and
> Document::createEntityReference. I'm not sure what semantics goes with it.

OK, I think this is worthwhile then.  :)  I'll read the spec and submit
a patch.

-j
___
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] regexp in Python

[Fredrik Lundh]

Bartlomiej Wolowiec wrote:

> For some time I'm interested in regular expressions and Finite State Machine.
> Recently, I saw that Python uses "Secret Labs' Regular Expression Engine",
> which very often works too slow. Its pesymistic time complexity is O(2^n),
> although other solutions, with time complexity O(n*m) ( O(n*m^2), m is the
> length of the regular expression and n is the length of the text,
> introduction to problem: http://swtch.com/~rsc/regexp/regexp1.html )

that article almost completely ignores all the subtle capturing and left-
to-right semantics that a perl-style engine requires, though.  trust me,
this is a much larger can of worms than you might expect.  but if you're
ready to open it, feel free to hack away.

> major part of regular expressions

the contrived example you used has nothing whatsoever to do with
"major part of regular expressions" as seen in the wild, though.  I'd
be much more interested in optimizations that focuses on patterns
you've found in real code.

 



___
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] minidom and DOM level 2

[Martin v. Löwis]

Jason Orendorff schrieb:
> The lib ref claims that minidom supports DOM Level 1.  Does anyone
> know what parts of Level 2 are not implemented?  I wasn't able to find
> anything offhand.  

I now looked at it closely, and the only thing missing from DOM Level
2 Core (that I could find) is the EntityReference interface, and
Document::createEntityReference. I'm not sure what semantics goes with it.

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