Re: [Python-Dev] Ph.D. dissertation ideas?

[Dennis Allison]

Brett,

Where are you doing your Phd and who will be your likely supervisor? 
It does make a difference.

Your dissertation idea list seems to me to focus on implementation
projects and not on research.  Usually a dissertation proceeds from a
hypothesis leading to an experiment, some measurements, and conclusions.  
Many universities tacitly expect a theorem and associated proof. The goal
of dissertation research is a completed approved dissertation, not some
intergalactic all encompassing contribution to human knowledge.  
Dissertation research should, IMHO, focus on a small, manageable problem.

Frequently, universities have a large cooperative project involving many 
graduate students, each of whom research a small, well defined topic areas 
related to the larger project.   Is this the case for your dissertation?

What are your interests?  Are you interested in language structure, 
language implementation, the formal interface between languages and 
applications, or what.   

Like most folks who lurk on this list, I have my list of things I'd like 
to see someone research.  Tell us a bit more and I am sure you'll get lots 
of us to share.

-d

On Thu, 12 Jan 2006, Brett Cannon wrote:

> It is time once again in my educational career to come to python-dev
> for help for major project ideas.  This time, though, it is for my
> Ph.D. dissertation (and thus can have larger scope than my masters
> thesis) but there are funding restrictions (and thus only certain
> areas I have possible funding for).
> 
> First off, there are two areas where I have possible funding: XML
> integration into programming languages and game scripting support (I
> have a third, AOP for anything, but  I don't think AOP is a good match
> for Python and thus not considering it for Python work).  The XML
> integration I have no direct ideas since I don't use XML.  There is
> the possibility of doing something like the LINQ project
> (http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp)
> or something, but I don't know how useful that could be.  It would
> have to be just as generic, though, as the LINQ project in terms of
> working with intefaces to be Pythonic so it might turn out to be more
> about language support for querying data.
> 
> For the game scripting, trying out the active objects for Python is a
> possibility (or something else that would help with concurrency). 
> Since that could allow for agent objects to be more concurrent it can
> be argued that it would help with game scripting.  I don't have any
> other ideas for the area of game scripting support.
> 
> Now I am not locked down to these areas, but they are what I have
> possible grant money for.  If through some miracle someone out there
> wants to fund my Ph.D. and wants something else worked on for Python,
> don't be shy.  =)  Unfortunately I don't think the PSF is up for
> funding my Ph.D., else I would say I would work on whatever python-dev
> decided they wanted to worked on that could be done as a dissertation.
> 
> Anyway, any ideas are appreciated.  There is no rush on this, either. 
> Just getting this out there now while I am tentatively exploring
> possible topics.
> 
> -Brett
> ___
> 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/allison%40sumeru.stanford.edu
> 

-- 

___
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] r42015 - peps/trunk

[David Goodger]

> [David Goodger]
>> An alternative is to use svn:externals to link to a specific
>> revision (via the -r option);

[Tim Peters]
> Yes. please.

Done.

-- 
David Goodger 



signature.asc
Description: OpenPGP digital signature
___
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] DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15

[Tony Meyer]

=
Announcements
=

-
Reminder: plain text documentation fixes are accepted
-

Want to help out with the Python documentation? Don't know LaTeX? No
problem! Plain text or ReST fixes are also welcome. You won't be able
to produce a diff file like with a normal patch, but comments that
explain how to fix the docs are just as good. A form like "in section
XXX right before the paragraph starting with YYY, the documentation
should say ZZZ" will make it easy for the doc maintainers to apply
your fix.

Contributing thread:

 - `c.l.p post on docs
`__

[SJB]


New-style exceptions patch requesting review


With `PEP 352`_ ready_ for Guido's pronouncement, Michael Hudson has
asked for a few more developers to review his patch_ to make all
exceptions new-style. It should be basically ready, but it would be
nice to have a few eyes for sanity checks, documentation, and
compilations on the various platforms.

.. _PEP 352: http://www.python.org/peps/pep-0352.html
.. _ready: 
http://www.python.org/dev/summary/2005-10-16_2005-10-31.html#required-superclass-for-exceptions
.. _patch: http://bugs.python.org/1104669

Contributing threads:

 - `New-style exceptions patch (was Re: PEP 8 updates/clarifications)
`__
 - `New-style exceptions patch
`__

[SJB]


Debugging lib available from ActiveState


Trent Mick confirmed that ActiveState do distribute a separate
distribution of debug DLLs for each Python release.  These can be
found by filling in the version number in the URL
ftp://ftp.activestate.com/ActivePython/etc/ActivePython--win32-ix86-debug.zip

Contributing thread:

 - `Plea to distribute debugging lib
`__

[TAM]

=
Summaries
=

---
Updating the Python style guide
---

Ian Bicking kicked off a lengthy discussion about updating various
aspects of `PEP 8`_ (the Python code style guide), which resulted in a
substantial revision of the PEP.

PEP 8 stated that if a module defines a single exception raised for
all sorts of conditions, it is generally called "error" or "Error". 
Ian noted that other than some outlying cases (e.g. os.error,
socket.error), CapWords are always used.  He also wondered if
exceptions should have names that are relatively unique, or simply
unique within their namespace.  Finally, he requested a position be
taken on acronyms (e.g. HHTPRedirect or HttpRedirect).

Barry Warsaw pointed out that since exceptions are now classes, the
rules for naming classes should really apply; his preference is
CapWordsEndingInError rather than Error or error.  He also suggested
that acronym letters should be capitalised.  There was mostly
consensus on this, although some prefer shorter exception class names.

Guido wondered whether the function/method naming convention
(lower_case, mixedCase, or CapWords) was so controversial that the PEP
should not make a recommendation other than of consistency.  In the
end, however, the status quo (lower_case except for consistency
reasons) won out.  He was definite about module, package, and class
names, however, which should be all-lowercase without underscores
(modules/packages), or CapWords (class names).  (He noted that
standard library modules such as StringIO.py and UserDict.py that
break this rule should be changed).

PEP 8 recommended appending an underscore rather than corrupted
spelling when a name conflicts with a reserved word e.g. class_ rather
than klass).  Ian suggested that a specific recommendation for the
class argument to classmethods be made; out of cls, klass and class_
he preferred cls.  He further suggested that, as self is not used
outside of the first argument of instance methods, whatever spelling
of the class argument is used should not be used elsewhere (e.g. cls
for the class argument, and class_ elsewhere).  This was generally
accepted.

A further suggestion from Barry's `Mailman style guide`_ was also
made, that from-imports should follow non-from imports, and dotted
imports should follow non-dotted imports.  Non-dotted imports should
be grouped by increasing length, while dotted imports should be
grouped roughly alphabetically.  However, this was felt to be too
prescriptive; users should follow their own aesthetic taste.

Various other small modifications and improvements were suggested and
made, such as::

  * PEP 8 stated that modules designed for use via "from M import *"
should prefix their globals, internal 

Re: [Python-Dev] pystate.c changes for Python 2.4.2

[Aahz]

On Thu, Jan 12, 2006, Gabriel Becedillas wrote:
>
> If I add this code at the end of PyThreadState_Delete:
> 
> if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate)
>   PyThread_delete_key_value(autoTLSkey);
> 
> then everything works fine.
> Could you please confirm if this is a bug ?

Regardless of whether you get any other responses, please go ahead and
file a SourceForge bug report so that we don't lose track of this.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
___
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] Include ctypes into core Python?

[Thomas Heller]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> Thomas Heller wrote:
>> Sounds good, although it should be noted that ctypes is a package now,
>> with a ctypes.wrap subpackage (contains the code generator), a
>> ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X),
>> and ctypes.test subpackage whcih contains several test modules.  Plus
>> the _ctypes.(dll|so) extension module.
>
> Ok. The installer should then combine them all into a feature.
>
> Still, the admin could disable all of this just by removing _ctypes.dll,
> right?

Right.

Thomas

___
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] pystate.c changes for Python 2.4.2

[Gabriel Becedillas]

Hi,
At the company I work for, we've embedded Python in C++ application we 
develop. Since our upgrade to Python 2.4.2 from 2.4.1 we started hitting 
Py_FatalError("Invalid thread state for this thread") when using debug 
builds.
We use both multiple interpreters and thread states.

I think the problem is that PyThreadState_Delete (which is used when I
destroy thread states and interpreters) is not making the same clean up
that PyThreadState_DeleteCurrent is doing (which is used when we create 
threads from python code). If a thread id is reused (obviously not 
between two running threads), and the previous thread used 
PyThreadState_Delete instead of PyThreadState_DeleteCurrent, then an old 
and invalid value for autoTLSkey is still stored, and that is
triggering the Py_FatalError when a call to PyThreadState_Swap is made.
If I add this code at the end of PyThreadState_Delete:

if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate)
PyThread_delete_key_value(autoTLSkey);

then everything works fine.
Could you please confirm if this is a bug ?
Thanks a lot and have a nice day.
___
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] Ph.D. dissertation ideas?

[Steve Holden]

Brett Cannon wrote:
> On 1/12/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> 
>>Brett,
>>
>>How about building a system that compiles a Python program (possibly
>>annotated) to an AJAX program?  That is, it analyzes the program to
>>determine what's appropriate and possible for client-side and
>>server-side, figures out the optimal network API (reduce latency,
>>reduce calls, reduce data transfer, increase responsiveness),
>>generates server-side Jython to run in Tomcat (or Python for
>>mod_python), and client-side XHTML, CSS, and Javascript to implement
>>the browser-based portion of the application.  Oddities of browser
>>implementations and Javascript VMs would be contained in the compiler
>>and automatically pushed into the generated code.
>>
>>This would be a tremendously useful advance in building distributed
>>systems that work with the Web.  The current approach to AJAX is a bit
>>like carpentry with old hand tools.  You'd probably also push Python
>>to higher levels of language-ness.
>>
> 
> 
> Hmm.  It's an idea.  I also thought of Python -> JavaScript compiler
> since JavaScript is not fun and getting to test using Python might be
> cool.  But not sure how useful that would be.  Plus I bet someone has
> does this with Java or something.
> 
If you can persuade your supervisor to be interested in educational 
games, a Python learning system might be an interesting project with 
lots of scope for user modelling and goal-directed behaviour.

There's been some work done on bomb-proofing the interpreter to offer a 
"try-python" type site, but nobody seems to have thought about how to 
engage a neophyte with an specific teaching strategy (possibly based on 
personality analysis) and then present problems to verify comprehension 
and offer appropriate feedback.

That would be a terrific game!

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

___
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] DRAFT: python-dev Summary for 2005-12-16 through 2005-12-31

[Tony Meyer]

Here's the second December summary.  As always, if anyone can spare
some time to take a look over it and send any
comments/suggestions/corrections/additions to me or Steve that would
be great.  I'm not all that confident about the "default comparisons"
thread, so particular attention to that would be great.  Thanks!

=
Announcements
=


QOTF: Quote of the Fortnight


Python-dev is in love with Python, though sometimes too much, Fredrik
Lundh contends:

...in reality, some things are carefully thought out and craftily
implemented, some things are engineering tradeoffs made at a certain
time, and some things are just accidents -- but python-dev will
happily defend the current solution with the same energy, no matter
what it is.

Contributing thread:

- `a quit that actually quits
`__

[SJB]

---
Reminder: plain text documentation patches are accepted
---

Want to help out with the Python documentation? Don't know LaTeX? No
problem! Plain text or ReST fixes are also welcome. You won't be able
to produce a diff file like with a normal patch, but comments that
explain how to fix the docs are just as good. A form like "in section
XXX right before the paragraph starting with YYY, the documentation
should say ZZZ" will make it easy for the doc maintainers to apply
your fix.

Contributing thread:

 - `LaTeX and Python doc contributions
`__

[SJB]

---
PyPy Sprint: Palma de Mallorca (Spain) 23rd - 29th January 2006
---

The next PyPy_ sprint is scheduled to take place from the 23rd to the
29th of January 2006 in Palma De Mallorca, Balearic Isles, Spain. 
There will be newcomer-friendly introductions and the focus will
mainly be on current JIT work, garbage collection, alternative
threading models, logic programming and on improving the interface
with external functions.

 .. _PyPy: http://codespeak.net/pypy

Contributing thread:

 - `Next PyPy Sprint: Palma de Mallorca (Spain) 23rd - 29th January
2006 `__

[TAM]

--
SHA-224, -256, -384 and -512 support in Python 2.5
--

Ronald L. Rivest asked about the cryptographic hash function support
in Python, now that md5 and sha1 are broken in terms of
collision-resistance.  The new-in-Python-2.5 hashlib module was
pointed out (and somewhat belatedly added to the NEWS file), which
includes new implementations for SHA-224, -256, -384 and -512 (these,
including tests, are already in SVN).

Gregory P. Smith noted that although the code isn't currently
available for earlier versions of Python, he does plan to release a
standalone package for Python 2.3 and Python 2.4, when time permits.

Contributing thread:

 - `hashlib - faster md5/sha, adds sha256/512 support
`__

[TAM]

=
Summaries
=

---
Improving the documentation process
---

Fredrik Lundh asked about automatically updating the development docs,
so that users wouldn't be required to have a latex toolchain installed
to get an HTML version of the current docs. This spawned a long
discussion about using something other than LaTeX (e.g. microformats_
or ReST_) for markup. Though HTML has the advantage that many Python
users are already familiar with it, a number of people voiced concerns
about the ease of reading and writing it.  ReST is generally easy to
read and write, but some people suggested that for complicated
structured text (like Python function and class definitions) it was no
better than LaTeX. Fredrik Lundh presented some example code
side-by-side_ and argued that using HTML with something like
PythonDoc_ could better represent the documentation's intent. He also
produced an initial conversion_ of the Python docs to this format.

Fredrik also pointed out that currently the doc patch submission
procedure is rather tedious, and listed_ the rather large number of
steps required for end-users and developers to get their documentation
fixes added to the current Python docs. He claimed that a simple wiki,
discussion board, or "user edit" mechanism like that of roundup_,
combined with automated updates of the documentation from the Python
SVN trunk, could reduce this procedure to two or three simple steps.
As a partial effort towards this goal, Trent Mick started posting
`daily builds`_ of the Python HTML. This prompted Neal Norwitz to set
up the docs server in a simil

[Python-Dev] Unicode print/stdoutput exceptions are not nice

[Robert Kiendl]

<[EMAIL PROTECTED]>
Martin v. Löwis schrieb:

 > Robert wrote:
 > > is in a PythonWin Interactive session - ok results for cyrillic chars
 > > (tolerant mbcs/utf-8 encoding!).
 > > But if I do this on Win console (as you probably mean), I get also
 > > encoding Errors - no matter if chcp1251, because cyrillic chars raise
 > > the encoding errors also.
 >
 > If you do "chcp 1251" (not "chcp1251") in the console, and then
 > run python.exe in the same console, what is the value of
 > sys.stdout.encoding?

correctly: 'cp1252' in my case; cyrillic-chars break "print"   (on PC 
linux 2.2 tty py24 sys.stdout.encoding is None (?); only 
locale.getdef... useful? )

I live with this in site(customize):

import codecs
_stdout=sys.stdout
if sys.platform=='win32' and not 
sys.modules.has_key('pywin.framework.startup'):
 _stdoutenc=getattr(_stdout,'encoding',None) or sys.getdefaultencoding()
 try: codecs.lookup(_stdoutenc)
 except LookupError: _stdoutenc=sys.getdefaultencoding()
 class StdOut:
 def write(self,s): 
_stdout.write(s.encode(_stdoutenc,'backslashreplace'))
 sys.stdout=StdOut()
elif sys.platform.startswith('linux'):
 import locale
 _stdoutenc=locale.getdefaultlocale()[1]
 try: codecs.lookup(_stdoutenc)
 except LookupError: _stdoutenc=sys.getdefaultencoding()
 class StdOut:
 def write(self,s): 
_stdout.write(s.encode(_stdoutenc,'backslashreplace'))
 sys.stdout=StdOut()


 > > I think this is not a good behaviour of python to be so picky.
 >
 > I think it it is good.
 >
 >Errors should never pass silently.
 >Unless explicitly silenced.

A political question. Arguments:

* Webbrowsers for example have to display defective HTML as good as 
possible, unknown unicode chars as "?" and so on... Users got very angry 
in the beginning of browsers when 'strict' programmers displayed their 
exception error boxes ...

* at least the "print" statement has to go through - the costs (for 
angry users and developers; e.g. 
http://blog.ianbicking.org/do-i-hate-unicode-or-do-i-hate-ascii.html) 
are much higher when apps suddenly break in simple print/display-output 
when the system picks up alien unicode chars somewhere (e.g. 
occasionally in filenames,...). No one is really angry when occasionally 
chinese chars are displayed cryptically on non-chinese computers. One 
can investigate, add fonts, ... to improve, or do nothing in most cases, 
but apps do not break on every print statement! This is not only true 
for tty-output, but also for log-file redirect and almost any common 
situation for print/normal stdout/file-(write)-output.

* anything is nice-printable in python by default, why not 
unicode-strings!? If the decision for default 'strict' encoding on 
stdout stands, we have at least to discuss about print-repr for unicode.

* the need for having technical strings 'strict' is much more rare. And 
programmers are anyway very aware in such situations . e.g. by 
asciifile.write( us.encode(xy,'strict') )   .

* on Windows for example the (good) mbcs_encode is anyway tolerant as 
it: unkown chars are mapped to '?' . I never had any objection to this.

Some recommendations - soft to hard:

* make print-repr for unicode strings tolerant  (and in PythonWin alwasy 
tolerant 'mbcs' encoding)

* make stdout/files to have 'replace'-mode encoding by default. (similar 
as done with my code above)

* set site.py/encoding=('ascii', 'replace')   # if not utf-8/mbcs/locale 
;enable a tuple
* save sys._setdefaultencoding by default

* I would also live perfectly with .encode(enc) to run 'replace' by 
default, and 'strict' on demand. None of my apps and scripts would break 
because of this, but win. A programmer is naturally very aware when he 
wants 'strict'. Can you name realistic cases where 'replace' behavior 
would be so critical that a program damages something?


 > > In
 > > [EMAIL PROTECTED] I showed, how I
 > > solved this so far. Any better/portable idea?
 >
 > Not sure why you aren't using sys.stdout.encoding on Linux. I would do
 >
 > try:
 >   c = codecs.getwriter(sys.stdout.encoding)
 > except:
 >   c = codecs.getwriter('ascii')
 > sys.stdout = c(sys.stdout, 'replace')
 >
 > Also, I wouldn't edit site.py, but instead add sitecustomize.py.

I have more problems with the shape of sys.path in different situations, 
multiple sitecustomize.py on other apps, environments, OS / users, 
cxfreeze,py2exe  ...   sitecustomize not stackable easily: a horror 
solution. The need is for a callable _function_ or for general change in 
python behaviour.

modifiying site.py is better and stable for me (I have my 
patch/module-todo-list handy each time i install a new python), as I 
always want tolerant behaviour. in code i check for 
site.encoding/_setdefaultencoding (I save this). Thus i get one central 
error if setup is not correct, but not evil unicode-errors somewhere 
deep in the app once on a russian computer in the future...

 > > Yes. But the original problem is, th

Re: [Python-Dev] PEP and stdlib

[Martin v. Löwis]

Fabien Schwob wrote:
> What do you think about that ?

See PEP 2.

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

Re: [Python-Dev] Ph.D. dissertation ideas?

[Brett Cannon]

On 1/12/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Brett,
>
> How about building a system that compiles a Python program (possibly
> annotated) to an AJAX program?  That is, it analyzes the program to
> determine what's appropriate and possible for client-side and
> server-side, figures out the optimal network API (reduce latency,
> reduce calls, reduce data transfer, increase responsiveness),
> generates server-side Jython to run in Tomcat (or Python for
> mod_python), and client-side XHTML, CSS, and Javascript to implement
> the browser-based portion of the application.  Oddities of browser
> implementations and Javascript VMs would be contained in the compiler
> and automatically pushed into the generated code.
>
> This would be a tremendously useful advance in building distributed
> systems that work with the Web.  The current approach to AJAX is a bit
> like carpentry with old hand tools.  You'd probably also push Python
> to higher levels of language-ness.
>

Hmm.  It's an idea.  I also thought of Python -> JavaScript compiler
since JavaScript is not fun and getting to test using Python might be
cool.  But not sure how useful that would be.  Plus I bet someone has
does this with Java or something.

-Brett
___
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] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries

[Crutcher Dunnavant]

I sorta disagree about it not being broken. Adding a feature which
works for eval but not for exec seems pretty broken. It's difficult to
reason about what will happen in the exec context, so I can't see what
fixing it would endanger; but I'd deffinately like to see it for 2.5.

I've run rough timings on the code, ('test make time'), detailed in
the patch discussion, and it seems completely lost in the noise.

On 1/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Is there any objection to this patch? Any support?
>
> It is assigned to me.  When I have time, will go through it in detail
> (the given use cases, more detailed timings, and a close reading of the
> code).
>
> If accepted, it will be for Py2.5, as it is a new feature.  There is
> nothing broken about the existing eval() version, it just doesn't apply
> as broadly as you would have liked.
>
>
>
> Raymond
>
>


--
Crutcher Dunnavant <[EMAIL PROTECTED]>
monket.samedi-studios.com
___
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] Ph.D. dissertation ideas?

[Bill Janssen]

Brett,

How about building a system that compiles a Python program (possibly
annotated) to an AJAX program?  That is, it analyzes the program to
determine what's appropriate and possible for client-side and
server-side, figures out the optimal network API (reduce latency,
reduce calls, reduce data transfer, increase responsiveness),
generates server-side Jython to run in Tomcat (or Python for
mod_python), and client-side XHTML, CSS, and Javascript to implement
the browser-based portion of the application.  Oddities of browser
implementations and Javascript VMs would be contained in the compiler
and automatically pushed into the generated code.

This would be a tremendously useful advance in building distributed
systems that work with the Web.  The current approach to AJAX is a bit
like carpentry with old hand tools.  You'd probably also push Python
to higher levels of language-ness.

> Tough question.  Language design is the over-reaching area that I
> love.  Basically how can powerful language ideas be presented in a
> easy-to-use fashion.  Could even generalize even farther to just
> making programming easier through the language.  And for some reason
> networking protocols and concurrent programming have always caught my
> eye

Bill
___
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] ConfigParser to save with order

[Tony Meyer]

> I see two paths here:
>
> - Rewrite ConfigParser entirely.
> - Apply my patch.

Allowing 'surgical' editing of configuration files, as has been  
proposed many times both here and c.l.p would not require  
ConfigParser to be entirely rewritten (just more extensive  
modification of the write() method).

> Someone needs to make a PEP. Michael Chermside, in the
> first mail of the first link that you sent, was working in a solution,
> but don't know what is done.

I believe that this always trails off without anything being achieved.

IMO what would be best would be a pronouncement (or something of  
similar weight) about the direction that should be taken wrt to  
configuration file parsing support in the stdlib.

   * The status quo.
   * The status quo, but output files in a fixed order (but unrelated  
to the read order); i.e. http://python.org/sf/1399309
   * 'Surgical' editing of files; i.e. preserve comments, whitespace,  
and ordering, appending new options/sections as needed.
   * A more complex configuration system (perhaps like others that  
exist in the wild).

I'm happy to either submit or help with a patch for the third option  
(and maybe the fourth) if need be.

I haven't personally found the lack of a more complex system in the  
stdlib a problem (although I suppose that the various more complex  
systems I have worked with could have been simplified if there was  
one).  I do believe that failing to preserve comments and ordering is  
a problem.

=Tony.Meyer

___
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] r42015 - peps/trunk

[Tim Peters]

[Tim Peters]
>> Yes. please.  svn:externals should always pin to a specific revision
>> (or at least to a "frozen" tag).  Updating to a new revision then is
>> just a propedit away (to change the revision number); ditto for
>> backing off to an older revision if the newer one has problems.

[Fredrik Lundh]
> wasn't the whole point for this exercise

Sorry, I don't know what the whole point was.

> to make sure that the included version was always up to date.  if you pin
> it to a given version, all we got from this was a dependence on another SVN
> server.

And very easy updating to a new version ("a propedit away ..."), and
transparency about exactly what it is we're depending on ("revision
12345 of project XYZ").

> (and a can of SVN worms, including issues with locking/cleanup, etc)

I haven't experienced any of that.  I've experienced plenty of
locking/cleanup problems when a project switches _between_ making its
own copies and using svn:externals, but none so long as it sticks to
one way of doing that.  Even on Windows ;-)
___
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] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)

[Martin v. Löwis]

M.-A. Lemburg wrote:
> What if x64 has a 64-bit value ? How do you catch
> and process the truncation error ?

We were *both* discussing a scenario where no sizes
exceed 2**31, right?

Under such a scenario, this just won't happen.

OTOH, if you were discussing a scenario where sizes
might exceed 2**31, then I don't see why you are worried
about Py_ssize_t* parameters alone: Even

  PyString_Size()

might (of course!) return a value > 2**31 - so it
is not just output parameters, but also return values.

For more information, please read "Conversion guidelines"
in

http://www.python.org/peps/pep-0353.html

>>That is not necessary. Can you give in example of a module
>>where you think it is necessary?
> 
> 
> If you want to port the extension to Py_ssize_t, this
> is essentially the case.
> 
> You might want to take the unicodeobject.c file as
> example.

unicodeobject.c is not an extension. We were discussing
existing extension modules.

> We could use the type flags for these. much like we
> do for the new style numbers.

Would you like to write a specification for that?

> If you don't like the macro approach, why not simply
> leave the two separate sets of APIs visible.

To simplify the porting.

> All Py_ssize_t aware and compatible extensions
> would use the new APIs instead. The old-style APIs
> should then take care of the proper down-casting and
> error reporting.

That is not possible. Some API does not support
error reporting (like PyString_Size()). So callers
don't expect it to fail.

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

[Python-Dev] Ph.D. dissertation ideas?

[Brett Cannon]

It is time once again in my educational career to come to python-dev
for help for major project ideas.  This time, though, it is for my
Ph.D. dissertation (and thus can have larger scope than my masters
thesis) but there are funding restrictions (and thus only certain
areas I have possible funding for).

First off, there are two areas where I have possible funding: XML
integration into programming languages and game scripting support (I
have a third, AOP for anything, but  I don't think AOP is a good match
for Python and thus not considering it for Python work).  The XML
integration I have no direct ideas since I don't use XML.  There is
the possibility of doing something like the LINQ project
(http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp)
or something, but I don't know how useful that could be.  It would
have to be just as generic, though, as the LINQ project in terms of
working with intefaces to be Pythonic so it might turn out to be more
about language support for querying data.

For the game scripting, trying out the active objects for Python is a
possibility (or something else that would help with concurrency). 
Since that could allow for agent objects to be more concurrent it can
be argued that it would help with game scripting.  I don't have any
other ideas for the area of game scripting support.

Now I am not locked down to these areas, but they are what I have
possible grant money for.  If through some miracle someone out there
wants to fund my Ph.D. and wants something else worked on for Python,
don't be shy.  =)  Unfortunately I don't think the PSF is up for
funding my Ph.D., else I would say I would work on whatever python-dev
decided they wanted to worked on that could be done as a dissertation.

Anyway, any ideas are appreciated.  There is no rush on this, either. 
Just getting this out there now while I am tentatively exploring
possible topics.

-Brett
___
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] Ph.D. dissertation ideas?

[Phillip J. Eby]

At 02:36 PM 1/12/2006 -0800, Brett Cannon wrote:
>(I have a third, AOP for anything, but  I don't think AOP is a good match
>for Python and thus not considering it for Python work)

For what it's worth, I've been doing what I'll loosely refer to as 
"research" on implementing a non-traditional form of AOP in Python via the 
combination of extensible generic functions and contextual variables -- two 
concepts that already exist in Python but which can be extended far beyond 
what is in current use.

The combination can be used to implement an "explicit is better than 
implicit" form of AOP, that is usually handled by a "weaving language" in 
classic AOP implementations.  I don't know of any published AOP work that 
focuses on the use of these kinds of tools; the communities that talk about 
the respective technologies appear to be disjoint.

Anyway, extensible generic operations in Python like 'len()', 'copy()' and 
so on are fairly common, but it's rare that people define their own such 
functions, as opposed to using ones in the stdlib.  A typical workaround in 
larger frameworks is to use interfaces and adaptation, but extensible 
generic operations make it easier to separate concerns orthogonally.

So, although you might think that AOP isn't "a good match for Python", the 
truth is that there's actually a fair amount of AOP-like things being done 
with Python.  It's just that classic structuring of AOP into things like 
aspects and weavers and all that crud is overcomplication.  If you view it 
simply in terms of extensible operations, which can also make decisions 
based on context, then you can achieve all the same goals of "classic" AOP 
without using any of its concepts or terminology.

One definition of AOP claims that it allows asserting qualified statements 
over oblivious code.  Python has this basic ability natively -- 
monkeypatching suffices to meet that definition.  The interesting question 
is, how can you do it *without* monkeypatching?

___
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] Include ctypes into core Python?

[Martin v. Löwis]

Thomas Heller wrote:
> Sounds good, although it should be noted that ctypes is a package now,
> with a ctypes.wrap subpackage (contains the code generator), a
> ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X),
> and ctypes.test subpackage whcih contains several test modules.  Plus
> the _ctypes.(dll|so) extension module.

Ok. The installer should then combine them all into a feature.

Still, the admin could disable all of this just by removing _ctypes.dll,
right?

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

Re: [Python-Dev] r42015 - peps/trunk

[Tim Peters]

[David Goodger]
...
> An alternative is to use svn:externals to link to a specific
> revision (via the -r option);

Yes. please.  svn:externals should always pin to a specific revision
(or at least to a "frozen" tag).  Updating to a new revision then is
just a propedit away (to change the revision number); ditto for
backing off to an older revision if the newer one has problems.

As to the rest, you're using externals in a vanilla way for their
intended purpose, and I have no problems with that.
___
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] r42015 - peps/trunk

[Fredrik Lundh]

Tim Peters wrote:

> Yes. please.  svn:externals should always pin to a specific revision
> (or at least to a "frozen" tag).  Updating to a new revision then is
> just a propedit away (to change the revision number); ditto for
> backing off to an older revision if the newer one has problems.

wasn't the whole point for this exercise to make sure that the included
version was always up to date.  if you pin it to a given version, all we
got from this was a dependence on another SVN server.

(and a can of SVN worms, including issues with locking/cleanup, etc)





___
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] PEP and stdlib

[Fabien Schwob]

Hello,

I've often read new PEP that are published, and they are often about new 
additions to the core language. Why not using them with the standard 
library.

Guido often say that he don't want to include new module that aren't 
widely used in the community. It's a good thing, but it lead to the 
creation of a lot of API incompatible modules. Why not using PEP in 
order to create standard API like the Java world do with JSRs (Java 
Specification Requests) ?

What do you think about that ?

-- 
Fabien

___
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] building a module catalogue with buildbot

[Fredrik Lundh]

Martin v. Löwis wrote:

> > My initial thought was that we could ask alpha testers to run this script on
> > their alpha builds, and report back, but it just struck me that the 
> > "buildbot"
> > already builds stuff on a couple of interesting platforms.
> >
> > Can buildbot deal with custom test/validation scripts, and collect the 
> > output
> > somewhere ?
>
> Collecting the output is the real challenge. Basically, you are
> restricted to putting stdout of a process into a file. So a result
> that is a set of linked HTML files is not supported.

The listmodule utility only outputs a plain list of available modules.  Just
being to able to scrape the lists off http://www.python.org/dev/buildbot/
would be good enough.





___
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] Include ctypes into core Python?

[Thomas Heller]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> Guido van Rossum wrote:
>> On the other hand it breaks one of the most fundamental Python
>> guidelines: if you get a core dump (segfault etc.) it's a bug in
>> Python or in a 3rd party extension, not in *your* Python code. An
>> exception would have to be made for any code that uses ctypes, as it
>> is usually trivial to cause core dumps with ctypes (I'd venture it's
>> hard to avoid them ;-).
>> 
>> I don't expect this to count against including ctypes; but I do want
>> it to be dealt with somehow!
>
> I think the strongest point *for* ctypes is the inclusion of dl
> in the source distribution, which has the very same flaws as
> ctypes in terms of crashability.
>
> So as for dealing with it "somehow": I would make ctypes a dynamically
> loaded module (ctypes.pyd), so administrators could remove it, and
> I could also make it a separate option in the Windows installer,
> so administrators could reject to install it.

Sounds good, although it should be noted that ctypes is a package now,
with a ctypes.wrap subpackage (contains the code generator), a
ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X),
and ctypes.test subpackage whcih contains several test modules.  Plus
the _ctypes.(dll|so) extension module.

Thomas

___
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] r42015 - peps/trunk

[David Goodger]

On 1/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I know, but I wouldn't expect SVN to query other servers
> than svn.python.org inside the standard repository
> directories.
>
> AFAIK, this is a first in the Python repository.

True, and worth discussing.  Luckily the PEPs repository is a
low-traffic, non-core area, so it's not urgent.

> Not sure if it's such a good idea.

>From my point of view, it's a time-saver.  No more manual updates!
They were a pain, and rarely got done.

> Branching and tagging
> doesn't work with external resources in Subversion,
> so things can become inconsistent.

How so?  The "svn:externals" property is treated the same as any
other, and is copied along with everything else by "svn copy".

> Also, what if you break the code in the berlios repo
> or the server is not reachable ?

If the code in the repo ever breaks, it will be fixed within minutes.
The server being unreachable is only a problem for initial checkouts;
updates will just keep the code that was already there.  In my
experience, the berlios.de SVN server has rarely been unreachable.  If
there's a problem, we can always back out the svn:externals property
and install the package.

That having been said, I do see the value of installing a packaged
release.  We just released Docutils 0.4 a few days ago; I could
install that statically.  An alternative is to use svn:externals to
link to a specific revision (via the -r option); I could link to the
0.4 release revision.  This would solve the repo-breakage issue, but
not the server-unreachability issue.

I don't think these issues are major, but I wouldn't mind terribly if
we decide to go with a static install.

> A release copy in the
> external/ dir would solve all these issues.

That's basically what we had before (except no explicity "external"
directory), but it was always out of date.  The "docutils" package was
directly in the trunk, for ease of import by the pep2html.py front end
(easy to work around, but why bother?).

Another minor nit with the old way: updates "polluted" the
python-checkins list.

--
David Goodger 
___
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] Include ctypes into core Python?

[Thomas Heller]

"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> writes:

> "Martin v. Löwis" wrote:
>
>> So as for dealing with it "somehow": I would make ctypes a dynamically
>> loaded module (ctypes.pyd), so administrators could remove it, and
>> I could also make it a separate option in the Windows installer,
>> so administrators could reject to install it.
>
> I like this solution. Of course, Thomas (author of both py2exe and
> ctypes) may like the ability to have ctypes built into python.dll ...

It is getting offtopic, but I don't care too much about that.  I
requested that zlib be changed to a builtin module too allow easier
bootstrapping of py2exe'd apps which have a compressed library archive.

The nearly only reason for me to implement the single-file option for
py2exe was that the implementation simulates a static linked Python-dll,
which allows for several totally-isolated interpreters in the same
process.

Thomas

___
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] r42015 - peps/trunk

[Fredrik Lundh]

M.-A. Lemburg wrote:

> AFAIK, this is a first in the Python repository. Not
> sure if it's such a good idea. Branching and tagging
> doesn't work with external resources in Subversion,
> so things can become inconsistent.
>
> Also, what if you break the code in the berlios repo
> or the server is not reachable ? A release copy in the
> external/ dir would solve all these issues.

using svn:external is usually a lousy idea.  using it in a public repository
is a really, really, really lousy idea.





___
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] r42015 - peps/trunk

[M.-A. Lemburg]

David Goodger wrote:
> On 1/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Hmm, shouldn't these things be tracked under external/ ?!
> 
> What do you mean exactly? A new "external" directory?

Yes.

> SVN provides a built-in mechanism for tracking external
> repositories, via the "svn:externals" property, and that's
> what I used.

I know, but I wouldn't expect SVN to query other servers
than svn.python.org inside the standard repository
directories.

AFAIK, this is a first in the Python repository. Not
sure if it's such a good idea. Branching and tagging
doesn't work with external resources in Subversion,
so things can become inconsistent.

Also, what if you break the code in the berlios repo
or the server is not reachable ? A release copy in the
external/ dir would solve all these issues.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 12 2006)
>>> 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] r42015 - peps/trunk

[David Goodger]

On 1/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Hmm, shouldn't these things be tracked under external/ ?!

What do you mean exactly? A new "external" directory?

SVN provides a built-in mechanism for tracking external
repositories, via the "svn:externals" property, and that's
what I used.

--
David Goodger 
___
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] r42015 - peps/trunk

[M.-A. Lemburg]

David Goodger wrote:
> [M.-A. Lemburg]
>> Question: why do we need docutils in the peps/trunk/ directory
>> in the first place ?
> 
> It's a convenience, so that a separate Docutils download & install
> (& maintain) isn't necessary for those who process reST-format PEPs.

Hmm, shouldn't these things be tracked under external/ ?!

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 12 2006)
>>> 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] r42015 - peps/trunk

[David Goodger]

[M.-A. Lemburg]
> Question: why do we need docutils in the peps/trunk/ directory
> in the first place ?

It's a convenience, so that a separate Docutils download & install
(& maintain) isn't necessary for those who process reST-format PEPs.

-- 
David Goodger 



signature.asc
Description: OpenPGP digital signature
___
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] r42015 - peps/trunk

[M.-A. Lemburg]

David Goodger wrote:
>> Author: david.goodger
>> Date: Thu Jan 12 04:33:16 2006
>> New Revision: 42015
>>
>> Modified:
>>peps/trunk/   (props changed)
>> Log:
>> add external link to Docutils public repo -- always up-to-date
> 
> I just deleted the static copy of the "docutils" directory from the "peps"
> repository, and added in an external link (svn:externals 'docutils
> svn://svn.berlios.de/docutils/trunk/docutils/docutils').  This way, the 
> external
> code should always be up-to-date.  You may need to manually delete your
> peps/trunk/docutils directory to get this to work though -- SVN leaves
> subdirectories behind which hinder the externals update.
> 
> Please let me know if this causes any problems.  Thanks.

Question: why do we need docutils in the peps/trunk/ directory
in the first place ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 12 2006)
>>> 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] New PEP: Using ssize_t as the index type

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> If it were this easy, I wouldn't have objections. But it's
>> not.
> 
> It is so easy. Can you should me an example where it isn't?
> 
>> The variables you use with these APIs tend to propagate
>> through the extension, you use them in other calls,
>> make assignments, etc.
> 
> They only propage if you make them. You don't have to,
> if you don't want to.
> 
>> If you implement extension types, you end up having to
>> convert all the length related struct variables to
>> Py_ssize_t.
> 
> Only if you want to. If not, the module will work
> (nearly) unmodified. Of course, it will be limited
> to 32-bit indices.

See my other reply on this topic.

>> All this is fine, but it's also a lot of work which
>> can be made easier. Recompiling an extension is well
>> within range of many Python users, manually checking,
>> fixing and porting it to the new API is certainly not.
> 
> Sure. However, most users will compile it on 32-bit
> systems. If they find they cannot get it to work on
> a 64-bit system, they should ask the author for help,
> or just use it in 32-bit mode (as 64-bit mode won't
> gain them anything, anyway).

I wonder how you are going to import a 32-bit
extension into a 64-bit binary of Python.
It simply doesn't work.

>> The set of functions that will require Py_ssize_t
>> is getting larger in your branch which is why I started
>> this discussion.
> 
> How so? I did not add a single function that has
> int* output values, AFAICT.

No, but there are quite a few APIs with Py_ssize_t*
output values.

> I am talking about the entirety of these functions,
> and claim that they are rarely used (including the
> Unicode and buffer APIs).

I wouldn't say that PyString_AsStringAndSize() is rarely
used and neither is PyArg_ParseTuple().

I agree that other APIs are certainly more domain
specific and can be dealt with in the extension, but
those two APIs need special care and so do the type
slot functions.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 12 2006)
>>> 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] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> ... and then the type change of that variable propagates
>> throughout the extension.
> 
> That depends on the usage of the code. If the variable
> is passed by value, no further changes are necessary.
> If a pointer to the variable is passed, you could replace
> it with
> 
>   Py_ssize_t x64; int x;
>   foo(&x64);
>   x = x64;
> 
> Then use x as you did with the original code.

What if x64 has a 64-bit value ? How do you catch
and process the truncation error ?

To do this down-casting correctly, you'd need to write
code that does bounds checks and integrate into the
functions error handling.

>> You basically end up having to convert the whole extension
>> to Py_ssize_t.
> 
> That is not necessary. Can you give in example of a module
> where you think it is necessary?

If you want to port the extension to Py_ssize_t, this
is essentially the case.

You might want to take the unicodeobject.c file as
example.

>> Don't get me wrong: I don't mind doing this for the eGenix
>> extensions, but I'm worried about the gazillion other
>> useful extensions out there which probably won't get
>> upgraded in time to be used with Python 2.5.
> 
> I agree that it is not acceptable to require immediate
> whole-sale updates of every modules. However, I do
> believe that the number of modules that need any change
> at all is small, and that those modules can be modified
> with minimal effort to "get them working again,
> backwards-compatible" (i.e. with the only exception that
> they would fail if indices run above 2**31).
> 
>> I think all it takes is a set of new APIs for functions
>> that use Py_ssize_t as output parameter and which are
>> mapped to the regular API names if and only if the
>> extension #defines PY_SSIZE_T_CLEAN (or some other
>> capability flag).
> 
> That is not enough. You also need to deal with the
> function pointers that change.

We could use the type flags for these. much like we
do for the new style numbers.

> Also, others have rejected/expressed dislike of the
> PY_SIZE_T_CLEAN macro already, so they would probably
> dislike further hackishness in that direction.

That's easy to say... by not providing an easy way
to upgrade extensions, you basically just move the
requirement for hacks into the extensions.

I wouldn't consider that a good solution.

If you don't like the macro approach, why not simply
leave the two separate sets of APIs visible. Old
extensions would then use and link against the existing
APIs. All Py_ssize_t aware and compatible extensions
would use the new APIs instead. The old-style APIs
should then take care of the proper down-casting and
error reporting.

In Py3K we could then remove the old-style ones
and rename the new ones to the old names. Porting
an already Py_ssize_t compatible extension to the
renamed new style APIs would then become a simple
task of search&replace.

> Anyway, I have installed the PEP onsite, and
> added an "Open Issues" section, recording your
> comments.

Thanks.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 12 2006)
>>> 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] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries

[Raymond Hettinger]

> Is there any objection to this patch? Any support?

It is assigned to me.  When I have time, will go through it in detail
(the given use cases, more detailed timings, and a close reading of the
code).

If accepted, it will be for Py2.5, as it is a new feature.  There is
nothing broken about the existing eval() version, it just doesn't apply
as broadly as you would have liked.



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