Lalo Martins | 3 Jul 2002 01:17

Re: [development doc updates]

On Tue, Jul 02, 2002 at 06:28:13PM -0400, Fred L. Drake wrote:
> The development version of the documentation has been updated:
> 
>     http://www.python.org/dev/doc/devel/
> 
> Many updates and corrections to the documentation, including docs for the
> new textwrap module.

Re: textwrap.TextWrapper.fix_sentence_endings

} ... Furthermore, since it relies on string.lowercase ... it is specific to
} English-language texts.

Well, actually the convention of separating sentences by two spaces is also
specific to the English language, so I don't see that as a problem.

[]s,
                                               |alo
                                               +----
--
  It doesn't bother me that people say things like
   "you'll never get anywhere with this attitude".
   In a few decades, it will make a good paragraph
      in my biography. You know, for a laugh.
--
http://www.laranja.org/                mailto:lalo <at> laranja.org
         pgp key: http://www.laranja.org/pessoal/pgp

Eu jogo RPG! (I play RPG)         http://www.eujogorpg.com.br/
Python Foundry Guide http://www.sf.net/foundry/python-foundry/
(Continue reading)

Fred L. Drake, Jr. | 3 Jul 2002 07:10
Picon
Favicon
Gravatar

Re: [Doc-SIG] Re: [development doc updates]

Lalo Martins writes:
 > Re: textwrap.TextWrapper.fix_sentence_endings
...
 > Well, actually the convention of separating sentences by two spaces is also
 > specific to the English language, so I don't see that as a problem.

Insidious, isn't it?  I've tried to clarify the matter further in the
documentation; please let me know if you think more is needed.

  -Fred

--

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

Gary Herron | 3 Jul 2002 10:25
Favicon

Re: [development doc updates]

Fred,

Reading the "What's New in Python 2.3" section, I find the following
sentence in "5 Extended Slices":

  Ever since Python 1.4 the slice syntax has supported a third
  ``Stride'' argument, but the builtin sequence types have not
  supported this feature (it was initially included at the behest of
  the developers of the Numerical Python package). This changes with
  Python 2.3.

This is ambiguous.  Exactly *HOW* does it change with Python 2.3?
Does the stride argument go away, or do builtin sequence types now
support the stride argument?  If I'd followed this newsgroup more
carefully, I'd probably know the answer.

The paragraph about PendingDeprecationWarning, which follows the above
quote, probably provides a clue, but it seems out of place, having
nothing to do with slices.

Gary Herron
gherron <at> islandtraining.com

Fred L. Drake, Jr. | 3 Jul 2002 14:04
Picon
Favicon
Gravatar

Re: [development doc updates]

Gary Herron writes:
 > Reading the "What's New in Python 2.3" section, I find the following
 > sentence in "5 Extended Slices":
...
 > This is ambiguous.  Exactly *HOW* does it change with Python 2.3?
 > Does the stride argument go away, or do builtin sequence types now
 > support the stride argument?  If I'd followed this newsgroup more
 > carefully, I'd probably know the answer.

The built-in types now support stride.  Thanks for pointing this
ambiguity out; I've changed the explanation in the document so that
this is clear.

 > The paragraph about PendingDeprecationWarning, which follows the above
 > quote, probably provides a clue, but it seems out of place, having
 > nothing to do with slices.

There was a section heading that was commented out in the document
source; I've uncommented the heading.  More material will be added to
the new section as we have time to complete the material.

Thanks!

  -Fred

--

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

(Continue reading)

Barry A. Warsaw | 8 Jul 2002 22:03

New Persistence SIG created

As recently discussed on meta-sig <at> python.org, we have created a new
SIG focussed on producing a common persistence and transactional
framework for Python programs.  This SIG is called
persistence-sig <at> python.org.

For more information on the SIG, its mission, and deadlines see

    http://www.python.org/sigs/persistence-sig/

To join the mailing list see

    http://mail.python.org/mailman-21/listinfo/persistence-sig

-Barry

Tim Peters | 13 Jul 2002 04:15
Picon

RE: Fw: Behavior of buffer()

[Tim]
> Fredrik pressed for details, but we haven't seen any concrete use cases.
> In the absence of the latter, it's impossible to guess what would be
> backward compatible for MAL's purposes.

[M.-A. Lemburg]
> For my purposes, the strategy buffer slice returns a buffer
> would be more appropriate because it would save the buffer type
> information across the slicing operation... I mean, you don't
> want to get bananas when you slice an apple in real life either ;-)
>
> I use buffers to mean: this is a chunk of binary data. The purpose
> is to recognize this type of data for pickling via xml-rpc,
> soap and other rpc mechanisms etc.

How do you use buffers?  Do you stick to their C API?  Do you use the
Python-level buffer() function?  If the latter, what do you do in Python
code with a buffer object after you get one?  The only use I've seen made of
a buffer object in Python code is as a way to trick the interpreter into
crashing (via recycling the memory the buffer object points to).

And from where do you get a buffer?  There are darned few types in Python
that buffer() accepts as an argument.  Do your extension types implement
tp_as_buffer?  I'm blindly casting for a reason why your appreciation of the
buffer object seems unique.

> Strings don't provide this information (since they can be a mix of
> text and binary data). Buffers are compatible enough with most tools
> working on strings that they represent a good alternative to tag data
> as being binary while not losing all the nice advantages of
(Continue reading)

Guido van Rossum | 17 Jul 2002 22:00
Favicon

Going to OSCON? Give a lightning talk!

If you're going to the O'Reilly Open Source Convention next week,
please consider giving a lightning talk.  We have reserved two
45-minute slots in the Python track on Thursday afternoon for
lightning talks.

A lightning talk is a 5-minute tightly-focused presentation on any
subject you like.  You can discuss your favorite extension, rant, sing
the praises of an under-appreciated developer, plug your product or
company, beg for a job, or even present a Shakespearean-style play
(don't laugh --- we had one of these in 2001).

To submit your idea, fill out this simple web form:

http://conferences.oreillynet.com/cs/os2002/create/e_sess?x-t=os2002_lt.create.form

--Guido van Rossum (home page: http://www.python.org/~guido/)

Jack Jansen | 19 Jul 2002 22:58
Favicon

Added platform-specific directories to sys.path

I've a question that I'd like some feedback on. On MacOSX 
there's a set of directories that are meant especially for 
storing extensions to applications, and there's requests on the 
pythonmac-sig that I add these directories to the Python search 
path. This could easily be done optionally, with a .pth file in 
site-python.

MacOSX has rationalized where preferences, libraries, licenses, 
extensions, etc are stored, and for all of these there's a 
hierarchy of folders. In the case of Python extension modules 
the logical places would be ~/Library/Application Support/Python 
(for user-installed extension modules), /Library/Application 
Support/Python (for machine-wide installed extension modules) 
and /Network/Library/Application Support/Python (for 
workgroup-wide installed modules). The final location, in 
/System, is for factory-installed stuff from Apple, not needed 
just yet for this example:-).

I sympathize with the idea of making things more conform to the 
platform standard, on the other hand I'm a bit reluctant to do 
things differently again from what other Pythons do. But, one of 
the things that is sorely missing from Python is a standard 
place to install per-user extension modules, so this might well 
be the thing that triggers inclusion of such functionality into 
the grand scheme of things (including distutils support, etc).
--
- Jack Jansen        <Jack.Jansen <at> oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -
(Continue reading)

Guido van Rossum | 19 Jul 2002 23:23
Favicon

Re: Added platform-specific directories to sys.path

> I've a question that I'd like some feedback on. On MacOSX 
> there's a set of directories that are meant especially for 
> storing extensions to applications, and there's requests on the 
> pythonmac-sig that I add these directories to the Python search 
> path. This could easily be done optionally, with a .pth file in 
> site-python.
> 
> MacOSX has rationalized where preferences, libraries, licenses, 
> extensions, etc are stored, and for all of these there's a 
> hierarchy of folders. In the case of Python extension modules 
> the logical places would be ~/Library/Application Support/Python 
> (for user-installed extension modules), /Library/Application 
> Support/Python (for machine-wide installed extension modules) 
> and /Network/Library/Application Support/Python (for 
> workgroup-wide installed modules). The final location, in 
> /System, is for factory-installed stuff from Apple, not needed 
> just yet for this example:-).
> 
> I sympathize with the idea of making things more conform to the 
> platform standard, on the other hand I'm a bit reluctant to do 
> things differently again from what other Pythons do. But, one of 
> the things that is sorely missing from Python is a standard 
> place to install per-user extension modules, so this might well 
> be the thing that triggers inclusion of such functionality into 
> the grand scheme of things (including distutils support, etc).

Traditionally, on Unix per-user extensions are done by pointing
PYTHONPATH to your per-user directory (-ies) in your .profile.

On Windows you can do this too, but I bet most people just have a
(Continue reading)

Tim Peters | 21 Jul 2002 23:04
Picon

RE: Added platform-specific directories to sys.path

[Martin v. Loewis]
> If that is the platform convention, I see no problem following
> it. Windows already does things differently from Unix, by using the
> registry to compute sys.path.

FYI, this is mostly a myth.  In normal operation for most people, Python
never gets any info out of the Windows registry.  The Python path in the
registry is consulted only in unusual situations, when the Python library
can't be found under the directory of the executable that called the
sys.path-setting code.  This can happen when, e.g., Python is embedded in
some other app.

The process is quite involved; the comment block at the top of PC/getpathp.c
is a good summary.  When reading it, note that there normally aren't any
"application paths" in the registry; e.g., the PLabs Windows installer
doesn't create any such beast.


Gmane