Re: [Python-Dev] os.path.getmtime on Windows

2006-01-15 Thread Martin v. Löwis 
Phillip J. Eby wrote:
> Windows doesn't store UTC timestamps, at least not on older FAT filesystems 
> and maybe not even on NTFS.  Changing Python won't help.  :)

Windows definitely stores UTC timestamps on NTFS, in units of 100ns
since Jan 1, 1601.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.getmtime on Windows

2006-01-15 Thread Martin v. Löwis 
Christian Tismer wrote:
> Is there a way to circumvent this problem, or am I missing something?
> If this is not the expected behavior, then it might make sense
> to find a patch.

I have meant to work on a patch for several years now. I would like to
drop usage of msvcrt's stat(3), and instead implement os.stat in terms
of Windows API directly. That would also have the advantage that
subsecond time-stamps can be exposed.

There are several issues involved in implementing such a patch, though.
One is that you need to do it twice: once for Win9x, and once for
NT+, because you have to use Unicode file names on one system, and
ANSI file names on the other.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

2006-01-15 Thread Collin Winter 
On 1/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> my main nit is the name: the test isn't broken in itself, and doesn't need
> to be fixed; it's just not expected to succeed at this time.
>
> the usual term for this is "expected failure" (sometimes called XFAIL).
>
> for the developer, this means that a failure is not a regression, and is pro-
> bably not caused by something that the developer just did.

When I've implemented this kind of thing in the past, I've generally
called the decorator/marker/whatever "TODO" (or some variation of
caps/lowercase).



Thanks,
Collin Winter
___
Python-Dev mailing list
[email protected]
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 icon

2006-01-15 Thread skip 

>> does Python have an official icon?

Ping> i found some images at http://www.pythonology.com/logos...

It appears the yin/yang Python's on that page are being used in the new site
(beta.python.org).  I don't know if that makes it official or not though.

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.getmtime on Windows

2006-01-15 Thread Christian Tismer 
Hi Martin,

>> Is there a way to circumvent this problem, or am I missing something?
>> If this is not the expected behavior, then it might make sense
>> to find a patch.
> 
> I have meant to work on a patch for several years now. I would like to
> drop usage of msvcrt's stat(3), and instead implement os.stat in terms
> of Windows API directly. That would also have the advantage that
> subsecond time-stamps can be exposed.

I see! Still trying to understand the story. I'm working through
the article Tim pointed us at.
http://www.codeproject.com/datetime/dstbugs.asp

Does it mean that msvcrt does extra magic to modify the existing
correct UTC entries? And would usage of the Windows API heal this
immediately, or are extra steps involved?
As I understand the article, things are different when a file is
stored in a FAT or NTFS drive.

Do you think the provided solution is worthwhile to be adapted
for Python?
http://www.codeproject.com/datetime/DstBugs/DstBugs.zip

> There are several issues involved in implementing such a patch, though.
> One is that you need to do it twice: once for Win9x, and once for
> NT+, because you have to use Unicode file names on one system, and
> ANSI file names on the other.

Correcting it just for NT/XP would make the majority of people
happy, IMHO.

cheers - chris
-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2006-01-15 Thread Gabriel Becedillas 
Michael Hudson wrote:
> Gabriel Becedillas <[EMAIL PROTECTED]> writes:
> 
> 
>>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 know you've said this to me in email already, but I have no idea how
> you managed to get this to work with 2.4.1 :)
> 
> 
>>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.
> 
> 
> I think I begin to understand the problem... but this is still
> fragile: it relies on the fact that you delete a thread state from the
> OS level thread that created it, but while a thread belonging to a
> different *interpreter state* has the GIL (or at least: the
> interpreter state of the thread state being deleted *doesn't* hold the
> GIL).  Can you guarantee that?

Mmm... it doesn't have to do with a race condition or something. Let me 
try to show you with an example (keep in mind that this relies on the 
fact that at some moment the operating system gives you a thread with 
the same id of another thread that allready finished executing):

// Initialize python.
Py_Initialize();
PyEval_InitThreads();
PyThreadState* p_main =  PyThreadState_Swap(NULL);
PyEval_ReleaseLock();

/*
Asume this block is executed in a separate thread, and that has been 
asigned thread id 10.
It doesn't matter what the main thread (the thread that initialized 
Python) is doing. Lets assume its waiting for this one to finish.
*/
{
PyEval_AcquireLock();
PyThreadState_Swap(p_main);
PyThreadState* p_child = PyThreadState_New(p_main->interp);

PyThreadState_Swap(p_child);
PyRun_SimpleString("print 'mi vieja mula ya no es lo que era'");

PyThreadState_Clear(p_child);
PyThreadState_Swap(NULL);
PyThreadState_Delete(p_child);
PyEval_ReleaseLock();
// The os level thread exits here.
}
/*
When this thread state gets deleted (using PyThreadState_Delete), the 
autoTLSkey stored for thread id number 10 is not removed, because 
PyThreadState_Delete doesn't have the necesary cleanup code (check 
pystate.c):

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

PyThreadState_DeleteCurrent behaves correctly because it does have this 
code.
I think that this code should be added to tstate_delete_common (I've 
done this and everything worked just fine).
If a new thread executes the same code, and that thread is assigned the 
same thread id, you get the Py_FatalError I'm talking about.
A workaround for this would be to use PyThreadState_DeleteCurrent 
instead of PyThreadState_Delete.

If you use the following code instead of the one above, the you have no 
way out to the Py_FatalError:
*/
{
PyEval_AcquireLock();
PyThreadState* ret = Py_NewInterpreter();

PyRun_SimpleString("print 'mi vieja mula ya no es lo que era'");

Py_EndInterpreter(ret);
PyThreadState_Swap(NULL);
PyEval_ReleaseLock();
}
/*
When this interpreter gets deleted (using Py_EndInterpreter), its thread 
state gets deleted using PyThreadState_Delete, and you are back to the 
beginning of the problem.
*/

I hope this helps to clarify the problem.
Thanks a lot and have a nice day.

> It seems to me that to be robust, you need a way of saying "delete the
> thread local value of autoTLSKey from thread $FOO".  But this is all
> very confusing...
> 
> 
>>Could you please confirm if this is a bug ?
> 
> 
> Yes, I think it's a bug.
> 
> Cheers,
> mwh
> 


-- 


Gabriel Becedillas
Developer
CORE SECURITY TECHNOLOGIES

Florida 141 - 2º cuerpo - 7º piso
C1005AAC Buenos Aires - Argentina
Tel/Fax: (54 11) 5032-CORE (2673)
http://www.corest.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.getmtime on Windows

2006-01-15 Thread Martin v. Löwis 
Christian Tismer wrote:
> Does it mean that msvcrt does extra magic to modify the existing
> correct UTC entries? 

Mostly, yes. For FAT, the system does also some conversion.
Those conversions I don't fully understand,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/file_times.asp

suggests that there are "cached UTC times" on FAT somewhere.

> And would usage of the Windows API heal this
> immediately, or are extra steps involved?

If we use GetFileTime, apparently yes. FindFirstFile apparently also
suffers from daylight conversion bugs when reading time stamps from FAT.

> As I understand the article, things are different when a file is
> stored in a FAT or NTFS drive.

Correct.

> Do you think the provided solution is worthwhile to be adapted
> for Python?
> http://www.codeproject.com/datetime/DstBugs/DstBugs.zip

No. If anything is done about this, it should be to drop msvcrt.

>> There are several issues involved in implementing such a patch, though.
>> One is that you need to do it twice: once for Win9x, and once for
>> NT+, because you have to use Unicode file names on one system, and
>> ANSI file names on the other.
> 
> 
> Correcting it just for NT/XP would make the majority of people
> happy, IMHO.

Right - the question would be whether completely breaking W9x support
in the process would be acceptable. We use the very same binaries
for W9x and NT.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

2006-01-15 Thread Martin v. Löwis 
Collin Winter wrote:
> When I've implemented this kind of thing in the past, I've generally
> called the decorator/marker/whatever "TODO" (or some variation of
> caps/lowercase).

I usually call things TODO if they need to be done. The test case is
not "TODO", since it is already done. "TODO" would be the place in
the code that needs to change; for an expected failure, you might not
even know where that code is.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.getmtime on Windows

2006-01-15 Thread Alexander Schremmer 
On Sun, 15 Jan 2006 20:23:39 +0100, "Martin v. Löwis" wrote:

>>> There are several issues involved in implementing such a patch, though.
>>> One is that you need to do it twice: once for Win9x, and once for
>>> NT+, because you have to use Unicode file names on one system, and
>>> ANSI file names on the other.

> Right - the question would be whether completely breaking W9x support
> in the process would be acceptable. We use the very same binaries
> for W9x and NT.

How about accessing/calling the wide char versions just if the OS is NT,
i.e. compiling both versions into the dll and just using one?

Looking at the file object, the open function uses "_wfopen" which needs
Windows NT according to the MSDN lib. So, how is 9x compat ensured here?

Kind regards,
Alexander

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.getmtime on Windows

2006-01-15 Thread Martin v. Löwis 
Alexander Schremmer wrote:
There are several issues involved in implementing such a patch, though.
One is that you need to do it twice: once for Win9x, and once for
NT+, because you have to use Unicode file names on one system, and
ANSI file names on the other.
> 
> 
>>Right - the question would be whether completely breaking W9x support
>>in the process would be acceptable. We use the very same binaries
>>for W9x and NT.
> 
> 
> How about accessing/calling the wide char versions just if the OS is NT,
> i.e. compiling both versions into the dll and just using one?

Right. That's what I meant when I said: "you need to do it twice".

> Looking at the file object, the open function uses "_wfopen" which needs
> Windows NT according to the MSDN lib. So, how is 9x compat ensured here?

There is a GetVersion check in there; not sure how effective it is,
though. However, if you pass byte strings, as the file name, _wfopen
is not used.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.getmtime on Windows

2006-01-15 Thread Martin v. Löwis 
Christian Tismer wrote:
> 1. create a file
> 2. get it's os.path.getmtime()
> 3. change your time zone
> 4. get os.path.getmtime again
> 
> compare - the time stamps are different.
> Change the time zone back, and they are identical, again.

Just to add an important detail here: I assume
you did not exit Python between step 2 and step 4, right?
(please confirm whether this is the case).

If so, it has nothing to do with daylight saving time.

If I start a new Python interpreter and fetch the mtime
again, it will report the value I got at step 2.

This is on NTFS, so the time stamps the system reports
(in FindFirstFile) are true UTC.

What happens is apparently this: msvcrt converts the UTC
time to local time, using FileTimeToLocalFileTime; this
gets the new time zone offset from the system. It then
converts it back through __loctotime_t. This invokes
__tzset, however, __tzset caches the _timezone offset,
so it is unaffected by the time zone change.

So *this* specific problem goes away as soon as we
start dropping msvcrt.

Regards,
Martin

P.S. The other problem (FindFirstFile gives bad UTC time
stamps on FAT, for files created in a different DST period)
has no real solution, AFAICT. There is no portable way to
determine whether the underlying file system stores time
stamps in local time or in UTC, and even if you know that
file stamps were in local time, you still couldn't reliably
convert that to UTC (because of the repeated hour, and
because of potential time zone changes).

So I would rather return to the user what the system gives
me, knowing that
a) the problem exists on FAT only, and people should use
   NTFS if they care about time stamps
b) it is better to document the limitation instead of
   trying to work around it: msvcrt shows that attempts
   to work around it make the problem worse, not better.
   So I would like to use FindFirstFile for stat(),
   and GetFileType+GetFileInformationByHandle for fstat().
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Birkenfeld's gone

2006-01-15 Thread Tim Peters 
[Georg Brandl -- or so he claimed on January 8]
> today, when two Python developers here had approached me about the PSF, I
> realized that it is time to correct a mistake which I had made over three 
> years
> ago, when I discovered Linux, free software, Usenet etc (I was sixteen at 
> that time).
>
> I then assumed a different name, partly to anonymize myself as others had 
> advised.
> When I came across Python, I instantly liked it, and since I had interest in
> Open Source development in general, I wanted to try and contribute to the
> development.
>
> And, as a matter of course, I used my different name for that. When I 
> realized that
> I liked the community and the development of Python very much, I decided to
> "unveil" myself, but I could never overcome myself -- till now.
>
> I'm really sorry, and I hope you could at least partly understand what caused
> me to act so irrational.

It doesn't really matter, Georg:  by default, Python compares by
object identity, not name.  If _you_ haven't changed, your name
doesn't matter.

Still, it takes real courage to reveal one's true identity, and you're
to be commended for it.  If it will make you feel better, "Aahz" was
born Bartholomew Fortescue Chillington the Third, and I was christened
Griselda Dolores Bignose.  Curiously, I'm not sure Guido even
remembers his true name (but, obviously, nobody would name their kid
"Guido").

I hope that revealing my true name too, and outing Aahz, will inspire
everyone to reveal their secret powers and home planets too.  I won't
be the first, though -- as you've discovered, when you're the first
you get ridiculed ;-).
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Birkenfeld's gone

2006-01-15 Thread Alex Martelli 

On Jan 15, 2006, at 6:46 PM, Tim Peters wrote:
 ...
> I hope that revealing my true name too, and outing Aahz, will inspire
> everyone to reveal their secret powers and home planets too.  I won't

OK, there I go -- "Alessandro Ferruccio Raffaele Martelli-Fortini".   
Good thing it's spelled in full only in one obscure church register  
and an even obscurer "Italian Register of Gentry", because I even  
feel it an imposition to have to spell out my legal first name  
"Alessandro" in some documents (it's that way in my passport, alas!)  
rather than the "Alex" I prefer... besides, no American ever spelled  
"Alessandro" right, I think they'd lose US citizenship if they did,  
or something, so I wanna stick with "Alex", which even THEY hardly  
ever manage to mis-spell (so they take their revenge by spelling my  
surname "Martinelli", like a popular local brand of [NON-alcoholic,  
yeck] cider... can't win, can't break even...).

Unfortunately none of my secret powers has to do with forcing  
Americans to spell correctly (indeed, that's rather my secret  
_weakness_ -- just seeing "its" and "it's" freely exchanged for each  
other instantly saps my will to live!)...


Alex

___
Python-Dev mailing list
[email protected]
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?

2006-01-15 Thread Dennis Allison 
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.

Brett--

Financial considerations aside, neither of the ideas you mention see ready
to be a dissertation topic.  I'd encourge you to look to other topics.

You might research interpreter structures for languages like Python which
do not use a global interpreter lock (GIL).  There's been discussion about
this from time to time on this list, even some suggestions as to what
might be done.  Given the trend toward multi-core processors, Python would
benefit if all processors did not need to block on the GIL. Guido told me
once that someone had build a Python interpreter with multiple locks, but
that the peformance was not very good and that the interpreter was
fragile.  This is, of course, a hard problem.

In 1974, Dijkstra wrote a fascinating paper on self-stabalizing 
algorithms; since that time a considerable literature has grown up.

Managing a Python system these days is a management problem when the
standard system is extended with libraries from many different sources,
each with different release schedules, dependencies, compatibilities, and 
documentation.  Automating the management of Python and its libraries 
might make a good dissertation topic, particualarly if there is some 
advice giving system that helps find an appropriate library for a 
particular problem.

Testing, optimization, refactopring tools, etc.

Dave Altel, following others, suggested in a provacatively title talks--

 



___
Python-Dev mailing list
[email protected]
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?

2006-01-15 Thread Brett Cannon 
On 1/15/06, Dennis Allison <[EMAIL PROTECTED]> wrote:
> 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.
>
> Brett--
>
> Financial considerations aside, neither of the ideas you mention see ready
> to be a dissertation topic.  I'd encourge you to look to other topics.
>

I'm open to other topics and in no way settled or locked into anything
mentioned so far.  Just need to be able to feed myself.  =)

> You might research interpreter structures for languages like Python which
> do not use a global interpreter lock (GIL).  There's been discussion about
> this from time to time on this list, even some suggestions as to what
> might be done.  Given the trend toward multi-core processors, Python would
> benefit if all processors did not need to block on the GIL. Guido told me
> once that someone had build a Python interpreter with multiple locks, but
> that the peformance was not very good and that the interpreter was
> fragile.  This is, of course, a hard problem.
>

It was Greg Stein who worked on it while at Microsoft.  He didn't
start to approach breaking even until two processors (if I remember
correctly).  None of the code was ever released.

This could fit under the concurrency or gaming funding if there is
some way to make threading just work better for Python.  So it's a
possibility.

> In 1974, Dijkstra wrote a fascinating paper on self-stabalizing
> algorithms; since that time a considerable literature has grown up.
>
> Managing a Python system these days is a management problem when the
> standard system is extended with libraries from many different sources,
> each with different release schedules, dependencies, compatibilities, and
> documentation.  Automating the management of Python and its libraries
> might make a good dissertation topic, particualarly if there is some
> advice giving system that helps find an appropriate library for a
> particular problem.
>

Possibilty.  Does tie into my lab's area of focus.

> Testing, optimization, refactopring tools, etc.
>

All possible general areas.

> Dave Altel, following others, suggested in a provacatively title talks--
>

Was there more to this line?  Seems like the email was cut off.

Thanks Dennis (and everyone, for that matter) for the continued help
and support!

-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 247 and hashlib

2006-01-15 Thread Seo Sanghyeon 
"PEP 247 -- API for Cryptographic Hash Functions" specifies a standard
API for hashing modules.

new([string])
... the optional 'string' parameter, if supplied, will be immediately
hashed into the object's starting state, as if obj.update(string) was
called.

But hashlib.new() takes the algorithm name... Does PEP need an update?

By the way, I am thinking about mapping .NET's
System.Security.Cryptography.HashAlgorithm.Create and created object's
ComputeHash method to Python's hash API for IronPython. For that, I'd
like to see a clarification.

Seo Sanghyeon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] basenumber redux

2006-01-15 Thread Alex Martelli 
For the last 2+ years I've been occasionally arguing for the  
introduction of a basenumber (and ideally a baseinteger, but that, to  
me, is a slightly lesser issue) analogous to basestring.  Google  
search fo [basenumber site:python.org] for several messages on the  
subject, by me and others; it will also find the recent thread about  
more general abstract baseclasses, which seems to have bogged down on  
such issues as whether sets are mappings.

Now, today, I have _again_ been bit by the lack of basenumber (by a  
bug of mine, fixed by adding decimal.Decimal to a long tuple of  
classes to be passed to an isinstance call -- I hadn't run that  
particular numeric code of mine since the time of Python 2.3,  
apparently), so I'm back to pining for it.  The previous discussion  
was short but pretty exhaustive, so I'd ask further discussants to  
refer back to it, rather than repeating it; no blocking issue appears  
to have emerged at that time, plenty of use cases were pointed out,  
etc.  Can we PLEASE have basenumber (and maybe baseinteger, so  
sequences can typecheck against that for their indices -- that's the  
key usecase of baseinteger) rather than have them "hijacked" by wider  
consideration of basesequence, basemapping, and so on...?  Pretty  
please?  Let's be pragmatic: basenumber isn't at all complicated  
nor controversial, baseinteger hardly at all, so let's accept them  
while pondering on other potential base* classes for as long as it  
takes for the dust to settle

I'll be happy to draft a PEP if needed (and just as happy to  
eventually provide an implementation patch if the PEP's accepted),  
but wanted to doublecheck on the general issue first!


Alex

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] basenumber redux

2006-01-15 Thread Martin v. Löwis 
Alex Martelli wrote:
> I'll be happy to draft a PEP if needed (and just as happy to  
> eventually provide an implementation patch if the PEP's accepted),  
> but wanted to doublecheck on the general issue first!

Please do so. I've browsed somewhat through past discussions,
but wasn't able to find a proposed specification of basenumber.
Also, I only found half of a rationale for it: it is meant to
be used along with isinstance, but I couldn't find out why
you wanted to do that. In

http://mail.python.org/pipermail/python-dev/2003-November/039916.html

you explain that you wanted to multiply all items of self with
other if other is a number; why couldn't this be written as

  def __mul__(self, other):
try:
   return self.__class__([ x*other for x in self.items ])
except TypeError:
   # various other multiplication cases

You give performance as the rationale; this is unconvincing as
it would rather indicate that performance of exceptions should
be improved (also, I think it is unpythonic to change the
language for performance reasons, except in really common
cases).

Also, in that example, I wonder if the use of multiplication
is flawed. If you have so many multiplication cases, perhaps
you abuse the notion of multiplication? Users will need to
understand the different cases, as well, and they will be
surprised when it works in one case, but not in a (seemingly
similar) othercase.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com