Re: [Python-Dev] [Python-3000] stdlib reorganization

[Talin]

A.M. Kuchling wrote:
> On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote:
> 
>>That sounds about reasonable.  One possible grouping:
> 
> 
> Note that 2.5's library reference has a different chapter organization
> from 2.4's.  See .

I like it. Its a much cleaner organization than the 2.4 libs. I would 
like to see it used as a starting point for a reorg of the standard lib 
namespace.

One question that is raised is whether the categories should map 
directly to package names in all cases. For example, I can envision a 
desire that 'sys' would stay a top-level name, rather than 'rt.sys'. 
Certain modules are so fundamental that they deserve IMHO to live in the 
root namespace.

-- Talin
___
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] optparse and unicode

[Ronald Oussoren]

On 30-mei-2006, at 22:32, Tom Cato Amundsen wrote:

> optparse
> 
>
> Using unicode strings with non-ascii chars.[1]
>
> I'm working around this by subclassing OptionParser. Below is a
> workaround I use in GNU Solfege. Should something like this be
> included in python 2.5?

Could you please file a bug or feature request for this on SF? Your  
report might get lost otherwise.

Ronald

___
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] Segmentation fault of Python if build on Solaris 9 or 10 with Sun Studio 11

[Guido van Rossum]

On 5/30/06, Andreas Flöter <[EMAIL PROTECTED]> wrote:
> I have filed a bug report "Building Python 2.4.3 on Solaris 9/10 with Sun
> Studio 11" 1496561 in the Python tracker. The problem I have encountered is,
> that some of the unit tests of the application roundup fail with Python
> producing a segmentation fault and dumping core, if Python was build with Sun
> Studio 11 (Sun C 5.8). In fact not only some of the unit tests fail, but also
> the application roundup at certain steps.
>
> If gcc is used, everything works fine. As Richard Jones suggests, it might be
> a problem in the anydbm module. I would rather prefer to use the native
> compiler of a platform. To name only two reason, distributing the application
> is easier (dynamic library dependencies are most likely met on the target
> system) and Sun is maintaining the reference native libraries.

On the other hand, there is the fact that the binaries produced by the
Sun compiler segfault... :-)

-- 
--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] Socket module corner cases

[Andrew McNamara]

>After a little more investigation here, it appears that getfqdn() returns
>the name unchanged (or perhaps run through the system's resolver libs) if
>there's no reverse DNS PTR entry. In the case given above,
>otherbox.mydomain.com didn't have a reverse DNS entry, so getfqdn()
>returned 'OTHERBOX'. However, when getfqdn() is called with a name whose
>IP *does* have a PTR record, it returns the correct FQDN.

That sounds entirely plausible.

Many of these name resolver functions pre-date DNS, and show their
/etc/hosts heritage somewhat (gethostbyaddr returning ip, names and
aliases in one hit is a classic example - this isn't easy with DNS).

>Thanks for the help. Now, couple more questions:
>
>getnameinfo() accepts the NI_NAMEREQD flag. It appears, though that a name
>lookup (and associated error if the lookup fails) occurs independent of
>whether the flag is specified. Does it actually do anything?
>
>Does getnameinfo() support IPv6? It appears to fail (with a socket.error
>that says "sockaddr resolved to multiple addresses") if both IPv4 and IPv6
>are enabled.

Someone more knowledgeable will have to answer these.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
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] optparse and unicode

[Tom Cato Amundsen]

optparse


Using unicode strings with non-ascii chars.[1]

I'm working around this by subclassing OptionParser. Below is a
workaround I use in GNU Solfege. Should something like this be
included in python 2.5?

(Please CC me any answer.)

Tom Cato

--- orig/src/mainwin.py
+++ mod/src/mainwin.py
@@ -30,7 +30,13 @@
 
 import optparse
 
-opt_parser = optparse.OptionParser()
+class MyOptionParser(optparse.OptionParser):
+def print_help(self, file=None):
+if file is None:
+file = sys.stdout
+file.write(self.format_help().encode(file.encoding, 'replace'))
+
+opt_parser = MyOptionParser()
 opt_parser.add_option('-v', '--version', action='store_true', dest='version')
 opt_parser.add_option('-w', '--warranty', action='store_true', dest='warranty',
 help=_('Show warranty and copyright.'))

[1]

Traceback (most recent call last):
  File "./solfege.py", line 43, in ?
import src.mainwin
  File "/home/tom/src/solfege-mcnv/src/mainwin.py", line 70, in ?
options, args = opt_parser.parse_args()
  File "/usr/lib/python2.3/optparse.py", line 1129, in parse_args
stop = self._process_args(largs, rargs, values)
  File "/usr/lib/python2.3/optparse.py", line 1169, in _process_args
self._process_long_opt(rargs, values)
  File "/usr/lib/python2.3/optparse.py", line 1244, in _process_long_opt
option.process(opt, value, values, self)
  File "/usr/lib/python2.3/optparse.py", line 611, in process
return self.take_action(
  File "/usr/lib/python2.3/optparse.py", line 632, in take_action
parser.print_help()
  File "/usr/lib/python2.3/optparse.py", line 1370, in print_help
file.write(self.format_help())
UnicodeEncodeError: 'ascii' codec can't encode characters in position 200-202: 
ordinal not in range(128)
-- 
Tom Cato Amundsen <[EMAIL PROTECTED]> http://www.solfege.org/
GNU Solfege - free ear traininghttp://www.gnu.org/software/solfege/
___
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] Segmentation fault of Python if build on Solaris 9 or 10 with Sun Studio 11

[Andreas Flöter]

I have filed a bug report "Building Python 2.4.3 on Solaris 9/10 with Sun 
Studio 11" 1496561 in the Python tracker. The problem I have encountered is, 
that some of the unit tests of the application roundup fail with Python 
producing a segmentation fault and dumping core, if Python was build with Sun 
Studio 11 (Sun C 5.8). In fact not only some of the unit tests fail, but also 
the application roundup at certain steps. 

If gcc is used, everything works fine. As Richard Jones suggests, it might be 
a problem in the anydbm module. I would rather prefer to use the native 
compiler of a platform. To name only two reason, distributing the application 
is easier (dynamic library dependencies are most likely met on the target 
system) and Sun is maintaining the reference native libraries.

Help would be appreciated, thanks
Andreas
___
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] 2.5a2 try/except slow-down: Convert to type?

[Sean Reifschneider]

Changes have been checked into the trunk for converting exceptions to types
instead of classes.  According to pybench, 2.5a2 was 60% slower at
raising exceptions than 2.4.3, and now trunk is 30% faster than 2.4.3.
Yay!

Thanks,
Sean
-- 
 "I was on IRC once and got mistaken for Dan Bernstein. I still have
 nightmares."  -- Donnie Barnes
Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

___
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] Need for Speed Sprint status

[Sean Reifschneider]

On Fri, May 26, 2006 at 09:51:55PM -0700, Neal Norwitz wrote:
>I just hope to hell you're done, because I can't keep up! :-)

Yeah, sucks to be you.  :-)

>It would help me enormously if someone could summarize the status and
>everything that went on.  These are the things that would help me the
>most.

I'm hoping that before we break tonight, that we can do an overview of the
changes, and make sure that everything is on the Wiki pages that Raymond
pointed to.

I've also been writing reports of activity on my work blog at
http://www.tummy.com/journals/users/jafo/

Thanks,
Sean
-- 
 Unix actually IS user friendly -- it's just very picky about whom it
 calls its friend.
Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

___
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] Socket module corner cases

[Bruce Christensen]

> > * getfqdn(): The function seems to not always return the FQDN. For 
> >example, if I run the following code from 'mybox.mydomain.com', I get

> >strange output. Does getfqdn() remove the common domain between my 
> >hostname and the one that I'm looking up?
>  socket.getfqdn('otherbox')
> >'OTHERBOX'
> ># expected 'otherbox.mydomain.com'
> 
> getfqdn() calls the system library gethostbyaddr(), and searches the
> result for the first name that contains '.' or if no name contains
dot, it
> returns the canonical name (as defined by gethostbyaddr() and the
system
> host name resolver libraries (hosts file, DNS, NMB)).

After a little more investigation here, it appears that getfqdn()
returns the
name unchanged (or perhaps run through the system's resolver libs) if
there's no reverse DNS PTR entry. In the case given above,
otherbox.mydomain.com didn't have a reverse DNS entry, so getfqdn()
returned
'OTHERBOX'. However, when getfqdn() is called with a name whose IP
*does*
have a PTR record, it returns the correct FQDN.

Thanks for the help. Now, couple more questions:

getnameinfo() accepts the NI_NAMEREQD flag. It appears, though that a
name
lookup (and associated error if the lookup fails) occurs independent of
whether the flag is specified. Does it actually do anything?

Does getnameinfo() support IPv6? It appears to fail (with a socket.error
that says "sockaddr resolved to multiple addresses") if both IPv4 and
IPv6
are enabled.

--Bruce
___
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] Let's stop eating exceptions in dict lookup

[Martin Blais]

On 5/29/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>  If it is really 0.5%, then we're fine.  Just remember that PyStone is an
> amazingly uninformative and crappy benchmark.

I'm still looking for a benchmark that is not amazingly uninformative
and crappy.  I've been looking around all day, I even looked under the
bed, I cannot find it.  I've also been looking around all day as well,
even looked for it shooting out of the Iceland geysirs, of all
places--it's always all day out here it seems, day and day-- and I
still can't find it.  (In the process however, I found Thule beer and
strangely dressed vikings, which makes it all worthwhile.)

cheers,
___
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] Converting crc32 functions to use unsigned

[Tim Peters]

[Bob Ippolito]
> It seems that we should convert the crc32 functions in binascii,
> zlib, etc. to deal with unsigned integers. Currently it seems that 32-
> bit and 64-bit platforms are going to have different results for
> these functions.

binascii.crc32 very deliberately intends to return the same signed
integer values on all platforms.  That's what this section at the end
is trying to do:

#if SIZEOF_LONG > 4
/* Extend the sign bit.  This is one way to ensure the result is the
 * same across platforms.  The other way would be to return an
 * unbounded unsigned long, but the evidence suggests that lots of
 * code outside this treats the result as if it were a signed 4-byte
 * integer.
 */
result |= -(result & (1L << 31));
#endif
return PyInt_FromLong(result);

I wouldn't try to fight that, unless that code is buggy (it looks
correct to me).  I don't remember "the evidence" now, but Barry & I
found "lots of code" relying on it at the time ;-)

> Should we do the same as the struct module, and do DeprecationWarning
> when the input value is < 0?

If the _result_ is going to change from sometimes-negative to
always-positive, then FutureWarning is most appropriate.

> ...
> None of the unit tests seem to exercise values where 32-bit and 64-
> bit platforms would have differing results, but that's easy enough to
> fix...

As above, it shouldn't be possible to concoct a case where
binascii.crc32's result differ across boxes.  That function also
intends to treat negative inputs the same way across boxes.
___
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] Socket module corner cases

[Andrew McNamara]

>Without further ado, the questions:
>
> * getfqdn(): The module docs specify that if no FQDN can be found,
>socket.getfqdn() should return the hostname as returned by
>gethostname(). However, CPython seems to return the passed-in hostname
>rather than the local machine's hostname (as would be expected from
>gethostname()). What's the correct behavior?
 s.getfqdn(' asdlfk asdfsadf ')
>'asdlfk asdfsadf'
># expected 'mybox.mydomain.com'

I would suggest the documentation is wrong and the CPython code is right
in this case: if you supply the optional /name/ argument, then you don't
want it returning your own name (but returning gethostname() is desirable
if no /name/ is supplied).

> * getfqdn(): The function seems to not always return the FQDN. For
>example, if I run the following code from 'mybox.mydomain.com', I get
>strange output. Does getfqdn() remove the common domain between my
>hostname and the one that I'm looking up?
 socket.getfqdn('otherbox')
>'OTHERBOX'
># expected 'otherbox.mydomain.com'

getfqdn() calls the system library gethostbyaddr(), and searches the
result for the first name that contains '.' or if no name contains dot,
it returns the canonical name (as defined by gethostbyaddr() and the
system host name resolver libraries (hosts file, DNS, NMB)).

> * getprotobyname(): Only a few protocols seem to be supported. Why?
 for p in [a[8:] for a in dir(socket) if a.startswith('IPPROTO_')]:
>... try:
>... print p,
>... print socket.getprotobyname(p)
>... except socket.error:
>... print "(not handled)"
>...

getprotobyname() looks up the /etc/protocols file (on a unix system -
I don't know about windows), whereas the socket.IPPROTO_* constants are
populated from the #defines in netinet/in.h at compile time. 

Personally, I think /etc/protocols and the associated library functions
are a historical mistake (getprotobynumber() is marginally useful -
but python doesn't expose it!).

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] stdlib reorganization

[Brett Cannon]

On 5/30/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote:> That sounds about reasonable.  One possible grouping:Note that 2.5's library reference has a different chapter organizationfrom 2.4's.  See <
http://docs.python.org/dev/lib/lib.html>.That's better.  Here are my issues with it:I don't know if I like 'data types' containing stuff like datetime which provide information rather than help deal with data.  And other stuff like sched don't seem to really have anything to do with data directly.
I think pdb and profile can be moved to developer tools.I realize that the misc. category is there just to have a place to stick 'formatter' since it doesn't need its own root-level spot, but I think in terms of a package I don't like the idea of a misc package.
-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] [Python-3000] stdlib reorganization

[A.M. Kuchling]

On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote:
> That sounds about reasonable.  One possible grouping:

Note that 2.5's library reference has a different chapter organization
from 2.4's.  See .

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] stdlib reorganization

[Brett Cannon]

On 5/30/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
[Steven Bethard]> I think that having a package level that exactly matches the divisions> in the Library Reference (http://docs.python.org/lib/lib.html) would
> be great.[Brett Cannon]> Makes sense to me.>[snip]> > 5. Miscellaneous Services>> I don't think we necessarily want a misc package.  Should stuff that falls> into here just be at the root level? Besides, some stuff, such as heapq,
> bisect, collections, and the User* modules could got into a data structure> package.  I also think that a testing package would make sense.  Could also> have a math package.That sounds about reasonable.  One possible grouping:
Testing Stuff:* 5.2 doctest -- Test interactive Python examples* 5.3 unittest -- Unit testing framework* 5.4 test -- Regression tests package for Python* 5.5 test.test_support -- Utility functions for tests
Yep, what I was thinking but possibly renaming 'test' to another naming or putting its functions at the package top level.
Math/Numeric Stuff:* 5.6 decimal -- Decimal floating point arithmetic* 5.7 math -- Mathematical functions* 5.8 cmath -- Mathematical functions for complex numbers* 5.9 random -- Generate pseudo-random numbers
* 5.10 whrandom -- Pseudo-random number generatorData Structures/Collections Stuff:* 5.11 bisect -- Array bisection algorithm* 5.12 collections -- High-performance container datatypes* 
5.13 heapq -- Heap queue algorithm* 5.14 array -- Efficient arrays of numeric values* 5.15 sets -- Unordered collections of unique elements* 5.16 itertools -- Functions creating iterators for efficient looping
Stuff I still don't know what to do with:* 5.1 pydoc -- Documentation generator and online help system* 5.17 ConfigParser -- Configuration file parser* 5.18 fileinput -- Iterate over lines from multiple input streams
* 5.19 calendar -- General calendar-related functions* 5.20 cmd -- Support for line-oriented command interpreters* 5.21 shlex -- Simple lexical analysisThere are just going to be some things that are odd.  Those will probably just have to sit at the top-level with no place to stick them so that they get proper visibility rather than sticking them in misc, forcing people to hunt in there every time they can't find a specific module that does what they want.
 > > 8. Unix Specific Services> > 9. The Python Debugger> > 10. The Python Profiler
>> Can't the pdb and profiling going into a developer package?I thought the same thing when I copied the list over the first time.Well, there you go then.  It's just *that* good of an idea.  =)
-Brett Steve--Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy___Python-Dev mailing listPython-Dev@python.org
http://mail.python.org/mailman/listinfo/python-devUnsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org

___
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 buildbots

[martin]

Zitat von Neal Norwitz <[EMAIL PROTECTED]>:

> I've been starting to get some of the buildbots working again.  There
> was some massive problem on May 25 where a ton of extra files were
> left around.  I can't remember if I saw something about that at the
> NFS sprint or not.

You can clean each buildbot remotely by forcing a build on a
(non-existing) branch. That removes the build tree, and then
tries to build the branch (which fails if the branch doesn't
exist). The next build will then start with a fresh checkout
of the trunk.

> There is a lingering problem that I can't fix on all the boxes.  Namely:
>
>   cp Modules/Setup{.dist,}
>
> Should we always do that step before we build on the buildbots?

If so, the easiest way to do it would be to "make distclean" in
the clean step: that removes Modules/Setup as well.

> Any objections?

See above. Rather than copying Modules/Setup over, I'd prefer to
see a distclean.

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] uriparsing library (Patch #1462525)

[Paul Jimenez]

http://sourceforge.net/tracker/index.php?func=detail&aid=1462525&group_id=5470&atid=305470
 

This is just a note to ask when the best time to try and get this in is
- I've seen other new/changed libs going in for 2.5 and wanted to make
sure this didn't fall off the radar. If now's the wrong time, please let
me know when the right time is so I can stick my head up again then.

Thanks,

  --pj


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

Re: [Python-Dev] [Python-3000] stdlib reorganization

[Steven Bethard]

[Steven Bethard]
> I think that having a package level that exactly matches the divisions
> in the Library Reference (http://docs.python.org/lib/lib.html) would
> be great.

[Brett Cannon]
> Makes sense to me.
>
[snip]
> > 5. Miscellaneous Services
>
> I don't think we necessarily want a misc package.  Should stuff that falls
> into here just be at the root level? Besides, some stuff, such as heapq,
> bisect, collections, and the User* modules could got into a data structure
> package.  I also think that a testing package would make sense.  Could also
> have a math package.

That sounds about reasonable.  One possible grouping:

Testing Stuff:
* 5.2 doctest -- Test interactive Python examples
* 5.3 unittest -- Unit testing framework
* 5.4 test -- Regression tests package for Python
* 5.5 test.test_support -- Utility functions for tests

Math/Numeric Stuff:
* 5.6 decimal -- Decimal floating point arithmetic
* 5.7 math -- Mathematical functions
* 5.8 cmath -- Mathematical functions for complex numbers
* 5.9 random -- Generate pseudo-random numbers
* 5.10 whrandom -- Pseudo-random number generator

Data Structures/Collections Stuff:
* 5.11 bisect -- Array bisection algorithm
* 5.12 collections -- High-performance container datatypes
* 5.13 heapq -- Heap queue algorithm
* 5.14 array -- Efficient arrays of numeric values
* 5.15 sets -- Unordered collections of unique elements
* 5.16 itertools -- Functions creating iterators for efficient looping

Stuff I still don't know what to do with:
* 5.1 pydoc -- Documentation generator and online help system
* 5.17 ConfigParser -- Configuration file parser
* 5.18 fileinput -- Iterate over lines from multiple input streams
* 5.19 calendar -- General calendar-related functions
* 5.20 cmd -- Support for line-oriented command interpreters
* 5.21 shlex -- Simple lexical analysis

> > 8. Unix Specific Services
> > 9. The Python Debugger
> > 10. The Python Profiler
>
> Can't the pdb and profiling going into a developer package?

I thought the same thing when I copied the list over the first time.

Steve
-- 
Grammar am for people who can't think for myself.
--- 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 buildbots

[martin]

Zitat von Benji York <[EMAIL PROTECTED]>:

> FWIW, with the buildbots I run, I use "clobber" mode, with which the
> entire build directory is removed and rebuilt on each run.  It slows
> things down a bit, but the results have been more consistent and it's
> easier to administer.

We should not do this. Performing a checkout each time is too expensive.

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] Socket module corner cases

[Bruce Christensen]

Hello,

I'm working on implementing a socket module for IronPython that aims to
be compatible with the standard CPython module documented at
http://docs.python.org/lib/module-socket.html. I have a few questions
about some corner cases that I've found. CPython results below are from
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win32.

Without further ado, the questions:

 * getfqdn(): The module docs specify that if no FQDN can be found,
socket.getfqdn() should return the hostname as returned by
gethostname(). However, CPython seems to return the passed-in hostname
rather than the local machine's hostname (as would be expected from
gethostname()). What's the correct behavior?
>>> s.getfqdn(' asdlfk asdfsadf ')
'asdlfk asdfsadf'
# expected 'mybox.mydomain.com'

 * getfqdn(): The function seems to not always return the FQDN. For
example, if I run the following code from 'mybox.mydomain.com', I get
strange output. Does getfqdn() remove the common domain between my
hostname and the one that I'm looking up?
>>> socket.getfqdn('otherbox')
'OTHERBOX'
# expected 'otherbox.mydomain.com'
 
 * gethostbyname_ex(): The CPython implementation doesn't seem to
respect the '' == INADDR_ANY and '' == INADDR_BROADCAST
forms. '' is treated as localhost, and '' raises a "host not
found" error. Is this intentional? A quick check seems to reveal that
gethostbyname() is the only function that respects '' and ''.
Are the docs or the implementation wrong?

 * getprotobyname(): Only a few protocols seem to be supported. Why?
>>> for p in [a[8:] for a in dir(socket) if a.startswith('IPPROTO_')]:
... try:
... print p,
... print socket.getprotobyname(p)
... except socket.error:
... print "(not handled)"
...
AH (not handled)
DSTOPTS (not handled)
ESP (not handled)
FRAGMENT (not handled)
GGP 3
HOPOPTS (not handled)
ICMP 1
ICMPV6 (not handled)
IDP (not handled)
IGMP (not handled)
IP 0
IPV4 (not handled)
IPV6 (not handled)
MAX (not handled)
ND (not handled)
NONE (not handled)
PUP 12
RAW (not handled)
ROUTING (not handled)
TCP 6
UDP 17

Thanks for your help!

--Bruce

___
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] bug in PEP 318

[Phillip J. Eby]

At 08:56 PM 5/30/2006 +0200, Alexander Bernauer wrote:
>Hi
>
>I found two bugs in example 4 of the PEP 318 [1]. People on #python
>pointed me to this list. So here is my report. Additionally I appended
>an afaics correct implementation for this task.
>
>[1] http://www.python.org/dev/peps/pep-0318/
>
>Bug 1)
>The decorator "accepts" gets the function which is returned by the
>decorator "returns". This is the function "new_f" which is defined
>differently from the function "func". Because the first has an
>argument count of zero, the assertion on line 3 is wrong.

The simplest fix for this would be to require that returns() be used 
*before* accepts().


>Bug 2)
>The assertion on line 6 does not work correctly for tuples. If the
>second argument of "isinstance" is a tuple, the function returns true,
>if the first argument is an instance of either type of the tuple.

This is intentional, to allow saying that the given argument may be (for 
example) an int or a float.  What it doesn't support is nested-tuple 
arguments, but that's a reasonable omission given the examples' nature as 
examples.


> def check(*args, **kwds):
> checktype(args, self.types)
> self.func(*args, **kwds)

This needs a 'return', since it otherwise loses the function's return value.


>To be honest, I didn't understand what the purpose of setting
>"func_name" is, so I left it out.  If its neccessary please feel free to
>correct me.

It's needed for Python documentation tools such as help(), pydoc, and so on 
display something more correct for the decorated function's documentation, 
although also copying the __doc__ attribute would really also be required 
for that.


>In contrast to tuples lists and dictionaries are not inspected. The
>reason is that I don't know how to express: "the function accepts a list
>of 3 or more integers" or alike. Perhaps somebody has an idea for this.

I think perhaps you've mistaken the PEP examples for an attempt to 
implement some kind of typechecking feature.  They are merely examples to 
show an idea of what is possible with decorators, nothing more.  They are 
not even intended for anybody to actually use!


>I wonder, how it can be, that those imho obvious mistakes go into a PEP
>and stay undetected there for almost 3 years.

That's because nobody uses them; a PEP example is not intended or required 
to be a robust production implementation of the idea it sketches.  They are 
proofs-of-concept, not source code for a utility.  If they were intended to 
be used, they would be in a reference library or in the standard library, 
or otherwise offered in executable form.

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

Re: [Python-Dev] [Python-3000] stdlib reorganization

[Brett Cannon]

On 5/30/06, Steven Bethard <
[EMAIL PROTECTED]> wrote:
On 5/30/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> So, first step in my mind is settling if we want to add one more depth to
> the stdlib, and if so, how we want to group (not specific groupings, just
> general guidelines).I think that having a package level that exactly matches the divisionsin the Library Reference (
http://docs.python.org/lib/lib.html
) wouldbe great.  Makes sense to me. 
Currently, that would mean packages for:
3. Python Runtime Services4. String Services5. Miscellaneous ServicesI
don't think we necessarily want a misc package.  Should stuff that
falls into here just be at the root level? Besides, some stuff, such as
heapq, bisect, collections, and the User* modules could got into a data
structure package.  I also think that a testing package would make
sense.  Could also have a math package.
6. Generic Operating System Services7. Optional Operating System Services

This includes socket, which I would think
would belong more in a networking-centric package (not including
web-specific stuff).  Plus I believe a threading/concurrency package
has been proposed before (which included hiding 'thread' so that people
wouldn't use such low-level stuff).
8. Unix Specific Services9. The Python Debugger
10. The Python Profiler
Can't the pdb and profiling going into a developer package? 

11. Internet Protocols and SupportShould xmlrpclib be in here, or in something more in line with RPC and "concurrency"?

12. Internet Data HandlingShould we merge  this with a more generic Internet/Web package?  Have a separate email package that includes 'email', smtp, etc?

13. Structured Markup Processing Tools14. Multimedia Services15. Cryptographic Services16. Graphical User Interfaces with Tk17. Restricted Execution=)  This section's not really valid anymore (although I will be fixing that at some point).
18. Python Language Services19. Python compiler package
20. SGI IRIX Specific Services
21. SunOS Specific Services22. MS Windows Specific Services
___
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] bug in PEP 318

[Alexander Bernauer]

Hi

I found two bugs in example 4 of the PEP 318 [1]. People on #python
pointed me to this list. So here is my report. Additionally I appended
an afaics correct implementation for this task.

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

Bug 1)
The decorator "accepts" gets the function which is returned by the
decorator "returns". This is the function "new_f" which is defined
differently from the function "func". Because the first has an
argument count of zero, the assertion on line 3 is wrong.

Bug 2)
The assertion on line 6 does not work correctly for tuples. If the
second argument of "isinstance" is a tuple, the function returns true,
if the first argument is an instance of either type of the tuple.
Unfortunately the example uses tuples.


Here goes my proposal for this decorators. Feel free to do anything you
like with it.

---8<---
def checktype(o, t): 
   """check if the type of the object "o" is "t" """
# in case of a tuple descend
if isinstance(t, tuple):
assert isinstance(o, tuple), str(type(o))
assert len(o) == len(t), "%d %d" % (len(o), len(t))
for (o2, t2) in zip(o, t):
checktype(o2, t2)

# isinsance(None, None) raises a TypeError. 
# so we need extra handling for this case
elif t == None:  
assert o == None
else:
assert isinstance(o, t), "%s %s" % (str(type(o)), str(t))

class accepts(object):
def __init__(self, *types):
self.types = types

def __call__(self, func):
self.func = func

def check(*args, **kwds):
checktype(args, self.types)
self.func(*args, **kwds)
 
return check

class returns(object):
def __init__(self, *types):
self.types = types

def __call__(self, func):
self.func = func

def check(*args, **kwds):
value = self.func(*args, **kwds)
# if the function returns only on object the single object is no 
tuple
# this extra case results in an extra handling here
if isinstance(value, tuple):
checktype(value, self.types)
else:
checktype((value,), self.types)
return value

return check

--->8---

To be honest, I didn't understand what the purpose of setting
"func_name" is, so I left it out.  If its neccessary please feel free to
correct me.

In contrast to tuples lists and dictionaries are not inspected. The
reason is that I don't know how to express: "the function accepts a list
of 3 or more integers" or alike. Perhaps somebody has an idea for this.

Here are some examples of what is possible:

---8<---
@accepts(int)
@returns(int)
def foo(a):
return a

foo(3)


@accepts(int, (float, int))
@returns(int, str)
def foo(a, b):
return (1, "asdf")

foo(1, (2.0, 1))


@returns(None)
def foo():
pass

foo()


@accepts(int, int)
def foo(a, *args):
pass

foo(3,3)


@accepts(tuple)
@returns(list)
def foo(a):
   return list(a)

foo((1,1))

--->8---

I wonder, how it can be, that those imho obvious mistakes go into a PEP
and stay undetected there for almost 3 years. Perhaps I misunderstood
something completly. In this case, please excuse me and ignore my mail.


The welcome message to this lists asked for introducing myself. Well,
there is nothing special to say about me concerning python. Let's say,
I'm just a fan. 

cu

-- 
Alexander Bernauer
___
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] Converting crc32 functions to use unsigned

[Bob Ippolito]

On May 30, 2006, at 11:19 AM, Guido van Rossum wrote:

> On 5/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>> Bob Ippolito wrote:
>>
>> > It seems that we should convert the crc32 functions in binascii,
>> > zlib, etc. to deal with unsigned integers.
>>
>> +1!!
>
> Seems ok, except I don't know what the backwards incompatibilities  
> would be...
>

I think the only compatibility issues we're going to run into are  
with the struct module in the way of DeprecationWarning. If people  
are depending on specific negative values for these, then their code  
should already be broken on 64-bit platforms. The only potential  
breakage I can see is if they're passing these values to other  
functions written in C that expect PyInt_AsLong(n) to work with the  
values (on 32-bit platforms). I can't think of a use case for that  
beyond the functions themselves and the struct module.

-bob

___
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] Remove METH_OLDARGS?

[Fredrik Lundh]

Georg Brandl wrote:

>> and links to
>>
>> http://msdn2.microsoft.com/en-us/library/c8xdzzhh.aspx
>>
>> which provides a pragma that does the same thing, and is documented to work
>> for both C and C++, and also works for macros.
> 
> But we'd have to use an #ifdef for every deprecated function.

or a pydeprecated.h file with all the relevant functions and macros 
inside single ifdef.




___
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] Remove METH_OLDARGS?

[Georg Brandl]

Fredrik Lundh wrote:
> Georg Brandl wrote:
> 
>> > I'd be satisfied with a deprecation warning for PyArg_Parse, though we
>> > (*) should really figure out how to make it work on Windows.  I
>> > haven't seen anyone object to the C compiler deprecation warning.
>>
>> There is something at
>> http://msdn2.microsoft.com/en-us/library/044swk7y.aspx
>>
>> but it says only "C++".
> 
> and links to
> 
> http://msdn2.microsoft.com/en-us/library/c8xdzzhh.aspx
> 
> which provides a pragma that does the same thing, and is documented to work
> for both C and C++, and also works for macros.

But we'd have to use an #ifdef for every deprecated function.

Of course, there aren't so many of them.

Georg

___
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] Converting crc32 functions to use unsigned

[Guido van Rossum]

Seems ok, except I don't know what the backwards incompatibilities would be...

On 5/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Bob Ippolito wrote:
>
> > It seems that we should convert the crc32 functions in binascii,
> > zlib, etc. to deal with unsigned integers.
>
> +1!!

-- 
--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] fixing buildbots

[Neal Norwitz]

On 5/30/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
>
> > I've been starting to get some of the buildbots working again.  There
> > was some massive problem on May 25 where a ton of extra files were
> > left around.  I can't remember if I saw something about that at the
> > NFS sprint or not.
>
> bob's new _struct module was checked in on May 25, and required some
> changes to the build procedure (structmodule.c was replaced by _struct.c).
>
> I'm not sure why such a relatively straightforward change would break the
> buildbots, though...

It wasn't the buildbots exactly, but rather the test suite not being
robust enough.  There are several tests that create files/directories
on setup and remove them on teardown.  However, if there's some
exception and teardown doesn't do it's job completely, on the next
run, setup will fail.  I fixed one of these in test_repr last night
IIRC.  test_glob I tried to fix with a change to the Makefile to rm -f
areallylong*.  Not sure why the problems didn't appear on Windows.

The tests should really be made more robust.

n
___
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] Converting crc32 functions to use unsigned

[Giovanni Bajo]

Bob Ippolito wrote:

> It seems that we should convert the crc32 functions in binascii,
> zlib, etc. to deal with unsigned integers. 

+1!!
-- 
Giovanni Bajo
___
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] test_gzip/test_tarfile failure om AMD64

[Bob Ippolito]

On May 30, 2006, at 10:47 AM, Tim Peters wrote:

> [Bob Ippolito]
>> What should it be called instead of wrapping?
>
> I don't know -- I don't know what it's trying to _say_ that isn't
> already said by saying that the input is out of bounds for the format
> code.

The wrapping (now overflow masking) warning happens during conversion  
of PyObject* to long or unsigned long. It has no idea what the  
destination packing format is beyond whether it's signed or unsigned.  
If the packing format happens to be the same size as a long, it can't  
possibly trigger a range warning (unless range checks are moved up  
the stack and all of the function signatures and code get changed to  
accommodate that).

>> When it says it's wrapping, it means that it's doing x &= (2 ^ (8  
>> * n)) - 1 to force
>> a number into meeting the expected range.
>
> How is that different from what it does in this case?:
>
 struct.pack(' /Users/bob/src/python/Lib/struct.py:63: DeprecationWarning: 'B' format
> requires 0 <= number <= 255
>  return o.pack(*args)
> '\x00'
>
> That looks like "wrapping" to me too (256 & (2**(8*1)-1)== 0x00), but
> in this case there is no deprecation warning about wrapping.  Because
> of that, I'm afraid you're drawing distinctions that can't make sense
> to users.

When it says "integer wrapping" it means that it's wrapping to fit in  
a long or unsigned long. n in this case is always 4 or 8 depending on  
the platform. The format-specific range check is separate. My  
description wasn't very good in the last email.

>> Reducing it to one warning instead of two is kinda difficult. Is it
>> worth the trouble?
>
> I don't understand.  Every example you gave that showed a wrapping
> warning also showed a "format requires i <= number <= j" warning.  Are
> there cases in which a wrapping warning is given but not a "format
> requires i <= number <= j" warning?  If so, I simply haven't seen one
> (but I haven't tried all possible inputs ;-)).
>
> Since the implementation appears (to judge from the examples) to
> "wrap" in every case in which any warning is given (or are there cases
> in which it doesn't?), I don't understand the point of distinguishing
> between wrapping warnings and  "format requires i <= number <= j"
> warnings either.  The latter are crystal clear.

A latter email in this thread enumerates exactly which circumstances  
should cause two warnings with the current implementation.

-bob

___
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] Let's stop eating exceptions in dict lookup

[Josiah Carlson]

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
> Tim Peters wrote:
> 
>  "abc".count("", 100)
> > 1
>  u"abc".count("", 100)
> > 1
> 
> which is the same as
> 
> >>> "abc"[100:].count("")
> 1
> 
>  "abc".find("", 100)
> > 100
>  u"abc".find("", 100)
> > 100
> >
> > today, although the idea that find() can return an index that doesn't
> > exist in the string is particularly jarring.  Since we also have:
> >
>  "abc".rfind("", 100)
> > 3
>  u"abc".rfind("", 100)
> > 3
> >
> > it's twice as jarring that "searching from the right" finds the target
> > at a _smaller_ index than "searching from the left".
> 
> well, string[pos:pos+len(substring)] == substring is true in both cases.
> 
> would "abc".find("", 100) == 3 be okay?

I would argue no.  Based on my experience with find, I would expect that
find produces values >= start, except when not found, then -1. (note
that I am talking about find and not rfind)


> or should we switch to treating the optional
> start and end positions as "return value boundaries" (used to filter the 
> result) rather than
> "slice directives" (used to process the source string before the operation)?

Return value boundaries seem the more appealing of the two.

 - Josiah

___
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] test_gzip/test_tarfile failure om AMD64

[Tim Peters]

[Bob Ippolito]
> What should it be called instead of wrapping?

I don't know -- I don't know what it's trying to _say_ that isn't
already said by saying that the input is out of bounds for the format
code.

> When it says it's wrapping, it means that it's doing x &= (2 ^ (8 * n)) - 1 
> to force
> a number into meeting the expected range.

How is that different from what it does in this case?:

>>> struct.pack(' Reducing it to one warning instead of two is kinda difficult. Is it
> worth the trouble?

I don't understand.  Every example you gave that showed a wrapping
warning also showed a "format requires i <= number <= j" warning.  Are
there cases in which a wrapping warning is given but not a "format
requires i <= number <= j" warning?  If so, I simply haven't seen one
(but I haven't tried all possible inputs ;-)).

Since the implementation appears (to judge from the examples) to
"wrap" in every case in which any warning is given (or are there cases
in which it doesn't?), I don't understand the point of distinguishing
between wrapping warnings and  "format requires i <= number <= j"
warnings either.  The latter are crystal clear.
___
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] Converting crc32 functions to use unsigned

[Bob Ippolito]

It seems that we should convert the crc32 functions in binascii,  
zlib, etc. to deal with unsigned integers. Currently it seems that 32- 
bit and 64-bit platforms are going to have different results for  
these functions.

Should we do the same as the struct module, and do DeprecationWarning  
when the input value is < 0? Do we have a PyArg_ParseTuple format  
code or a converter that would be suitable for this purpose?

None of the unit tests seem to exercise values where 32-bit and 64- 
bit platforms would have differing results, but that's easy enough to  
fix...

-bob


___
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] test_gzip/test_tarfile failure om AMD64

[Bob Ippolito]

On May 30, 2006, at 2:41 AM, Nick Coghlan wrote:

> Bob Ippolito wrote:
>> On May 29, 2006, at 8:00 PM, Tim Peters wrote:
>>> We certainly don't want to see two deprecation warnings for a single
>>> deprecated behavior.  I suggest eliminating the "struct integer
>>> wrapping" warning, mostly because I had no idea what it _meant_
>>> before reading the comments in _struct.c  ("wrapping" is used most
>>> often in a proxy or delegation context in Python these days).   "'B'
>>> format requires 0 <= number <= 255" is perfectly clear all by  
>>> itself.
>> What should it be called instead of wrapping? When it says it's   
>> wrapping, it means that it's doing x &= (2 ^ (8 * n)) - 1 to force  
>> a  number into meeting the expected range.
>
> "integer overflow masking" perhaps?

Sounds good enough, I'll go ahead and change the wording to that.

>> Reducing it to one warning instead of two is kinda difficult. Is  
>> it  worth the trouble?
>
> If there are cases where only one warning or the other triggers, it  
> doesn't seem worth the effort to try and suppress one of them when  
> they both trigger.

It works kinda like this:

def get_ulong(x):
ulong_mask = (sys.maxint << 1L) | 1
if is_unsigned and ((unsigned)x) > ulong_mask:
x &= ulong_mask
warning('integer overflow masking is deprecated')
return x

def pack_ubyte(x):
x = get_ulong(x)
if not (0 <= x <= 255):
warning("'B' format requires 0 <= number <= 255")
x &= 0xff
return chr(x)

Given the implementation, it will warn twice if sizeof(format) <  
sizeof(long) AND one of the following:
1. Negative numbers are given for an unsigned format
2. Input value is greater than ((sys.maxint << 1) | 1) for an  
unsigned format
3. Input value is not ((-sys.maxint - 1) <= x <= sys.maxint) for a  
signed format

-bob

___
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] Remove METH_OLDARGS?

[Scott Dial]

Neal Norwitz wrote:
> Already done for gcc, see Py_DEPRECATED in pyport.h.  Would be nice if
> someone could add support on Windows.
> 

The manner that macro is used can't be leveraged to work in the VC 
compiler. I admit to not having done an extensive search for the usage 
of Py_DEPRECATED, but to take from object.h:

typedef PyObject *(*intargfunc)(PyObject *, int) Py_DEPRECATED(2.5);

In GCC, you tag on __attribute__((__deprecated__)) but there is no 
equivalent tagging method in VC. In VC, you should instead put a pragma 
for the identifier: #pragma deprecated(intargfunc). AFAIK, you can't put 
a #pragma in a #define, so it seems wise to only mark functions 
deprecated (which you can do via __declspec(deprecated)).

-- 
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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 buildbots

[Benji York]

Neal Norwitz wrote:
 > I can
 > understand why we wouldn't want to unconditionally overwrite a user's
 > modified Setup.  However, for the buildbots, it seems safer to always
 > overwrite it.

FWIW, with the buildbots I run, I use "clobber" mode, with which the
entire build directory is removed and rebuilt on each run.  It slows
things down a bit, but the results have been more consistent and it's 
easier to administer.
--
Benji York
___
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] Integer representation (Was: ssize_t question: longs in header files)

[Fredrik Lundh]

Martin v. Löwis wrote:

>> That's why I'd like my alternative proposal (int as ABC and two
>> subclasses that may remain anonymous to the Python user); it'll save
>> the alignment waste for short ints and will let us use a smaller int
>> type for the size for long ints (if we care about the latter).
>
> I doubt they can remain anonymous. People often dispatch by type
> (e.g. pickle, xmlrpclib, ...), and need to put the type into a
> dictionary. If the type is anonymous, they will do
>
>   dispatch[type(0)] = marshal_int
>   dispatch[type(sys.maxint+1)] = marshal_int

"may remain anonymous" may also mean that type(v) is type(int) for all integers.

but I think isinstance(v, int) should be good enough for Py3K; I really hope all
the talk about typing and multimethods and stuff results in tools that can be 
used
to implement explicit dispatch machineries such as the one in XML-RPC (why
not turn all the marshal methods into a single multimethod?)

 



___
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] Remove METH_OLDARGS?

[Fredrik Lundh]

Georg Brandl wrote:

> > I'd be satisfied with a deprecation warning for PyArg_Parse, though we
> > (*) should really figure out how to make it work on Windows.  I
> > haven't seen anyone object to the C compiler deprecation warning.
>
> There is something at
> http://msdn2.microsoft.com/en-us/library/044swk7y.aspx
>
> but it says only "C++".

and links to

http://msdn2.microsoft.com/en-us/library/c8xdzzhh.aspx

which provides a pragma that does the same thing, and is documented to work
for both C and C++, and also works for macros.

 



___
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 buildbots

[Fredrik Lundh]

Neal Norwitz wrote:

> I've been starting to get some of the buildbots working again.  There
> was some massive problem on May 25 where a ton of extra files were
> left around.  I can't remember if I saw something about that at the
> NFS sprint or not.

bob's new _struct module was checked in on May 25, and required some
changes to the build procedure (structmodule.c was replaced by _struct.c).

I'm not sure why such a relatively straightforward change would break the
buildbots, though...

 



___
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] Let's stop eating exceptions in dict lookup

[Fredrik Lundh]

Tim Peters wrote:

 "abc".count("", 100)
> 1
 u"abc".count("", 100)
> 1

which is the same as

>>> "abc"[100:].count("")
1

 "abc".find("", 100)
> 100
 u"abc".find("", 100)
> 100
>
> today, although the idea that find() can return an index that doesn't
> exist in the string is particularly jarring.  Since we also have:
>
 "abc".rfind("", 100)
> 3
 u"abc".rfind("", 100)
> 3
>
> it's twice as jarring that "searching from the right" finds the target
> at a _smaller_ index than "searching from the left".

well, string[pos:pos+len(substring)] == substring is true in both cases.

would "abc".find("", 100) == 3 be okay?  or should we switch to treating the 
optional
start and end positions as "return value boundaries" (used to filter the 
result) rather than
"slice directives" (used to process the source string before the operation)?  
it's all trivial
to implement, and has no performance implications, but I'm not sure what the 
consensus
really is...

 



___
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] Remove METH_OLDARGS?

[Paul Moore]

On 5/30/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > I'd be satisfied with a deprecation warning for PyArg_Parse, though we
> > (*) should really figure out how to make it work on Windows.  I
> > haven't seen anyone object to the C compiler deprecation warning.
>
> There is something at
> http://msdn2.microsoft.com/en-us/library/044swk7y.aspx
>
> but it says only "C++".

I checked, and it works with C as well. (VC 7.1 toolkit compiler, but
I can't believe it makes a difference...)

Paul.
___
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] test_gzip/test_tarfile failure om AMD64

[Nick Coghlan]

Bob Ippolito wrote:
> On May 29, 2006, at 8:00 PM, Tim Peters wrote:
>> We certainly don't want to see two deprecation warnings for a single
>> deprecated behavior.  I suggest eliminating the "struct integer
>> wrapping" warning, mostly because I had no idea what it _meant_
>> before reading the comments in _struct.c  ("wrapping" is used most
>> often in a proxy or delegation context in Python these days).   "'B'
>> format requires 0 <= number <= 255" is perfectly clear all by itself.
> 
> What should it be called instead of wrapping? When it says it's  
> wrapping, it means that it's doing x &= (2 ^ (8 * n)) - 1 to force a  
> number into meeting the expected range.

"integer overflow masking" perhaps?

> Reducing it to one warning instead of two is kinda difficult. Is it  
> worth the trouble?

If there are cases where only one warning or the other triggers, it doesn't 
seem worth the effort to try and suppress one of them when they both trigger.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] test_gzip/test_tarfile failure om AMD64

[Bob Ippolito]

On May 29, 2006, at 8:00 PM, Tim Peters wrote:

> [Bob Ippolito]
>>> ...
>>> Actually, should this be a FutureWarning or a DeprecationWarning?
>
> Since it was never documented, UndocumentedBugGoingAwayError ;-)
> Short of that, yes, DeprecationWarning.  FutureWarning is for changes
> in non-exceptional behavior (.e.g, if we swapped the meanings of "<"
> and ">" in struct format codes, that would rate a FutureWarning
> subclass, line InsaneFutureWarning).
>
>> OK, this behavior is implemented in revision 46537:
>>
>> (this is from ./python.exe -Wall)
>>
>>  >>> import struct
>
> ...
>
>>  >>> struct.pack('> /Users/bob/src/python/Lib/struct.py:63: DeprecationWarning: struct
>> integer wrapping is deprecated
>>return o.pack(*args)
>> /Users/bob/src/python/Lib/struct.py:63: DeprecationWarning: 'B'
>> format requires 0 <= number <= 255
>>return o.pack(*args)
>> '\xff'
>
> We certainly don't want to see two deprecation warnings for a single
> deprecated behavior.  I suggest eliminating the "struct integer
> wrapping" warning, mostly because I had no idea what it _meant_
> before reading the comments in _struct.c  ("wrapping" is used most
> often in a proxy or delegation context in Python these days).   "'B'
> format requires 0 <= number <= 255" is perfectly clear all by itself.

What should it be called instead of wrapping? When it says it's  
wrapping, it means that it's doing x &= (2 ^ (8 * n)) - 1 to force a  
number into meeting the expected range.

Reducing it to one warning instead of two is kinda difficult. Is it  
worth the trouble?

-bob

___
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] Let's stop eating exceptions in dict lookup

[Armin Rigo]

Hi Fredrik,

On Tue, May 30, 2006 at 07:48:50AM +0200, Fredrik Lundh wrote:
> since "abc".find("", 0) == 0, I would have thought that a program that 
> searched for an empty string in a loop wouldn't get anywhere at all.

Indeed.  And when this bug was found in the program in question, a
natural fix was to add 1 to the start position if the searched string
was empty, which used to ensure that the loop terminates.


A bientot,

Armin
___
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] problem with compilation flags used by distutils

[Toon Knapen]

We are compiling python on a multitude of platforms using a multitude of 
compilers and encountered problems when building python and 
python-extensions when specific flags need to be used by the compiler.

For instance, currently we're building the trunk on a Sun Solaris 9 
machine using Sun Studio 11. To make python compile in 64bit we execute 
the following sequence:


export CC=cc
export CFLAGS="-xarch=v9"
export EXTRA_CFLAGS="-xarch=v9"
export CXX=CC
export CXXFLAGS="-xarch=v9"
export F77=f77
export FFLAGS="-xarch=v9"
export LDFLAGS="-xarch=v9"
./configure


Unless we define 'EXTRA_CFLAGS' (which is not documented in `configure 
--help`) we need to add the "-xarch=v9" command-line option also 
manually to the generated Makefile to make sure python compiles with 
this option.

Next when compiling python-extensions (e.g. numarray) using distutils, 
distutils does not know it needs to pass the "-xarch=v9" option when 
linking a dynamic library. Distutils will still consult the LDFLAGS 
env.var. but IMO it also needs to use the content of LDFLAGS at the time 
python itself was compiled to secure that extensions are built 
compatible with python itself.


toon


___
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] Remove METH_OLDARGS?

[Georg Brandl]

Neal Norwitz wrote:
> On 5/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>
>> > OTOH, perhaps a deprecation warning on PyArgs_Parse() is sufficient?
>> > What about that?  It doesn't address other cases where OLDARGS are
>> > used without PyArgs_Parse though.
>>
>> What other cases remain? People might have complex argument processing
>> procedure not involving PyArg_Parse, these would just break with a
>> runtime error in Py3k. If the module is maintained, it should be easy
>> to fix it. If the module is unmaintained, producing a warning now
>> might not help, either.
> 
> One case would be if the function doesn't take any args, but the args
> aren't checked, just ignored.  Another case I was thinking about was
> PyArg_NoArgs which is a macro, but that just calls PyArg_Parse, so it
> would get flagged.  I can't imagine there would be enough of these
> cases to matter.
> 
> I'd be satisfied with a deprecation warning for PyArg_Parse, though we
> (*) should really figure out how to make it work on Windows.  I
> haven't seen anyone object to the C compiler deprecation warning.

There is something at
http://msdn2.microsoft.com/en-us/library/044swk7y.aspx

but it says only "C++".

Georg

___
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