Re: [Python-Dev] xmlrpclib and dates before 1900

[Ralf Schmitt]

On Thu, Apr 3, 2008 at 5:36 AM, <[EMAIL PROTECTED]> wrote:

>
> It's actually not xmlrpclib which has the limitation, but
> datetime.strftime().  That's a known limitation.  Here's the comment in
> the
> datetime code:
> [snip]
> Personally, I don't think patching xmlrpclib is the right place to "fix"
> this problem.  It's possible that the datetime comment is no longer
> correct
>

yes, you're right. but I didn't feel like writing a strftime implementation
(which has probably even less chance of being committed). This patch is
rather tiny, it's easy to understand and it works now.


> and that limitation should be reconsidered.  I see no other mention of
> PYTHON2K in any .c, .h or .py files in the trunk.
>
> Skip
>
>
___
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] xmlrpclib and dates before 1900

[Ralf Schmitt]

On Thu, Apr 3, 2008 at 5:52 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

>
> I'd like to see this fixed if possible, but I'm not sure how -- the C
> level 'struct tm' has (year - 1900) in the tm_year member, and I'm not
> sure that implementations are required to do anything with negative
> values there. We'd have to reimplement all of strftime ourselves. I'm
> not against that, but there are higher priorities.
>

Have you considered using the pure python datetime implementation from the
pypy project for py3k?
It's even based on your own code :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Annotations support in python

[Heshan Suriyaarachchi]

 Hi,
 I need to work with annotations as it is said in [1]. Currently I am
using python 2.5.1. I would like to know whether the
next release of python will support this feature. If the next version
support this feature I would like to know when are you
planning to release it. I used the __future__ module but I could not get the
annotations with it.

[1] -  http://www.python.org/dev/peps/pep-3107/

Thanx
Heshan Suriyaarachchi
___
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] Annotations support in python

[Thomas Wouters]

On Thu, Apr 3, 2008 at 1:47 PM, Heshan Suriyaarachchi <[EMAIL PROTECTED]>
wrote:

>  Hi,
>  I need to work with annotations as it is said in [1]. Currently I am
> using python 2.5.1. I would like to know whether the
> next release of python will support this feature. If the next version
> support this feature I would like to know when are you
> planning to release it. I used the __future__ module but I could not get
> the annotations with it.
>
> [1] -  http://www.python.org/dev/peps/pep-3107/
>


The 3xxx PEPs are all about Python 3.0. Python 3.0 is the version that will
support function annotations. Python 2.6 will almost certainly not, and 2.5
will most assuredly not -- features don't get added after the major version
has been released, we only fix bugs.

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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] fixing tests on windows

[Tim Golden]

[re tests which fail because something's holding a file
open with SHARE_DELETE]

Well I've tried my best, but I can't come up with a solution
which guarantees to overcome this obstacle. I set up a fairly
aggressive directory watcher which, when it sees a test file
being created, takes a SHARE_DELETE handle on it and releases
it immediately. (Guessing that this is what the other apps
are doing).

Running the test suite from HEAD, this generates all manner
of access-denied type errors as per the original output.

I used tempfile to generate a random TESTFN in the current directory
rather than the static @test. And implemented the rename-shim
discussed previously, renaming to a different random name, courtesy
of mktemp. With those in place, most tests run without error. But
I'm still getting errors in the same sort of areas which Steven B
originally reported.

The one error I can't see a way round is the access denied (which
manifests as Permission Error) which is the documented result of
attempting to open a file with a pending delete -- ie the delete
succeeded but hasn't completed yet.

An additional complication is that there are hundreds of
instances throughout the tests where the test simply calls
os.unlink/os.remove to undo the test file. To have some more
robust central deletion I had to go through and update 68 tests.

I'll keep trying, but in the current state I'm not convinced
the situation's improved enough for me to bother uploading
a patch.

TJG
___
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] fixing tests on windows

[Trent Nelson]

[Disclaimer: thought dump e-mail, signal to noise ratio may be subpar.]

Sounds like you're at least making steps forward in the right direction, 
despite the activity probably being quite disheartening.  Based on what you've 
said below and the rest of the conversation, here are my thoughts for an 
approach:

1.  For a given python[_d].exe, always use the same test directory, but hash it 
against the entire python process path such that it's unique only for a given 
python instance.
2.  Make sure every time a test wants a temp file, it gets a unique one in this 
directory.  Sounds like your TESTFN modification would take care of this for 
those tests using TESTFN; if TESTFN is the preferred approach then any other 
tests using tempfile or hardcoding file names would then be changed to use this 
instead.
3.  In order to address tests that either call the test_support methods for 
removing files/directories, or those that call os.(unlink|remove), do what ever 
needs to be done to make these no-ops on Windows if an error occurs.
4.  At the end of the regrtest.py run, create a suspended arbitrary process 
(i.e. explorer.exe), hijack the main thread context of the process and inject a 
routine (i.e. overwrite the thread context's instruction pointers) that takes 
care of removing the temporary directory that was used for testing -- patiently 
re-trying if any failures occur until all rogue processes also accessing the 
file(s) stop doing so.  Resume the thread before exiting python.

Heh.  Sounds crazy?  It did to me as well, until I came across 
http://www.catch22.net/tuts/selfdel.asp, which documents the approach.  It's 
not particularly necessary in our case, we could simply spawn another python 
process at the end of regrtest.py that patiently attempts to remove the test 
directory we just used when the python process that was executing regrtest.py 
exits.

We could then modify regrtest.py such that it will use the same approach if the 
hashed test directory already exists at the start of a run and it can't remove 
it via os.unlink.  If we *still* run into issues here on the buildbots, say if 
regrtest.py blocks on our helper process, which for the life of it can't remove 
some/all of the test files -- it'd be interesting to write something that 
grok's all open handles for all processes and attempts to figure out what it is 
that keeps these files open -- i.e. same thing that procexp.exe does when you 
search for a handle.

Or, keeping it simple, rather than a separate process and hashed test directory 
based on python process path, just have a common directory, i.e. 
%TEMP%\python-regrtest, and use an incrementing sequence number for each test 
run's test directory, i.e. if there are directories 001, 002 and 003 in the 
temp dir, when regrtest.py starts, it'll try delete all of these -- if it can't 
(which is what we'd want if another test is already running), it adds 1 to the 
highest numbered directory it couldn't delete.

Guess it all depends on how much effort we want to put into cleaning up our 
test directory really -- just ensuring tests get a clean area and unique file 
names each run is the easy part.

Trent.


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tim Golden [EMAIL 
PROTECTED]
Sent: 03 April 2008 09:39
To: Python-Dev
Subject: Re: [Python-Dev] fixing tests on windows

[re tests which fail because something's holding a file
open with SHARE_DELETE]

Well I've tried my best, but I can't come up with a solution
which guarantees to overcome this obstacle. I set up a fairly
aggressive directory watcher which, when it sees a test file
being created, takes a SHARE_DELETE handle on it and releases
it immediately. (Guessing that this is what the other apps
are doing).

Running the test suite from HEAD, this generates all manner
of access-denied type errors as per the original output.

I used tempfile to generate a random TESTFN in the current directory
rather than the static @test. And implemented the rename-shim
discussed previously, renaming to a different random name, courtesy
of mktemp. With those in place, most tests run without error. But
I'm still getting errors in the same sort of areas which Steven B
originally reported.

The one error I can't see a way round is the access denied (which
manifests as Permission Error) which is the documented result of
attempting to open a file with a pending delete -- ie the delete
succeeded but hasn't completed yet.

An additional complication is that there are hundreds of
instances throughout the tests where the test simply calls
os.unlink/os.remove to undo the test file. To have some more
robust central deletion I had to go through and update 68 tests.

I'll keep trying, but in the current state I'm not convinced
the situation's improved enough for me to bother uploading
a patch.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m

Re: [Python-Dev] xmlrpclib and dates before 1900

[Guido van Rossum]

On Thu, Apr 3, 2008 at 12:29 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> yes, you're right. but I didn't feel like writing a strftime implementation
> (which has probably even less chance of being committed). This patch is
> rather tiny, it's easy to understand and it works now.

Thinking about it more, given the slim chances that we'll reimplement
strftime, I think it's okay to fix this for xmlrpc specifically.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xmlrpclib and dates before 1900

[Guido van Rossum]

On Thu, Apr 3, 2008 at 12:34 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> Have you considered using the pure python datetime implementation from the
> pypy project for py3k?

I wouldn't dream of it. datetime is considered performance critical by many.

> It's even based on your own code :)

Which was meant as a prototype only.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our cause

[Trent Nelson]

Committed new version of kill_python to trunk in r62129.

   Trent.

From: "Martin v. Löwis" [EMAIL PROTECTED]
Sent: 02 April 2008 14:39
To: Trent Nelson
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Tools\buildbot\kill_python.c can't be helping our 
cause

> That'll kill the first python_d.exe instance it finds matching the
> given path; given that our buildbots run trunk/release25-maint/py3k
> in parallel

That's actually not a given: we currently *don't* run multiple builds
simultaneously on the same slave.

> Unless anyone advises otherwise, I'll start on a patch.

If you can make it less error-prone, sure, go ahead.

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] fixing tests on windows

[Terry Reedy]

"Tim Golden" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| [re tests which fail because something's holding a file
| open with SHARE_DELETE]

There are a couple of things one can do in a directory's Properties box 
(right click) to reduce interference.
1. Under General/Advanced, uncheck 'allow Indexing Service' and click Yes 
to recursively apply to subdirs and files.
2. Under Sharing, check 'Make private'.  This is recursive, but only works 
for dirs under My Documents or on Desktop.  This would be most useful, I 
think, if buildbots run as a separate user.
Have these already been done?

tjr



___
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] socket.SOL_REUSEADDR: different semantics between Windows vs Unix (or why test_asynchat is sometimes dying on Windows)

[Trent Nelson]

I started looking into this:

http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/289/step-test/0

Pertinent part:

test_asyncore

test_asynchat

command timed out: 1200 seconds without output
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1
remoteFailed: [Failure instance: Traceback from remote host -- Traceback (most 
recent call last):
Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
]

I tried to replicate it on the buildbot in order to debug, which, surprisingly, 
I could do consistently by just running rt.bat -q -d -uall test_asynchat.  As 
the log above indicates, the python process becomes completely and utterly 
wedged, to the point that I can't even attach a remote debugger and step into 
it.

Digging further, I noticed that if I ran the following code in two different 
python consoles, EADDRINUSE was *NOT* being raised by socket.bind():

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 54322))

However, take out the setsockopt line, and wallah, the second s.bind() will 
raise EADDRINUSE, as expected.  This manifests into a really bizarre issue with 
test_asynchat in particualr, as subsequent sock.accept() calls on the socket 
put python into the uber wedged state (can't even ctrl-c out at the console, 
need to kill the process directly).

Have to leave the office and head home so I don't have any more time to look at 
it tonight -- just wanted to post here for others to mull over.

Trent.
___
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] fixing tests on windows

[Steven Bethard]

On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>  "Tim Golden" <[EMAIL PROTECTED]> wrote in message
>  news:[EMAIL PROTECTED]
>
> | [re tests which fail because something's holding a file
>  | open with SHARE_DELETE]
>
>  There are a couple of things one can do in a directory's Properties box
>  (right click) to reduce interference.
>  1. Under General/Advanced, uncheck 'allow Indexing Service' and click Yes
>  to recursively apply to subdirs and files.
>  2. Under Sharing, check 'Make private'.  This is recursive, but only works
>  for dirs under My Documents or on Desktop.  This would be most useful, I
>  think, if buildbots run as a separate user.
>  Have these already been done?

We already know how to stop the errors from arising by modifying the
Windows environment. In my particular case, it was sufficient to
disable Windows Search Service and the TortoiseSVN Image Overlays.
However, it would be *really* nice if the Python test suite just
worked out of the box, and you didn't have to change your normal
Windows environment.

Or were you suggesting that there is some programmatic way for the
test suite to create directories that disallow the Search Service,
etc.?

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
 --- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] fixing tests on windows

[Tim Golden]

Terry Reedy wrote:
> "Tim Golden" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> | [re tests which fail because something's holding a file
> | open with SHARE_DELETE]
> 
> There are a couple of things one can do in a directory's Properties box 
> (right click) to reduce interference.
> 1. Under General/Advanced, uncheck 'allow Indexing Service' and click Yes 
> to recursively apply to subdirs and files.
> 2. Under Sharing, check 'Make private'.  This is recursive, but only works 
> for dirs under My Documents or on Desktop.  This would be most useful, I 
> think, if buildbots run as a separate user.
> Have these already been done?

I realise that there are options on any given machine
to reduce the interference of known applications. (And
I assume that the people who own buildbots are in a
position to do what they can in that direction). I was
working more towards a situation where they wouldn't
have to, where the test suite could confidently be run
without having to allow for artefacts of this type.

Still trying: some new ideas from Trent elsewhere in
this thread which I'll look into tomorrow.

TJG
___
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] fixing tests on windows

[Terry Reedy]

"Steven Bethard" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
| >  "Tim Golden" <[EMAIL PROTECTED]> wrote in message
| >  news:[EMAIL PROTECTED]
| >
| > | [re tests which fail because something's holding a file
| >  | open with SHARE_DELETE]
| >
| >  There are a couple of things one can do in a directory's Properties 
box
| >  (right click) to reduce interference.
| >  1. Under General/Advanced, uncheck 'allow Indexing Service' and click 
Yes
| >  to recursively apply to subdirs and files.
| >  2. Under Sharing, check 'Make private'.  This is recursive, but only 
works
| >  for dirs under My Documents or on Desktop.  This would be most useful, 
I
| >  think, if buildbots run as a separate user.
| >  Have these already been done?
|
| We already know how to stop the errors from arising by modifying the
| Windows environment. In my particular case, it was sufficient to
| disable Windows Search Service and the TortoiseSVN Image Overlays.
| However, it would be *really* nice if the Python test suite just
| worked out of the box, and you didn't have to change your normal
| Windows environment.

If the testdir disallows the search indexer, then there should be no need 
to disable Windows Search Service.  If privatizing the dir kept other 
programs out, then likewise.

| Or were you suggesting that there is some programmatic way for the
| test suite to create directories that disallow the Search Service,
| etc.?

I suspect, but do not know, that the dialog box effects changes through 
user-programmable interfaces.  So while I would start with manual changes 
to see if that solves the problem, I presume there must be a system call 
for changing dir attributes.

tjr



___
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] fixing tests on windows

[Tony Nelson]

At 3:52 PM -0600 4/3/08, Steven Bethard wrote:
>On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
 ...
>Or were you suggesting that there is some programmatic way for the
>test suite to create directories that disallow the Search Service,
>etc.?

I'd think that files and directories created in the TEMP directory would
normally not be indexed on any OS, including MSWindows.  But this is just a
guess.
-- 

TonyN.:'   
  '  
___
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] RELEASED Python 2.6a2 and 3.0a4

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team and the Python community, I'm  
happy to announce the second alpha release of Python 2.6, and the  
fourth alpha release of Python 3.0.

Please note that these are alpha releases, and as such are not  
suitable for production environments.  We continue to strive for a  
high degree of quality, but there are still some known problems and  
the feature sets have not been finalized.  These alphas are being  
released to solicit feedback and hopefully discover bugs, as well as  
allowing you to determine how changes in 2.6 and 3.0 might impact  
you.  If you find things broken or incorrect, please submit a bug  
report at

http://bugs.python.org

For more information and downloadable distributions, see the Python  
2.6 web
site:

http://www.python.org/download/releases/2.6/

and the Python 3.0 web site:

http://www.python.org/download/releases/3.0/

We are planning one more alpha release of each version, followed by  
two beta releases, with the final releases planned for August 2008.   
See PEP 361 for release details:

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

Enjoy,
- -Barry

Barry Warsaw
[EMAIL PROTECTED]
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR/WImHEjvBPtnXfVAQJmoQP+MzqNDI+Xt8zua/FE7Ca4TVXoIIy2uoOm
I1i3+vmevZ9vtAb9hcGwfEgPY4LSwb9Js4KnJJWMPaMuFJK4NgGoiMdj+t42zDbQ
bEzfBUOCoVkejLRxIQnWeJf1Hu8JocYyCHIRffv57/QdKpHuiSs8aE8GIT3STo3o
I88H5NY1GgI=
=WT2z
-END PGP 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] xmlrpclib and dates before 1900

[skip]

Guido> Thinking about it more, given the slim chances that we'll
Guido> reimplement strftime, I think it's okay to fix this for xmlrpc
Guido> specifically.

Is there some reason we can't incorporate a suitable open source
implementation of strftime into the Python core?  Here's one example that
might provide a suitable starting point (BSD 4.4, then Tcl, then Apple
heritage):


http://www.opensource.apple.com/darwinsource/WWDC2003/tcl-10/tcl/compat/strftime.c

It would probably need some tweaks for Windows, and some changes to the
macro usage.  Then there is the 1900 base year issue.  I'm certainly no
licensing expert, but it seems like we should be able to redistribute it.

Skip
___
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] xmlrpclib and dates before 1900

[Guido van Rossum]

Someone else will have to do a thorough code review. Last time we got
something off the web it turned out to be awful (the float formatting
code -- I'm still reeling from that one).

On Thu, Apr 3, 2008 at 8:48 PM,  <[EMAIL PROTECTED]> wrote:
>
> Guido> Thinking about it more, given the slim chances that we'll
> Guido> reimplement strftime, I think it's okay to fix this for xmlrpc
> Guido> specifically.
>
>  Is there some reason we can't incorporate a suitable open source
>  implementation of strftime into the Python core?  Here's one example that
>  might provide a suitable starting point (BSD 4.4, then Tcl, then Apple
>  heritage):
>
> 
> http://www.opensource.apple.com/darwinsource/WWDC2003/tcl-10/tcl/compat/strftime.c
>
>  It would probably need some tweaks for Windows, and some changes to the
>  macro usage.  Then there is the 1900 base year issue.  I'm certainly no
>  licensing expert, but it seems like we should be able to redistribute it.
>
>  Skip
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xmlrpclib and dates before 1900

[James Y Knight]

On Apr 2, 2008, at 11:52 PM, Guido van Rossum wrote:
> I'd like to see this fixed if possible, but I'm not sure how -- the C
> level 'struct tm' has (year - 1900) in the tm_year member, and I'm not
> sure that implementations are required to do anything with negative
> values there. We'd have to reimplement all of strftime ourselves. I'm
> not against that, but there are higher priorities.

At least on linux, negative values work great. I have no idea if  
that's required by the spec or not. Someone would have to test on  
other platforms I guess...

James

___
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] xmlrpclib and dates before 1900

[skip]

Guido> Someone else will have to do a thorough code review. Last time we
Guido> got something off the web it turned out to be awful (the float
Guido> formatting code -- I'm still reeling from that one).

This isn't some oddball weekend project from an out-of-work programmer.
It's derived from BSD 4.4 and then looks like Tcl absorbed it as their
implementation of strftime.  The version I posted looks like it's part of
Darwin.  Should be fairly well wrung out.  I downloaded it and with a couple
mods I was able to use it as a substitute for strftime() in timemodule.c.
It compiles cleanly and seems to pass all tests.

My thought would be to only use this for Python 3.0.

Skip
___
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] [Distutils] Wow, I think I actually *get* it now!

[phil jones]

Just a thought. What I'd really like to see is a quick 5 / 10 minute
screen-cast of using setup tools. I've been looking for one for a
couple of weeks but haven't found,

Something like this buildout example, perhaps :

http://video.google.com/videoplay?docid=3428163188647461098&total=7&start=0&num=10&so=0&type=search&plindex=0

cheers

phil jones

On Thu, Mar 20, 2008 at 8:12 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 20/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>  >  Actually, this information is VERY helpful.  It makes it blindingly
>  >  obvious to me now that the difference between loving and hating
>  >  setuptools is whether you're *intentionally* using it, or whether it
>  >  shows up in your ecosystem uninvited.
>
>  Exactly. I never thought to express that, but it precisely explains my
>  situation as well.
>
>
>  >  Hm.  So it seems to me that maybe one thing that would help is a
>  >  "Setuptools Haters' Guide To Setuptools" -- that is, *short*
>  >  documentation specifically written for people who don't want to use
>  >  setuptools and want to minimize its impact on their systems.  I could
>  >  probably write something like that fairly easily, now that I have
>  >  some idea of what to go in it, more than, "the existing documentation
>  >  sucks".  :)
>  >
>  >  Can I count on some non-assimilated persons' help in critiquing such
>  >  a document and suggesting any topics I miss?
>
>  I would do so. (From a Windows user's perspective).
>
>  Paul.
>
>
> ___
>  Distutils-SIG maillist  -  [EMAIL PROTECTED]
>  http://mail.python.org/mailman/listinfo/distutils-sig
>
___
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] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Stephen Waterbury]

Phillip J. Eby wrote:
> ... if tools exist and are distributed for such a [PEP 262] "database", 
> and *everybody* agrees to use it as an officially-blessed standard, 
> then it should be possible for setuptools to co-exist with that 
> framework, and we're all happy campers.

I like this idea and the 3 items proposed to accomplish it.

> 2. Update or replace the implementation as appropriate  ...

After some googling and digging around, I found:



Is that what you meant by "the implementation"?

> Questions, comments...  volunteers?   :)

I'll try to help, if this is agreed to and if I'm able.

Steve
___
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] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Brian Sutherland]

On Sat, Mar 22, 2008 at 02:31:34AM +0100, "Martin v. L?wis" wrote:
> > Tools which will need this data, in order to do their work.  Hence, 
> > the reason for standardizing the data, instead of the tool(s).
> 
> If there was a chance that the infrastructure being developed
> actually helps these tools, *that* would be a reasonable goal,
> IMO.
> 
> However, I'm extremely skeptical that this can ever succeed
> to the degree that whoever provides RPMs, .debs, or MSI
> files will actually use such data, as they will find that
> the data are incomplete, and they have to redo all of it,
> anyway.

I've found it extremely useful to have access to dependency information
when making Debian packages automagically out of setuptools tarballs.

It's not easy or robust to access/use it, but for my simple pure python
packages, it's been working wonderfully. 

-- 
Brian Sutherland
___
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] [Distutils] How we can get rid of eggs for 2.6 and beyond

[Jeff Younker]

On Mar 24, 2008, at 3:26 PM, Tres Seaver wrote:

> Sharing the system python is hugely problematic on a unix box which
> actually *uses* python for its own tools:  the application is not  
> "safe"
> from additions / updates / removeals of the packages in
> /usr/lib/python2.x/site-packages done to support those system tools.
> The problem gets worse as multiple non-system applications install  
> files
> there:  e.g., the 'twisted' package on Debian boxes depends on an
> ancient version of 'zope.interface', which can't be used with any
> currently supported version of Zope.

This is why versioning would be an useful solution.  Each package
would use the dependent packages that it requires.  Foo 1.0 uses
Bar 2.3 and Baz 3.2 uses Foo 1.4.  An application can use both Foo 1.0
and Baz 3.2 without having to mediate between their requirements.
While nobody is really requesting versioning, it seems to be the
solution to many problems that plague us.

-jeff
___
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] xmlrpclib and dates before 1900

[skip]

> I downloaded it and with a couple mods I was able to use it as a
> substitute for strftime() in timemodule.c.  It compiles cleanly and seems
> to pass all tests.

I misspoke.  test_strptime fails with timezone issues.  That's probably just
my misunderstanding of how Python deals with timezones.  I make a quick
replacement of Tcl's tzname stuff to get it to compile, but the test fails.
It would probably not be much work for someone who understands how the
Python datetime/time code handles timezone names.

Skip

___
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] Annotations support in python

[Neal Norwitz]

The release schedule for 2.6/3.0 is http://www.python.org/dev/peps/pep-0361/
3.0 will have the feature, 2.6 may or may not.

n

On Thu, Apr 3, 2008 at 4:47 AM, Heshan Suriyaarachchi
<[EMAIL PROTECTED]> wrote:
>  Hi,
>  I need to work with annotations as it is said in [1]. Currently I am
> using python 2.5.1. I would like to know whether the
> next release of python will support this feature. If the next version
> support this feature I would like to know when are you
>  planning to release it. I used the __future__ module but I could not get
> the annotations with it.
>
> [1] -  http://www.python.org/dev/peps/pep-3107/
>
> Thanx
> Heshan Suriyaarachchi
>
>
>
> ___
>  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/nnorwitz%40gmail.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