Re: [Python-Dev] Import semantics
Fabio Zadrozny wrote: > Python and Jython import semantics differ on how sub-packages should be > accessed after importing some module: > > Jython 2.1 on java1.5.0 (JIT: null) > Type "copyright", "credits" or "license" for more information. > >>> import xml > >>> xml.dom > > > Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import xml > >>> xml.dom > Traceback (most recent call last): > File "", line 1, in ? > AttributeError: 'module' object has no attribute 'dom' > >>> from xml.dom import pulldom > >>> xml.dom > > > Note that in Jython importing a module makes all subpackages beneath it > available, whereas in python, only the tokens available in __init__.py > are accessible, but if you do load the module later even if not getting > it directly into the namespace, it gets accessible too -- this seems > more like something unexpected to me -- I would expect it to be > available only if I did some "import xml.dom" at some point. > > My problem is that in Pydev, in static analysis, I would only get the > tokens available for actually imported modules, but that's not true for > Jython, and I'm not sure if the current behaviour in Python was expected. > > So... which would be the right semantics for this? the difference in Jython is deliberate. I think the reason was to mimic more the Java style for this, in java fully qualified names always work. In jython importing the top level packages is enough to get a similar effect. This is unlikely to change for backward compatibility reasons, at least from my POV. > > Thanks, > > Fabio > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
On Sun, 11 Jun 2006, Giovanni Bajo wrote:
> Some comments on the code:
>
> > for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
>
> Can we get rid of these absolute paths? Something like this should suffice:
>
> >>> from ctypes import *
> >>> buf = create_string_buffer(4096)
> >>> windll.kernel32.GetSystemDirectoryA(buf, 4096)
> 17
> >>> buf.value.decode("mbcs")
> u'C:\\WINNT\\system32'
I'd like to, but i don't want to use a method for finding the system
directory that depends on ctypes. Is there a more general way?
> > for function in functions:
> >try:
> >_node = function()
> >except:
> >continue
>
> This also hides typos and whatnot.
The intended semantics of getnode() are that it cannot fail.
The individual *_getnode() functions do throw exceptions if
something goes wrong, and so they can be tested individually
on platforms where they are expected to work.
-- ?!ng
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
On Sun, 11 Jun 2006, Phillip J. Eby wrote: > At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote: > >I've added code to make uuid1() use uuid_generate_time() if available > >and uuid4() use uuid_generate_random() if available. These functions > >are provided on Mac OS X (in libc) and on Linux (in libuuid). Does > >that work for you? > > Sure - but actually my main point was to have a uuid() call you could use > to just get whatever the platform's preferred form of GUID is, without > having to pick what *type* you want. I'm reluctant to do that, because there's a privacy question here. I think the person using the module should have control over whether the UUID is going to leak the host ID or not (rather than leaving it up to whatever the platform prefers or which call the implementor of uuid.py happened to choose for a given platform). > Perhaps that isn't feasible, or is a bad idea for some other reason, but my > main point was to have a call that means "get me a good unique ID". :) Couldn't we just recommend uuid.uuid4() for that? -- ?!ng ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>>> for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
>>
>> Can we get rid of these absolute paths? Something like this should
>> suffice:
>>
> from ctypes import *
> buf = create_string_buffer(4096)
> windll.kernel32.GetSystemDirectoryA(buf, 4096)
>> 17
> buf.value.decode("mbcs")
>> u'C:\\WINNT\\system32'
>
> I'd like to, but i don't want to use a method for finding the system
> directory that depends on ctypes.
Why?
> Is there a more general way?
GetSystemDirectory() is the official way to find the system directory. You can
either access it through ctypes or through pywin32, but I guess we're moving to
ctypes for this kind of stuff, since it's bundled in 2.5. I don't know any
Python sys/os method to get a pointer to that directory. Another thing that you
might do is to drop those absolute system directories altogether. After all,
ipconfig should always be in the path.
As a last note, you are parsing ipconfig output assuming an English Windows
installation. My Italian Windows 2000 has localized output.
Giovanni Bajo
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Sat, 10 Jun 2006, Fredrik Lundh wrote:
if all undocumented modules had as much documentation and articles as
ET, the world would be a lot better documented ;-)
I've posted a text version of the xml.etree.ElementTree PythonDoc here:
http://www.python.org/sf/1504046
hopefully, one of the anything-to-latex volunteers will pick this up
shortly; otherwise, I'll deal with that early next week.
i am new to anything-to-latex but gave it a try
elementtree.txt is the modified text version
1. add a classifier to function and class documentation
2. remove the Arguments:/Returns: definition lists, first because the
tool does not handle it in a useful way, second i couldnt find this
style in lib/*.tex and therefore dont know how it should be handled.
elementtree.text is the version generated from this version (rst2docpy)
cheers:Module: elementtree
:Summary: The xml.etree.ElementTree Module
:Module Type: standard
:Author: Fredrik Lundh <[EMAIL PROTECTED]>
:Version Added: 2.5
:Synopsis: This module provides implementations of the Element and ElementTree
types, plus support classes.
A C version of this API is available as xml.etree.cElementTree.
Overview
The Element type is a flexible container object, designed to store
hierarchical data structures in memory. The type can be described as a
cross between a list and a dictionary.
Each element has a number of properties associated with it:
* a tag. This is a string identifying what kind of data
this element represents (the element type, in other words).
* a number of attributes, stored in a Python dictionary.
* a text string.
* an optional tail string.
* a number of child elements, stored in a Python sequence
To create an element instance, use the Element or SubElement factory
functions.
The ElementTree class can be used to wrap an element
structure, and convert it from and to XML.
Functions
-
Comment(text=None) : funcdesc
Comment element factory. This factory function creates a special
element that will be serialized as an XML comment.
The comment string can be either an 8-bit ASCII string or a Unicode
string.
text: A string containing the comment string.
Returns: An element instance, representing a comment.
dump(elem) : funcdesc
Writes an element tree or element structure to sys.stdout. This
function should be used for debugging only.
The exact output format is implementation dependent. In this
version, it's written as an ordinary XML file.
elem: An element tree or an individual element.
Element(tag, attrib={}, **extra) : funcdesc
Element factory. This function returns an object implementing the
standard Element interface. The exact class or type of that object
is implementation dependent, but it will always be compatible with
the _ElementInterface class in this module.
The element name, attribute names, and attribute values can be
either 8-bit ASCII strings or Unicode strings.
tag: The element name.
attrib: An optional dictionary, containing element attributes.
extra: Additional attributes, given as keyword arguments.
Returns: An element instance.
fromstring(text) : funcdesc
Parses an XML document from a string constant. Same as XML.
source: A string containing XML data.
Returns: An Element instance.
iselement(element) : funcdesc
Checks if an object appears to be a valid element object.
element: element instance.
Returns: A true value if this is an element object.
iterparse(source, events=None) : funcdesc
Parses an XML document into an element tree incrementally, and reports
what's going on to the user.
source: A filename or file object containing XML data.
events: A list of events to report back. If omitted, only "end"
events are reported.
Returns: A (event, elem) iterator.
parse(source, parser=None) : funcdesc
Parses an XML document into an element tree.
source: A filename or file object containing XML data.
parser: An optional parser instance. If not given, the
standard XMLTreeBuilder parser is used.
Returns: An ElementTree instance
ProcessingInstruction(target, text=None) : funcdesc
PI element factory. This factory function creates a special element
that will be serialized as an XML processing instruction.
target: A string containing the PI target.
text: A string containing the PI contents, if any.
Returns: An element instance, representing a PI.
SubElement(parent, tag, attrib={}, **extra) : funcdesc
Subelement factory. This function creates an element instance, and
appends it to an existing element.
The element name, attribute names, and attribute values can be
either 8-bit ASCII strings or Unicode strings.
parent: The parent element.
tag: The subelement name.
attrib: An optional dictionary, containing element attribut
Re: [Python-Dev] 2.5 issues need resolving in a few days
On Sat, 10 Jun 2006, Fredrik Lundh wrote:
if all undocumented modules had as much documentation and articles as
ET, the world would be a lot better documented ;-)
I've posted a text version of the xml.etree.ElementTree PythonDoc here:
http://www.python.org/sf/1504046
hopefully, one of the anything-to-latex volunteers will pick this up
shortly; otherwise, I'll deal with that early next week.
i am new to anything-to-latex but gave it a try
elementtree.txt is the modified text version
1. add a classifier to function and class documentation
2. remove the Arguments:/Returns: definition lists, first because the
tool does not handle it in a useful way, second i couldnt find this
style in lib/*.tex and therefore dont know how it should be handled.
elementtree.text is the version generated from this version (rst2docpy)
cheers:Module: elementtree
:Summary: The xml.etree.ElementTree Module
:Module Type: standard
:Author: Fredrik Lundh <[EMAIL PROTECTED]>
:Version Added: 2.5
:Synopsis: This module provides implementations of the Element and ElementTree
types, plus support classes.
A C version of this API is available as xml.etree.cElementTree.
Overview
The Element type is a flexible container object, designed to store
hierarchical data structures in memory. The type can be described as a
cross between a list and a dictionary.
Each element has a number of properties associated with it:
* a tag. This is a string identifying what kind of data
this element represents (the element type, in other words).
* a number of attributes, stored in a Python dictionary.
* a text string.
* an optional tail string.
* a number of child elements, stored in a Python sequence
To create an element instance, use the Element or SubElement factory
functions.
The ElementTree class can be used to wrap an element
structure, and convert it from and to XML.
Functions
-
Comment(text=None) : funcdesc
Comment element factory. This factory function creates a special
element that will be serialized as an XML comment.
The comment string can be either an 8-bit ASCII string or a Unicode
string.
text: A string containing the comment string.
Returns: An element instance, representing a comment.
dump(elem) : funcdesc
Writes an element tree or element structure to sys.stdout. This
function should be used for debugging only.
The exact output format is implementation dependent. In this
version, it's written as an ordinary XML file.
elem: An element tree or an individual element.
Element(tag, attrib={}, **extra) : funcdesc
Element factory. This function returns an object implementing the
standard Element interface. The exact class or type of that object
is implementation dependent, but it will always be compatible with
the _ElementInterface class in this module.
The element name, attribute names, and attribute values can be
either 8-bit ASCII strings or Unicode strings.
tag: The element name.
attrib: An optional dictionary, containing element attributes.
extra: Additional attributes, given as keyword arguments.
Returns: An element instance.
fromstring(text) : funcdesc
Parses an XML document from a string constant. Same as XML.
source: A string containing XML data.
Returns: An Element instance.
iselement(element) : funcdesc
Checks if an object appears to be a valid element object.
element: element instance.
Returns: A true value if this is an element object.
iterparse(source, events=None) : funcdesc
Parses an XML document into an element tree incrementally, and reports
what's going on to the user.
source: A filename or file object containing XML data.
events: A list of events to report back. If omitted, only "end"
events are reported.
Returns: A (event, elem) iterator.
parse(source, parser=None) : funcdesc
Parses an XML document into an element tree.
source: A filename or file object containing XML data.
parser: An optional parser instance. If not given, the
standard XMLTreeBuilder parser is used.
Returns: An ElementTree instance
ProcessingInstruction(target, text=None) : funcdesc
PI element factory. This factory function creates a special element
that will be serialized as an XML processing instruction.
target: A string containing the PI target.
text: A string containing the PI contents, if any.
Returns: An element instance, representing a PI.
SubElement(parent, tag, attrib={}, **extra) : funcdesc
Subelement factory. This function creates an element instance, and
appends it to an existing element.
The element name, attribute names, and attribute values can be
either 8-bit ASCII strings or Unicode strings.
parent: The parent element.
tag: The subelement name.
attrib: An optional dictionary, containing element attr
Re: [Python-Dev] beta1 coming real soon
H.Yamamoto wrote: > - Original Message - > From: "Walter Dörwald" <[EMAIL PROTECTED]> > To: "H.Yamamoto" <[EMAIL PROTECTED]> > Cc: "python-dev" > Sent: Friday, June 09, 2006 7:56 PM > Subject: Re: [Python-Dev] beta1 coming real soon > >> The best way to throughly test the patch is of course to check it in. ;) > > Is it too risky? ;) At least I'd like to get a second review of the patch. >> I've tested the patch on Windows and there were no obvious bugs. Of >> course to *really* test the patch a Windows installation with a >> multibyte locale is required. >> >>> # Maybe, no one is using this codec? >> The audience is indeed limited. > > Yes, I agree. And the audience who has "64bit" Windows with multibyte locale > should be much more limitted... Unfortunately, yes. Servus, Walter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
On 6/12/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Sun, 11 Jun 2006, Giovanni Bajo wrote:
> > Some comments on the code:
> >
> > > for dir in ['', r'c:\windows\system32', r'c:\winnt\system32']:
> >
> > Can we get rid of these absolute paths? Something like this should suffice:
> >
> > >>> from ctypes import *
> > >>> buf = create_string_buffer(4096)
> > >>> windll.kernel32.GetSystemDirectoryA(buf, 4096)
> > 17
> > >>> buf.value.decode("mbcs")
> > u'C:\\WINNT\\system32'
>
> I'd like to, but i don't want to use a method for finding the system
> directory that depends on ctypes. Is there a more general way?
Why not use ctypes? This is precisely the situation it was designed
for. There's nothing more general (this is totally Windows-specific
after all). The alternative is to depend on pywin32, which is not part
of the core, or to write a custom C wrapper, which seems to me to be
precisely what we're trying to move away from...
Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Greg> Multiple values could be written Greg>case 'a': Greg>case 'b': Greg>case 'c': Greg> ... That would be an exception to the rule that a line ending in a colon introduces an indented block. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Greg> A way out of this would be to define the semantics so that the Greg> expression values are allowed to be cached, and the order of Greg> evaluation and testing is undefined. So the first time through, Greg> the values could all be put in a dict, to be looked up thereafter. And if those expressions' values would change if evaluated after further execution? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sgmllib Comments
Martin v. Löwis wrote: > Sam Ruby wrote: >> If we can agree on the behavior, I would be glad to write up a patch. >> >> It seems to me that the simplest way to proceed would be for the code >> that attempts to resolve character references (both named and numeric) >> in attributes to be isolated in a single method. Subclasses that desire >> different behavior (including the existing Python 2.4 and prior >> behaviour) could simply override this method. > > In SGML, this is problematic: The named things are not character > references, they are entity references, and it isn't necessarily > the case that they expand to a character. For example, &author; > might expand to "Martin v. Löwis", and &logo; might refer to a > bitmap image which is unparsed. > > That said, providing a overridable replacement function sounds > like the right approach. To keep with tradition, I would still > distinguish between character references and entity references, > i.e. providing two overridable functions instead. Returning > None could mean that no replacement is available. > > As for default implementations, I think they should do what > currently happens: entity references are replaced according to > entitydefs, character references are replaced to bytes if > they are smaller than 256. > > Contrary to what others said, it appears that SGML *does* > support hexadecimal character references, provided that > the SGML declaraction contains the HCRO definition (which, > for HTML and XML, is defined as HCRO "&#x"). So it seems > safe to process hex character references by default (although > it isn't safe to assume Unicode, IMO). I don't see why expanding to multiple characters is a problem. Just so that we have a tracking number and real code to anchor this discussion, I've opened the following and attached a patch: http://python.org/sf/1504676 This implementation does handle multiple character expansions. It does default to exactly what the current code does. It does *not* currently handle hexadecimal character references. It also does pass all the current sgmllib tests, though I did not include any additional tests in this initial patch. - Sam Ruby ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
Hello, Armin Rigo wrote: > Hi, > > On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote: >> I just submitted http://python.org/sf/1501934 and assigned it to Neal so it >> doesn't get forgotten before 2.5 goes out ;) It seems Python 2.5 compiles >> the following code incorrectly: > > No, no, it's an underground move by Jeremy to allow assignment to > variables of enclosing scopes: ... > Credits to Samuele's evil side for the ideas. His non-evil side doesn't > agree, and neither does mine, of course :-) ... > More seriously, a function with a variable that is only written to as > the target of augmented assignments cannot possibly be something else > than a newcomer's mistake: the augmented assignments will always raise > UnboundLocalError. I am not really a newcomer to python. But lately I find myself regularly bitten by this compiler behavior that I tend to view as a (design) bug. This started happening after I saw that sets are just as good as lists performance-wise and I began changing code like this def solve(problem) : freebits = [True for _ in range(N)] def search(data) : ... for b in swaps : freebits[b] ^= 1 to more concise and clearer code like that def solve(problem) : freebits = set(range(N)) def search(data) ... freebits ^= swaps ... At such points, I find it a huge violation of the principle of least surprise that the compiler forbids to mean 'x.__ixor__(y)' with 'x ^= y' and interprets the latter to mean something different. Given that this preferred meaning is certain to cause a misleading runtime error !!! What ? It *wants* me to write x.__ixor__(y) *spontaneously* ? I can't believe it ! What's in dir(set) ? Oh, what's that, set.symmetric_difference_update() !? Why not set.lets_get_miles_out_of_our_way_to_accomodate_some_evil_theories() ? Mhh, set.X_update() admits iterables while augmented assignments require other sets [a vital difference for sure ;)] so maybe it's just by accident that the set API offers a good enough equivalent to x ^= y to escape having to use x.__ixor__(y) in similar contexts. Now reading this thread where somebody files a patch to "rectify" 2.5a2 behaving sanely on this issue, and somebody else follows up to -jokingly- argue in favor of sanity while confessing to the latter's evilness - that tells me that some really weird behind-the-looking-glass official theory might indeed dominate the issue. Is that theory written somewhere ? Or is it just the manifestation of a bug in the BDFL's famed time machine ? (I am saying this because Guido recently argued that sets should integrate as if they had been designed into Python from the beginning, what the above flagrantly contradicts imho). Cheers, Boris Borcic -- "On naît tous les mètres du même monde" ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] file()
I notice that file() throws an IOError when it detects an invalid mode string. Wouldn't a ValueError be more appropriate? Kristján ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
Alex Martelli wrote: >...claims: > >Note that for even rather small len(x), the total number of >permutations of x is larger than the period of most random number >generators; this implies that "most" permutations of a long >sequence can never be generated. > >Now -- why would the behavior of "most" random number generators be >relevant here? The module's docs claim, for its specific Mersenne >Twister generator, a period of 2**19997-1, which is (e.g.) a >comfortable >130128673800676351960752618754658780303412233749552410245124492452914636 >028095467780746435724876612802011164778042889281426609505759158196749438 >742986040468247017174321241233929215223326801091468184945617565998894057 >859403269022650639413550466514556014961826309062543 times larger than >the number of permutations of 2000 items, which doesn't really feel >to me like a "rather small len(x)" in this context (what I'm most >often shuffling is just a pack of cards -- len(x)==52 -- for example). > >I suspect that the note is just a fossil from a time when the default >random number generator was Whichman-Hill, with a much shorter >period. Should this note just be removed, or instead somehow >reworded to point out that this is not in fact a problem for the >module's current default random number generator? Opinions welcome! > > I think the note is still useful, but the "rather small" wording should be replaced by something most precise (such as the value of n=len(x) where n! > 2**19997). Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file()
Yup, although it's a change in behavior that would need to be studied carefully for backwards incompatibilities. Usually it's given as a constant, so there won't be any problems; but there might be code that receives a mode string and attempts to test its validity by trying it and catching IOError, such code would have to be changed. --Guido On 6/12/06, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote: > I notice that file() throws an IOError when it detects an invalid mode > string. Wouldn't a ValueError be more appropriate? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sgmllib Comments
Sam Ruby wrote: > I don't see why expanding to multiple characters is a problem. That isn't a problem. Expanding to unparsed entities is. So the current call to handle_entityref must remain. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
At 12:44 AM 6/12/2006 +0200, Fredrik Lundh wrote: >the compiler can of course figure that out also for if/elif/else state- >ments, by inspecting the AST. the only advantage for switch/case is >user syntax... Not quite true - you'd have to restrict the switch expression in some way, so you don't have: if x.y == 1: ... elif x.y == 2: ... where the compiler doesn't know if getattr(x,'y') is really supposed to happen more than once. But I suppose you could class that as syntax. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Please stop changing wsgiref on the trunk
As requested in PEP 360, please inform me of any issues you find so they can be corrected in the standalone package and merged back to the trunk. I just wasted time cutting an 0.1.1 release of the standalone wsgiref package only to find that it doesn't correspond to any particular point in the trunk, because people made changes without contacting me or the Web-SIG. I then spent a bunch more time figuring out how to get the changes out and merge them back in to the standalone version such that the Python trunk has a specific version number of wsgiref. Please don't do this again. I appreciate the help finding bugs, but I'll probably still be maintaining the standalone version of wsgiref for a few years yet. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote: >Thomas Heller wrote: > > I don't know if this is the uuidgen you're talking about, but > > on linux there is libuuid: > >Thanks! > >Okay, that's in there now. Have a look at http://zesty.ca/python/uuid.py . > >Phillip J. Eby wrote: > > By the way, I'd love to see a uuid.uuid() constructor that simply calls the > > platform-specific default UUID constructor (CoCreateGuid or uuidgen(2)), > >I've added code to make uuid1() use uuid_generate_time() if available >and uuid4() use uuid_generate_random() if available. These functions >are provided on Mac OS X (in libc) and on Linux (in libuuid). Does >that work for you? Sure - but actually my main point was to have a uuid() call you could use to just get whatever the platform's preferred form of GUID is, without having to pick what *type* you want. The idea being that there should be some call you can make that will always give you something reasonably unique, without being overspecified as to the type of uuid. That way, people can be told to use uuid.uuid() to get unique IDs for use in their programs, without having to get into what types of UUIDs do what. Perhaps that isn't feasible, or is a bad idea for some other reason, but my main point was to have a call that means "get me a good unique ID". :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FYI: wsgiref is now checked in
At 03:22 PM 6/10/2006 -0400, Tim Peters wrote: >This may be because compare_generic_iter() uses `assert` statements, >and those vanish under -O. If so, a test shouldn't normally use >`assert`. On rare occasions it's appropriate, like test_struct's: > > if x < 0: > expected += 1L << self.bitsize > assert expected > 0 > >That isn't testing any of struct's functionality, it's documenting and >verifying a fundamental _belief_ of the test author's: the test >itself is buggy if that assert ever triggers. Or, IOW, it's being >used for what an assert statement should be used for :-) Thanks for the bug report; I've fixed these problems in the standalone version (0.1.2 on the cheeseshop) and in the Python 2.5 trunk. Web-SIG folks take note: wsgiref.validate is based on paste.lint, so paste.lint has the same problem. That is, errors won't be raised if the code is run with -O. As a side effect of fixing the problems, I found that some of the wsgiref.validate (aka paste.lint) asserts have improperly computed messages. Instead of getting an explanation of the problem, you'll instead get a different error at the assert. I fixed these in wsgiref.validate, but the underlying problems presumably still exist in paste.lint. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please stop changing wsgiref on the trunk
On 6/11/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > As requested in PEP 360, please inform me of any issues you find so they > can be corrected in the standalone package and merged back to the trunk. > > I just wasted time cutting an 0.1.1 release of the standalone wsgiref > package only to find that it doesn't correspond to any particular point in > the trunk, because people made changes without contacting me or the > Web-SIG. I then spent a bunch more time figuring out how to get the > changes out and merge them back in to the standalone version such that the > Python trunk has a specific version number of wsgiref. Please don't do > this again. > > I appreciate the help finding bugs, but I'll probably still be maintaining > the standalone version of wsgiref for a few years yet. Phillip, Please consider the burden for Python developers who have to remember who owns what code. I know we have PEP 360, but the more I think about it, the more I believe it's unreasonable to have growing amounts of code in the Python source tree that cannot be modified by Python developers who are taking the usual caution (understanding the code, running unit tests, being aware of backwards compatibility requirements, etc.). Once code is checked into Python's source tree, change control should ideally rest with the Python developers collectively, not with one particular "owner". IOW I think PEP 360 is an unfortunate historic accident, and we would be better off without it. I propose that we don't add to it going forward, and that we try to get rid of it as we can. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please stop changing wsgiref on the trunk
At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote: >IOW I think PEP 360 is an unfortunate historic accident, and we would >be better off without it. I propose that we don't add to it going >forward, and that we try to get rid of it as we can. 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want to get rid of it, *now* would be the time. There is an approach that would address this issue and others relating to external packages, but it would require changes to how Python is built. That is, I would propose a directory to contain externally-maintained packages, each with their own setup.py. These packages could be built and installed with Python, but would then also be separately-distributable. Alternately, such packages could be done using svn:externals tied to specific release versions of the external packages. This idea would address the needs of external maintainers (having a single release history) while still allowing Python developers to modify the code (if the external package is in Python's SVN repository). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UUID module
Ka-Ping Yee wrote: > I'd like to, but i don't want to use a method for finding the system > directory that depends on ctypes. Is there a more general way? I think os.path.join(os.environ["SystemRoot"], "system32") should be fairly reliable. If people are worried that the directory might not be system32, then HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows\SystemDirectory gives you the value (although I could not find out how to expand REG_EXPAND_SZ keys with _winreg). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
Walter Dörwald wrote: >>> The best way to throughly test the patch is of course to check it in. ;) >> Is it too risky? ;) > > At least I'd like to get a second review of the patch. I've reviewed it, and am likely to check it in. I notice that the patch still has problems. In particular, it is limited to "DBCS" (and SBCS) character sets in the strict sense; general "MBCS" character sets are not supported. There are a few of these, most notably the ISO-2022 ones, UTF-8, and GB18030 (can't be bothered to look up the code page numbers for them right now). What I don't know is whether any Windows locale uses a "true" MBCS character set as its "ANSI" code page. The approach taken in the patch could be extended to GB18030 and UTF-8 in principle, but can't possibly work for ISO-2022. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please stop changing wsgiref on the trunk
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote: > >IOW I think PEP 360 is an unfortunate historic accident, and we would > >be better off without it. I propose that we don't add to it going > >forward, and that we try to get rid of it as we can. > > 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want > to get rid of it, *now* would be the time. I'm all for it. While I am an enthusiastic supporter of several of those additions, I am *not* in favor of the special status granted to software contributed by certain developers, since it is a burden for all other developers. > There is an approach that would address this issue and others relating to > external packages, but it would require changes to how Python is > built. That is, I would propose a directory to contain > externally-maintained packages, each with their own setup.py. These > packages could be built and installed with Python, but would then also be > separately-distributable. > > Alternately, such packages could be done using svn:externals tied to > specific release versions of the external packages. > > This idea would address the needs of external maintainers (having a single > release history) while still allowing Python developers to modify the code > (if the external package is in Python's SVN repository). Even that is a burden on regular Python developers. For example, when I do "svn up" in the PEPS directory, which has such an arrangement for the docutils, it usually spends (much) more time deciding that there's nothing new in the docutils than it spends on the rest of the update. I also suspect that the external linking will continue to cause a burden for Python developers -- upgrading to a newer version of the external package would require making sure that no changes made by Python developers in the previous release bundle are lost in the new release bundle. I personally think that, going forward, external maintainers should not be granted privileges such as are being granted by PEP 360, and an inclusion of a package in the Python tree should be considered a "fork" for all practical purposes. If an external developer is not okay with such an arrangement, they shouldn't contribute. Note: I'm saying "going forward". I'm not saying that this "tough luck" policy should be applied to the packages that have already been accepted; I don't want the PSF to break its work. Although I'd encourage their authors to loosen up. Perhaps issues like these should motivate us to consider a different source control tool. There's a new crop of tools out that could solve this by having multiple repositories that can be sync'ed with each other. This sounds like an important move towards world peace! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
PyXML appears pretty stable (in terms of release frequency -- I have no opinion on the code quality :-). Perhaps it could just be incorporated into the Python svn tree, if the various owners are willing to sign a contributor statement? --Guido On 6/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > The most important outstanding issue is the xmlplus/xmlcore issue. > > It's not going to get fixed unless someone works on it. There's only > > a few days left before beta 1. Can someone please address this? > > >From my point of view, I shall consider them resolved/irrelevant: > I'm going to step down as a PyXML maintainer, so I don't have to > worry anymore about how to maintain PyXML. If PyXML then gets > unmaintained, the problem goes away, otherwise, the new maintainer > will have to find a solution. > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import semantics
On 6/12/06, Samuele Pedroni <[EMAIL PROTECTED]> wrote: > Fabio Zadrozny wrote: > > Python and Jython import semantics differ on how sub-packages should be > > accessed after importing some module: > > > > Jython 2.1 on java1.5.0 (JIT: null) > > Type "copyright", "credits" or "license" for more information. > > >>> import xml > > >>> xml.dom > > > > > > Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on > > win32 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import xml > > >>> xml.dom > > Traceback (most recent call last): > > File "", line 1, in ? > > AttributeError: 'module' object has no attribute 'dom' > > >>> from xml.dom import pulldom > > >>> xml.dom > > > > > > Note that in Jython importing a module makes all subpackages beneath it > > available, whereas in python, only the tokens available in __init__.py > > are accessible, but if you do load the module later even if not getting > > it directly into the namespace, it gets accessible too -- this seems > > more like something unexpected to me -- I would expect it to be > > available only if I did some "import xml.dom" at some point. > > > > My problem is that in Pydev, in static analysis, I would only get the > > tokens available for actually imported modules, but that's not true for > > Jython, and I'm not sure if the current behaviour in Python was expected. > > > > So... which would be the right semantics for this? > > the difference in Jython is deliberate. I think the reason was to mimic > more the Java style for this, in java fully qualified names always work. > In jython importing the top level packages is enough to get a similar > effect. > > This is unlikely to change for backward compatibility reasons, at least > from my POV. IMO it should do this only if the imported module is really a Java package. If it's a Python package it should stick to python semantics if possible. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should hex() yield 'L' suffix for long numbers?
Here's how I interpret PEP 237. Some changes to hex() and oct() are warned about in B1and to be implemented in B2. But I'm pretty sure that was about the treatment of negative numbers, not about the trailing 'L'. I believe the PEP authors overlooked the trailing 'L' for hex() and oct(). I think they should be considered just as sticky as the trailing 'L' for repr(). --Guido On 6/11/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Ka-Ping Yee] > > I did this earlier: > > > > >>> hex(9) > > '0x9184e729fffL' > > > > and found it a little jarring, because i feel there's been a general > > trend toward getting rid of the 'L' suffix in Python. > > > > Literal long integers don't need an L anymore; they're automatically > > made into longs if the number is too big. And while the repr() of > > a long retains the L on the end, the str() of a long does not, and > > i rather like that. > > > > So i kind of expected that hex() would not include the L either. > > I see its main job as just giving me the hex digits (in fact, for > > Python 3000 i'd prefer even to drop the '0x' as well), and the L > > seems superfluous and distracting. > > > > What do you think? Is Python 2.5 a reasonable time to drop this L? > > As I read pep 237, that should have happened in Python 2.3 or 2.4. > This specific case is kinda muddy there. Regardless, the only part > that was left for Python 3 was "phase C", and this is phase C in its > entirety: > > C. The trailing 'L' is dropped from repr(), and made illegal on >input. (If possible, the 'long' type completely disappears.) > > It's possible, though, that hex() and oct() were implicitly considered > to be variants of repr() for purposes of phase C. How much are we > willing to pay Guido to Pronounce? > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
Guido van Rossum wrote: >> 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want >> to get rid of it, *now* would be the time. > > I'm all for it. > > While I am an enthusiastic supporter of several of those additions, I > am *not* in favor of the special status granted to software > contributed by certain developers, since it is a burden for all other > developers. Then I guess we should deal with before 2.5b1, and delay 2.5b1 until the status of each of these has been clarified. Each maintainer should indicate whether he is happy with a "this is part of Python" approach. If so, the entry should be removed from PEP 360 (*); if not, the code should be removed from Python before beta 1. Speaking with some authority for Expat, I'd be happy to have it removed from PEP 360. Regards, Martin (*) Alternatively, this PEP could be given purely informational status, i.e. with section "no requirements on Python maintainers". Then, Expat should be moved to that section: people can happily make changes to expat, and whoever synchronizes it with the external source must make sure these changes get carried over. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
At 09:43 AM 6/12/2006 -0700, Guido van Rossum wrote: >On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >>At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote: >> >IOW I think PEP 360 is an unfortunate historic accident, and we would >> >be better off without it. I propose that we don't add to it going >> >forward, and that we try to get rid of it as we can. >> >>4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want >>to get rid of it, *now* would be the time. > >I'm all for it. > >While I am an enthusiastic supporter of several of those additions, I >am *not* in favor of the special status granted to software >contributed by certain developers, since it is a burden for all other >developers. While I won't claim to speak for the other authors, I would guess that they have the same reason for wanting that status as I do: to be able to maintain an external release for their existing users with older versions of Python, until Python-in-the-field catches up with Python-in-development. Right now, the effective industry-deployed version of Python is 2.3 - maybe 2.2 if you have a lot infrastructure in Python, and 2.1 if you support Jython. >I also suspect that the external linking will continue to cause a >burden for Python developers -- upgrading to a newer version of the >external package would require making sure that no changes made by >Python developers in the previous release bundle are lost in the new >release bundle. I'd be willing to live with e.g. moving wsgiref to an Externals/wsgiref subdirectory of the main Python tree, *without* svn:externals, and simply bumping its version number in that directory to issue snapshots. This would be no different from the current situation (in terms of svn usage for core developers), except that I could go to one directory to get an "svn log" and review what other people did to the code and docs. Right now, I've got to track at least three different directories to know what somebody did to wsgiref in the core. >I personally think that, going forward, external maintainers should >not be granted privileges such as are being granted by PEP 360, and an >inclusion of a package in the Python tree should be considered a >"fork" for all practical purposes. If an external developer is not >okay with such an arrangement, they shouldn't contribute. This is going to make it tougher to get good contributions, where "good" means "has existing users and a maintainer committed to supporting them". >Perhaps issues like these should motivate us to consider a different >source control tool. There's a new crop of tools out that could solve >this by having multiple repositories that can be sync'ed with each >other. This sounds like an important move towards world peace! First we'd need to make Python's build process support building external libraries in the first place. If we did that, we could solve the problem in SVN right now, as long as maintainers were willing to move their project's main repository to Python's repository. If I understand correctly, the main thing it would require is that Python's setup.py invoke all the Externals/*/setup.py files. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Thomas Lee wrote: > Hi all, > > As the subject of this e-mail says, the attached patch adds a "switch" > statement to the Python language. > > However, I've been reading through PEP 275 and it seems that the PEP > calls for a new opcode - SWITCH - to be added to support the new > construct. > > I got a bit lost as to why the SWITCH opcode is necessary for the > implementation of the PEP. The reasoning seems to be > improving performance, but I'm not sure how a new opcode could improve > performance. > > Anybody care to take the time to explain this to me, perhaps within the > context of my patch? Could you upload your patch to SourceForge ? Then I could add it to the PEP. Thomas wrote a patch which implemented the switch statement using an opcode. The reason was probably that switch works a lot like e.g. the for-loop which also opens a new block. Could you explain how your patch works ? BTW, I think this part doesn't belong into the patch: > Index: Lib/distutils/extension.py > === > --- Lib/distutils/extension.py(revision 46818) > +++ Lib/distutils/extension.py(working copy) > @@ -185,31 +185,31 @@ > continue > > suffix = os.path.splitext(word)[1] > -switch = word[0:2] ; value = word[2:] > +switch_word = word[0:2] ; value = word[2:] -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 12 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2006-07-03: EuroPython 2006, CERN, Switzerland 20 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 09:43 AM 6/12/2006 -0700, Guido van Rossum wrote: > >On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > >>At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote: > >> >IOW I think PEP 360 is an unfortunate historic accident, and we would > >> >be better off without it. I propose that we don't add to it going > >> >forward, and that we try to get rid of it as we can. > >> > >>4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want > >>to get rid of it, *now* would be the time. > > > >I'm all for it. > > > >While I am an enthusiastic supporter of several of those additions, I > >am *not* in favor of the special status granted to software > >contributed by certain developers, since it is a burden for all other > >developers. > > While I won't claim to speak for the other authors, I would guess that they > have the same reason for wanting that status as I do: to be able to > maintain an external release for their existing users with older versions > of Python, until Python-in-the-field catches up with Python-in-development. > > Right now, the effective industry-deployed version of Python is 2.3 - maybe > 2.2 if you have a lot infrastructure in Python, and 2.1 if you support Jython. Sure, but this doesn't require the draconian "I-and-I-only own the code" approach that you have. There's more code in the source tree that is also distributed externally -- see the table in PEP 291. > >I also suspect that the external linking will continue to cause a > >burden for Python developers -- upgrading to a newer version of the > >external package would require making sure that no changes made by > >Python developers in the previous release bundle are lost in the new > >release bundle. > > I'd be willing to live with e.g. moving wsgiref to an Externals/wsgiref > subdirectory of the main Python tree, *without* svn:externals, and simply > bumping its version number in that directory to issue snapshots. > > This would be no different from the current situation (in terms of svn > usage for core developers), except that I could go to one directory to get > an "svn log" and review what other people did to the code and docs. Right > now, I've got to track at least three different directories to know what > somebody did to wsgiref in the core. And is that such a big deal? Now that wsgiref is being distributed with Python 2.5, it shouldn't evlove at a much faster pace than Python 2.5, otherwise it would defeat the purpose of having it in 2.5. (And isn't it just a reference implementation? Why would it evolve at all?) > >I personally think that, going forward, external maintainers should > >not be granted privileges such as are being granted by PEP 360, and an > >inclusion of a package in the Python tree should be considered a > >"fork" for all practical purposes. If an external developer is not > >okay with such an arrangement, they shouldn't contribute. > > This is going to make it tougher to get good contributions, where "good" > means "has existing users and a maintainer committed to supporting them". To which I say, "fine". From the Python core maintainers' POV, more standard library code is just more of a maintenance burden. Maybe we should get serious about slimming down the core distribution and having a separate group of people maintain sumo bundles containing Python and lots of other stuff. Or maybe we don't even need the latter, if the download technology improves enough (eggs should make it easier for people to download and install extra stuff in a pinch). > >Perhaps issues like these should motivate us to consider a different > >source control tool. There's a new crop of tools out that could solve > >this by having multiple repositories that can be sync'ed with each > >other. This sounds like an important move towards world peace! > > First we'd need to make Python's build process support building external > libraries in the first place. If we did that, we could solve the problem > in SVN right now, as long as maintainers were willing to move their > project's main repository to Python's repository. > > If I understand correctly, the main thing it would require is that Python's > setup.py invoke all the Externals/*/setup.py files. I guess that's one way of doing it. But perhaps Python's setup.py should not bother at all, and this is up to the users. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 12 Jun 2006 13:08:52 -0400 "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > While I won't claim to speak for the other authors, I would guess > that they have the same reason for wanting that status as I do: to be > able to maintain an external release for their existing users with > older versions of Python, until Python-in-the-field catches up with > Python-in-development. I handle this in a different way for the email package, which used to be externally maintained and effectively still supports Pythons back to 2.1. I'm happy (no, ecstatic) if others want to help maintain it (w/discussion on email-sig of course), but I'll probably still be the one doing standalone releases. I do this by maintaining a directory in the sandbox that externals in the correct url from the Python repo, and also provides all the necessary distutils and documentation chrome used to support the standalone releases. That way, the code lives in Python's primary repo, but it's still easy enough for me to spin releases. The catch of course is that I have three checkouts for each of the three major versions of email. Two of them pull from branches in the Python repo while one (currently) pulls from the trunk. Yes, it's a PITA, but I could reduce the amount of work by deciding on a different mix of version compatibility. I don't know if that will work for the other PEP 360 packages, but it works for me. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iQCVAwUBRI2nkHEjvBPtnXfVAQLuZgP+NTCIYEM2gCiphIPlDCwncYBZ7FHrirPd XHIPfmjDfYYNA+wWvCBYkgLPakRXCldSO7p2EYrl/RVetgZR51/V0kQsKbC+UkUa TiCIgMr0P7rIMRXXN7dZAcvD8Xaxs7TE2meTEC+HaWem9wEUaJy/2PJSUmxTMF3t BxlIGN7gjeg= =C6oP -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > is this "we don't give a fuck about 3rd party developers and users" attitude > really representative for the python-dev community and the PSF ? If you want the PSF to listen to you should watch your language. I'm out of here, back to focusing on Python 3000. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
Guido van Rossum wrote: > Maybe we should get serious about slimming down the core distribution > and having a separate group of people maintain sumo bundles containing > Python and lots of other stuff. there are already lots of people doing that (most Linux distributions add stuff, directly or indirectly; ActiveState and Enthought are doing that for windows, Nokia is doing that for the S60 platform, etc); the PEP 360 approach is an attempt to emulate that for the python.org distribution. > I guess that's one way of doing it. But perhaps Python's setup.py > should not bother at all, and this is up to the users. or, for the python.org distribution, the release manager. I'm not sure how to deal with things like documentation, regression tests, buildbots, issue trackers, etc, though. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
On Monday 12 June 2006 13:42, Guido van Rossum wrote: > Maybe we > should get serious about slimming down the core distribution and > having a separate group of people maintain sumo bundles containing > Python and lots of other stuff. +1 -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: Martin v. Löwis wrote:> Then I guess we should deal with before 2.5b1, and delay 2.5b1 until the> status of each of these has been clarified.>> Each maintainer should indicate whether he is happy with a "this is > part of Python" approach. If so, the entry should be removed from PEP> 360 (*); if not, the code should be removed from Python before beta 1.is this "we don't give a fuck about 3rd party developers and users" attitude really representative for the python-dev community and the PSF ?Well, obviously I care since I wrote the PEP in the first place.But I don't think this is trying to say they don't care. People just want to lower the overhead of maintaining the distro. Having to report bugs and patches to an external location instead of just getting to fix it directly is a hassle that poeple don't ask for. Plus it is bound to get forgotten by accident, so planning for it doesn't hurt. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
On 12 Jun 2006, at 02:19, Terry Jones wrote: >> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: > > Greg> Terry Jones wrote: >>> Suppose you have a RNG with a cycle length of 5. There's nothing >>> to stop an >>> algorithm from taking multiple already returned values and >>> combining them >>> in some (deterministic) way to generate > 5 outcomes. > > Greg> No, it's not. As long as the RNG output is the only input to > Greg> the algorithm, and the algorithm is deterministic, it is > Greg> not possible get more than N different outcomes. It doesn't > Greg> matter what the algorithm does with the input. ... > The code below uses a RNG with period 5, is deterministic, and has one > initial state. It produces 20 different outcomes. I think that in any meaningful sense your code is producing just one outcome, since it has just one initial state. It is completely deterministic and has no seed, so this is expected. > It's just doing a simplistic version of what a lagged RNG generator > does, > but the lagged part is in the "algorithm" not in the rng. That's > why I said > if you included the state of the algorithm in what you meant by > "state" I'd > be more inclined to agree. This is a different issue. You instantiate more than one PRNG. If you have n PRGNs which each have a period p then you can get have the combination in p^n different starting states, which can be useful but only if you can find n*log2(p) bits of starting entropy to get the thing into a usefully random state. Nicko > def rng(): ... > history = [rng()] ... > for lag in range(1, 5): ... > new = rng() ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
Brett Cannon wrote: > But I don't think this is trying to say they don't care. People just want > to lower the overhead of maintaining the distro. well, wouldn't the best way to do that be to leave all non-trivial maintenance of a given component to an existing external community? (after all, the number of non-python-dev python contributors are *much* larger than the number of python-dev contributors). I mean, we're not really talking about ordinary leak-elimination or portability-fixing or security-hole-plugging maintenance; it's the let's-extend-the-api-in-incompatible- ways and fork-because-we-can stuff that I'm worried about. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
Guido van Rossum wrote: >>> I personally think that, going forward, external maintainers should >>> not be granted privileges such as are being granted by PEP 360, and >>> an inclusion of a package in the Python tree should be considered a >>> "fork" for all practical purposes. If an external developer is not >>> okay with such an arrangement, they shouldn't contribute. >> >> This is going to make it tougher to get good contributions, where >> "good" means "has existing users and a maintainer committed to >> supporting them". > > To which I say, "fine". From the Python core maintainers' POV, more > standard library code is just more of a maintenance burden. Maybe we > should get serious about slimming down the core distribution and > having a separate group of people maintain sumo bundles containing > Python and lots of other stuff. -1000. One of the biggest Python strength, and one that I personally rely on a lot, is the large *standard* library. It means that you can write scripts and programs that will run on any Python installation out there, no matter how many eggs were downloaded before, no matter whether the Internet connection is available or not, no matter if the user has privileges to install extensions, even if the SourceForge mirror is down, even if SourceForge changed their HTML and now the magic code can't grok it anymore, etc etc etc. If Python were to lose this standard library in favor of several different distributions, users could not sensibly write a program anymore without incurring the risk of using packages not available to some users. Perl has this problem with CPAN, and system administrators going through hoops to write admin scripts which do not rely on any external package just because you can't be sure if a package is installed or not; this leads to code duplication (duplication of the code included in an external package, but which can't be "reliably" used), and to bugs (since the local copy of the functionality can surely be more buggy than the widespread implementation of the external package). Let's not get into this mess, please. I think we just need a smoother way to maintain the standard library, not an agreement to remove it, just because we cannot find a way to maintain it properly. The fact that there hundreds of unreviewed patches to the standard library made by wannabe contributors is a blatant sign that something *can* be improved. -- Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
On 6/12/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > >>> I personally think that, going forward, external maintainers should > >>> not be granted privileges such as are being granted by PEP 360, and > >>> an inclusion of a package in the Python tree should be considered a > >>> "fork" for all practical purposes. If an external developer is not > >>> okay with such an arrangement, they shouldn't contribute. > >> > >> This is going to make it tougher to get good contributions, where > >> "good" means "has existing users and a maintainer committed to > >> supporting them". > > > > To which I say, "fine". From the Python core maintainers' POV, more > > standard library code is just more of a maintenance burden. Maybe we > > should get serious about slimming down the core distribution and > > having a separate group of people maintain sumo bundles containing > > Python and lots of other stuff. > > -1000. > > One of the biggest Python strength, and one that I personally rely on a lot, > is the large *standard* library. It means that you can write scripts and > programs that will run on any Python installation out there, no matter how > many eggs were downloaded before, no matter whether the Internet connection > is available or not, no matter if the user has privileges to install > extensions, even if the SourceForge mirror is down, even if SourceForge > changed their HTML and now the magic code can't grok it anymore, etc etc > etc. > > If Python were to lose this standard library in favor of several different > distributions, users could not sensibly write a program anymore without > incurring the risk of using packages not available to some users. Perl has > this problem with CPAN, and system administrators going through hoops to > write admin scripts which do not rely on any external package just because > you can't be sure if a package is installed or not; this leads to code > duplication (duplication of the code included in an external package, but > which can't be "reliably" used), and to bugs (since the local copy of the > functionality can surely be more buggy than the widespread implementation of > the external package). > > Let's not get into this mess, please. I think we just need a smoother way to > maintain the standard library, not an agreement to remove it, just because > we cannot find a way to maintain it properly. The fact that there hundreds > of unreviewed patches to the standard library made by wannabe contributors > is a blatant sign that something *can* be improved. I'm with you, actually; developers contributing code without wanting to give up control are the problem. You should go talk to those contributors. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > I mean, we're not really talking about ordinary leak-elimination or > portability-fixing > or security-hole-plugging maintenance; it's the > let's-extend-the-api-in-incompatible- > ways and fork-because-we-can stuff that I'm worried about. Have any instances of that actually happened? That would be a problem with *any* code in the Python library, not just external contributions, so I'm not sure why external contribions should be treated any differently here. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> But I don't think this is trying to say they don't care. People just want> to lower the overhead of maintaining the distro.well, wouldn't the best way to do that be to leave all non-trivial maintenance of a given component to an existing external community?(after all, the number of non-python-dev python contributors are *much* largerthan the number of python-dev contributors).I mean, we're not really talking about ordinary leak-elimination or portability-fixing or security-hole-plugging maintenance; it's the let's-extend-the-api-in-incompatible-ways and fork-because-we-can stuff that I'm worried about.Well, I don't know if that is necessarily the case. PEP 360 doesn't have a single project saying that minor fixes can just go right in. If we want to just change the wording such that all code in the tree can be touched for bug fixes and compatibility issues without clearance, that's great. But Phillip's email that sparked all of this was about basic changes to wsgiref, not some API change (at least to the best of my knowledge).-Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
At 10:42 AM 6/12/2006 -0700, Guido van Rossum wrote: >Sure, but this doesn't require the draconian "I-and-I-only own the >code" approach that you have. If there were only one version and directory tree to maintain to do both the Python trunk and the external version, I wouldn't mind other people making changes. It's the synchronization that's a PITA, especially because of the directory layout. If we had Externals/ I would just issue snapshots from there. >And is that such a big deal? Now that wsgiref is being distributed >with Python 2.5, it shouldn't evlove at a much faster pace than Python >2.5, otherwise it would defeat the purpose of having it in 2.5. (And >isn't it just a reference implementation? Why would it evolve at all?) This is backwards: I'm not the one who evolved it, other Python devs did! :) I want Python 2.5 to distribute some version of wsgiref that is precisely the same as *some* public wsgiref release, so that PEP 360 will have accurate info and so that people who want a particular wsigref release can specify a sane version number, to avoid the kind of skew we used to have with micro-releases (e.g. 2.2.2). >>If I understand correctly, the main thing it would require is that Python's >>setup.py invoke all the Externals/*/setup.py files. > >I guess that's one way of doing it. But perhaps Python's setup.py >should not bother at all, and this is up to the users. However, if Python's setup.py did this, then external developers would get the benefit (and discipline) of the buildbots and testing. That seems like a good thing to me. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should hex() yield 'L' suffix for long numbers?
[Guido] > Here's how I interpret PEP 237. Some changes to hex() and oct() are > warned about in B1and to be implemented in B2. But I'm pretty sure > that was about the treatment of negative numbers, not about the > trailing 'L'. I believe the PEP authors overlooked the trailing 'L' > for hex() and oct(). That was mentioned explicitly under "Incompatibilities" (last sentence): - Currently, the '%u', '%x', '%X' and '%o' string formatting operators and the hex() and oct() built-in functions behave differently for negative numbers: negative short ints are formatted as unsigned C long, while negative long ints are formatted with a minus sign. This will be changed to use the long int semantics in all cases (but without the trailing 'L' that currently distinguishes the output of hex() and oct() for long ints). ... Since it wasn't mentioned explicitly again under "Transition", but the trailing 'L' on repr() was explicitly mentioned twice under "Transition", the least strained logic-chopping reading is that losing the 'L' for hex() and oct() was intended to be done along with the other changes in the paragraph quoted above. > I think they should be considered just as sticky as the trailing 'L' for > repr(). Given that the "least strained" reading above missed its target release, and the purpose of target releases was to minimize annoying changes, I agree it should be left for P3K now regardless. I'll change the PEP accordingly to make this explicit. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
On Mon, Jun 12, 2006 at 10:42:44AM -0700, Guido van Rossum wrote: > standard library code is just more of a maintenance burden. Maybe we > should get serious about slimming down the core distribution and > having a separate group of people maintain sumo bundles containing > Python and lots of other stuff. Or maybe we don't even need the That separate group of people = Linux distributors, ActiveState, whoever maintains the fink archive (and to some degree Apple), so we already have sumo distributions available. That doesn't help people on platforms without package databases or repositories of free software, but I don't know if any such platforms matter. I'd bet over 90% of people writing Python code are on one of Windows, MacOS, or Linux; Solaris would add a small sliver to that 90%, and then all the other platforms (other Unix variants, Palms, Nokias, etc.) are in the noise. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import semantics
> the difference in Jython is deliberate. I think the reason was to mimic > more the Java style for this, in java fully qualified names always work. > In jython importing the top level packages is enough to get a similar > effect. > > This is unlikely to change for backward compatibility reasons, at least > from my POV. While I appreciate the usage concerns, at some point someone has to decide whether Jython is an implementation of Python, or a version of BeanShell with odd syntax. If it's Python, it has to comply with the Python specification, regardless of what Java does. If it doesn't do that, it should be cast into the outer darkness of the Python world. The escape hatch here would be to redefine the Python specification to allow either behavior. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file()
Guido van Rossum wrote: > Yup, although it's a change in behavior that would need to be studied > carefully for backwards incompatibilities. Usually it's given as a > constant, so there won't be any problems; but there might be code that > receives a mode string and attempts to test its validity by trying it > and catching IOError, such code would have to be changed. > > --Guido > > On 6/12/06, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote: >> I notice that file() throws an IOError when it detects an invalid mode >> string. Wouldn't a ValueError be more appropriate? > The situation is even more complex with the current trunk. open() raises ValueError if it detects an invalid the mode string, such as universal newline mode and a writable mode combined (the definition of what is invalid has been made stricter, the mode string now must begin with r, w, a or U), but it raises IOError if the OS call to fopen() fails because of an invalid mode string. This might need unification. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
At 11:23 AM 6/12/2006 -0700, Guido van Rossum wrote: >developers contributing code without wanting >to give up control are the problem. Control isn't the issue; it's ensuring that fixes don't get lost or reverted from either the external version or the stdlib version. Control is merely a means to that end. If we can accomplish that via some other means (e.g. an Externals/ subtree), I'm all for it. (Actually, perhaps Packages/ would be a better name, since the point is that they're packages that are maintained for separate distribution for older Python versions. They're really *not* "external" any more, they just get snapshotted for release.) I guess I should say, control isn't the issue for *me*. I can't speak for anyone else. Fredrik has raised the issue of API forks, but I haven't encountered this myself. I *have* seen some developers make spurious "cleanups" to working code that breaks compatibility with older Python versions, though, just not in wsgiref. But I don't mind policing such things myself as long as I have only one subtree to svn log (versus having to track three separate logs and diffs for Lib/wsgiref/, Lib/test/test_wsgiref.py, and Doc/lib/libwsgiref.tex, and then having to reformat the diffs to apply to a different directory layout). Now, Barry's approach to the email package makes good sense to me, and I'd use it, except that SVN externals can't sync individual files. I'd have to create Lib/wsgiref/tests (and make a dummy Lib/test/test_wsgiref that invokes them) and Lib/wsgiref/doc (and make Doc/lib/lib.tex include libwsgiref.tex from there). If those changes are acceptable, I'd be happy to take that as a compromise approach. I'll still have to manually update the Python PKG-INFO (due to no setup.py), but it'd be better than nothing. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import semantics
Bill Janssen wrote: >>the difference in Jython is deliberate. I think the reason was to mimic >>more the Java style for this, in java fully qualified names always work. >>In jython importing the top level packages is enough to get a similar >>effect. >> >>This is unlikely to change for backward compatibility reasons, at least >>from my POV. > > > While I appreciate the usage concerns, at some point someone has to > decide whether Jython is an implementation of Python, or a version of > BeanShell with odd syntax. this is mildy insulting, to the people that spent time trying to find the best compromises between various issues and keep jython alive. For example, I spent quite some energy at times to justify not implementing some unpythonic but tempting features from a java pov. > If it's Python, it has to comply with the > Python specification, regardless of what Java does. cpython cannot import java packages. also python rules don't translate completely to them, and sometimes python import semantics are as clear as mud and reading import.c is the only way to know. Of course allowing this for python packages was an overgeneralisation. > If it doesn't do > that, it should be cast into the outer darkness of the Python world. > this is a design decision that originates back to Jim. It could be limited maybe to java packages, but is sadly quite addictive. That's why I mentionted a backward compatibility problem. > The escape hatch here would be to redefine the Python specification to > allow either behavior. > > Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
[Brett] >> But I don't think this is trying to say they don't care. People just want >> to lower the overhead of maintaining the distro. [Fredrik] > well, wouldn't the best way to do that be to leave all non-trivial > maintenance of a > given component to an existing external community? > > (after all, the number of non-python-dev python contributors are *much* larger > than the number of python-dev contributors). > > I mean, we're not really talking about ordinary leak-elimination or > portability-fixing > or security-hole-plugging maintenance; it's the > let's-extend-the-api-in-incompatible- > ways and fork-because-we-can stuff that I'm worried about. Well, look at the changes Philip originally complained about: C:\Code\python\Lib\wsgiref>svn log -rHEAD:0 -v --stop-on-copy r46887 | phillip.eby | 2006-06-12 00:04:32 -0400 (Mon, 12 Jun 2006) | 2 lines Changed paths: ... Sync w/external release 0.1.2. Please see PEP 360 before making changes to external packages. r46855 | neal.norwitz | 2006-06-11 03:26:27 -0400 (Sun, 11 Jun 2006) | 1 line Changed paths: M /python/trunk/Lib/pkgutil.py M /python/trunk/Lib/wsgiref/validate.py Fix errors found by pychecker r46800 | andrew.kuchling | 2006-06-09 15:43:25 -0400 (Fri, 09 Jun 2006) | 1 line Changed paths: M /python/trunk/Lib/wsgiref/simple_server.py Remove unused variable r46794 | brett.cannon | 2006-06-09 14:40:46 -0400 (Fri, 09 Jun 2006) | 2 lines Changed paths: M /python/trunk/Lib/msilib M /python/trunk/Lib/test/crashers M /python/trunk/Lib/wsgiref svn:ignore .pyc and .pyo files. r46787 | tim.peters | 2006-06-09 13:47:00 -0400 (Fri, 09 Jun 2006) | 2 lines Changed paths: M /python/trunk/Lib/wsgiref/handlers.py M /python/trunk/Lib/wsgiref/headers.py M /python/trunk/Lib/wsgiref/simple_server.py M /python/trunk/Lib/wsgiref/util.py M /python/trunk/Lib/wsgiref/validate.py Whitespace normalization. That's all ordinary everyday maintenance, and, e.g., there is no mechanism to exempt anything in a checkout tree from reindent.py or PyChecker complaints. In addition, not shown above is that I changed test_wsgiref.py to stop a test failure under -O. Given that we're close to the next Python release, and test_wsgiref was the only -O test failure, I wasn't going to let that stand. I did wait ~30 hours between emailing about the problem and fixing it, but I like to whittle down my endless todo list too <0.4 wink>. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import semantics
Bill Janssen wrote: > If it's Python, it has to comply with the Python specification, > regardless of what Java does. what specification ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file()
On 6/12/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Yup, although it's a change in behavior that would need to be studied > > carefully for backwards incompatibilities. Usually it's given as a > > constant, so there won't be any problems; but there might be code that > > receives a mode string and attempts to test its validity by trying it > > and catching IOError, such code would have to be changed. > > > > --Guido > > > > On 6/12/06, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote: > >> I notice that file() throws an IOError when it detects an invalid mode > >> string. Wouldn't a ValueError be more appropriate? > > > > The situation is even more complex with the current trunk. open() raises > ValueError if it detects an invalid the mode string, such as universal > newline mode and a writable mode combined (the definition of > what is invalid has been made stricter, the mode string now must begin > with r, w, a or U), but it raises IOError if the OS call to fopen() fails > because of an invalid mode string. This might need unification. That would be hard to fix unless we get rid of the stdio-based implementation (which I intend to do in Py3k). I say we leave it alone for now -- fopen() can fail for any number of platform-dependent reasons and we can't really expect to do look-before-you-leap on this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file()
Guido van Rossum wrote: > On 6/12/06, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >> > Yup, although it's a change in behavior that would need to be studied >> > carefully for backwards incompatibilities. Usually it's given as a >> > constant, so there won't be any problems; but there might be code that >> > receives a mode string and attempts to test its validity by trying it >> > and catching IOError, such code would have to be changed. >> > >> > --Guido >> > >> > On 6/12/06, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote: >> >> I notice that file() throws an IOError when it detects an invalid mode >> >> string. Wouldn't a ValueError be more appropriate? >> > >> >> The situation is even more complex with the current trunk. open() raises >> ValueError if it detects an invalid the mode string, such as universal >> newline mode and a writable mode combined (the definition of >> what is invalid has been made stricter, the mode string now must begin >> with r, w, a or U), but it raises IOError if the OS call to fopen() fails >> because of an invalid mode string. This might need unification. > > That would be hard to fix unless we get rid of the stdio-based > implementation (which I intend to do in Py3k). I say we leave it alone > for now -- fopen() can fail for any number of platform-dependent > reasons and we can't really expect to do look-before-you-leap on this. One option would be to raise IOError in the former case too. That's what I meant with "unification". Cheers, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should hex() yield 'L' suffix for long numbers?
On 6/12/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Guido] > > Here's how I interpret PEP 237. Some changes to hex() and oct() are > > warned about in B1and to be implemented in B2. But I'm pretty sure > > that was about the treatment of negative numbers, not about the > > trailing 'L'. I believe the PEP authors overlooked the trailing 'L' > > for hex() and oct(). > > That was mentioned explicitly under "Incompatibilities" (last sentence): > > - Currently, the '%u', '%x', '%X' and '%o' string formatting > operators and the hex() and oct() built-in functions behave > differently for negative numbers: negative short ints are > formatted as unsigned C long, while negative long ints are > formatted with a minus sign. This will be changed to use the > long int semantics in all cases (but without the trailing 'L' > that currently distinguishes the output of hex() and oct() for > long ints). ... Oops, I missed that. > Since it wasn't mentioned explicitly again under "Transition", but the > trailing 'L' on repr() was explicitly mentioned twice under > "Transition", the least strained logic-chopping reading is that losing > the 'L' for hex() and oct() was intended to be done along with the > other changes in the paragraph quoted above. I now agree with that. > > I think they should be considered just as sticky as the trailing 'L' for > > repr(). > > Given that the "least strained" reading above missed its target > release, and the purpose of target releases was to minimize annoying > changes, I agree it should be left for P3K now regardless. I'll > change the PEP accordingly to make this explicit. Agreed again. Thanks for updating the PEP. PS Tim: did you get my private email about SequenceMatcher? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file()
No, because ValueError is the better exception for an invalid mode string. On 6/12/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On 6/12/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > >> Guido van Rossum wrote: > >> > Yup, although it's a change in behavior that would need to be studied > >> > carefully for backwards incompatibilities. Usually it's given as a > >> > constant, so there won't be any problems; but there might be code that > >> > receives a mode string and attempts to test its validity by trying it > >> > and catching IOError, such code would have to be changed. > >> > > >> > --Guido > >> > > >> > On 6/12/06, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote: > >> >> I notice that file() throws an IOError when it detects an invalid mode > >> >> string. Wouldn't a ValueError be more appropriate? > >> > > >> > >> The situation is even more complex with the current trunk. open() raises > >> ValueError if it detects an invalid the mode string, such as universal > >> newline mode and a writable mode combined (the definition of > >> what is invalid has been made stricter, the mode string now must begin > >> with r, w, a or U), but it raises IOError if the OS call to fopen() fails > >> because of an invalid mode string. This might need unification. > > > > That would be hard to fix unless we get rid of the stdio-based > > implementation (which I intend to do in Py3k). I say we leave it alone > > for now -- fopen() can fail for any number of platform-dependent > > reasons and we can't really expect to do look-before-you-leap on this. > > One option would be to raise IOError in the former case too. That's what > I meant with "unification". > > Cheers, > Georg > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
Guido van Rossum wrote: > developers contributing code without wanting > to give up control are the problem. That hits the nail on the head. If something is added to the standard library, it becomes part of Python and must be controlled by whoever controls Python. Otherwise there will be chaos. If a developer puts his code into the standard library, it may or may not increase their status, ego, or income. Each developer must decide for himself. I suggest that the BDFL make a Pronouncement on this subject. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import semantics
writes: > what [Python] specification? Good meta-point. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
On Mon, Jun 12, 2006 at 11:25:21AM -0700, Guido van Rossum wrote: > Have any instances of that actually happened? That would be a problem > with *any* code in the Python library, not just external > contributions, so I'm not sure why external contribions should be > treated any differently here. There have certainly been changes to xmlrpclib, such as support for datetime objects and an allow_none flag to support handling None values as a element. (I don't know if xmlrpclib is externally released any longer, so maybe it doesn't count.) --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
At 03:29 PM 6/12/2006 -0400, Tim Peters wrote: >That's all ordinary everyday maintenance, and, e.g., there is no >mechanism to exempt anything in a checkout tree from reindent.py or >PyChecker complaints. > >In addition, not shown above is that I changed test_wsgiref.py to stop >a test failure under -O. Given that we're close to the next Python >release, and test_wsgiref was the only -O test failure, I wasn't going >to let that stand. I did wait ~30 hours between emailing about the >problem and fixing it, but I like to whittle down my endless todo list >too <0.4 wink>. Your fix masked one of the *actual* problems, which was that wsgiref.validate (contributed by Ian Bicking) was also using asserts to check for validation failures. This required a more extensive fix. (See my reply to your problem report.) Your post about the error was on Friday afternoon; I had a corrected version on Sunday evening, but I couldn't check it in because nobody told me about any of the "ordinary everyday maintenance" they were doing, and I had to figure out how to merge the now-divergent trees. The whitespace changes I expected, since you previously told me about reindent.py. The other changes I did not expect, since my original message about the checkin requested that people at least keep me informed of changes (as does PEP 360), so I thought that people would abide by that or at least notify me if they found it necessary to make a change to e.g. fix a test. Your email about the test problem didn't say you were making any changes. Regardless of "everyday maintenance", my point was that I understood one procedure to be in effect, per PEP 360. If nobody's expected to actually pay any attention to that procedure, there's no point in having the PEP. Or if "everyday maintenance" is expected to be exempt, the PEP should reflect that. Assuming that everybody knows which rules do and don't count is a non-starter on a project the size of Python. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
On Mon, Jun 12, 2006 at 03:12:20PM -0400, Phillip J. Eby wrote: > encountered this myself. I *have* seen some developers make spurious > "cleanups" to working code that breaks compatibility with older Python > versions, though, just not in wsgiref. Note that the standard library policy has always been that the library for Python 2.X does not need to work with an earlier Python interpreter. Modules that must continue to work with earlier versions are listed in PEP 291. (Yes, another PEP to look at in addition to 360. IMHO we should require all modules with version constraints or external master source to have comments indicating this *in the code*, at the top of every source file, so that someone writing a patch or bugfix knows what the requirements are.) --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > Maybe we should get serious about slimming down the core distribution > > and having a separate group of people maintain sumo bundles containing > > Python and lots of other stuff. > > there are already lots of people doing that (most Linux distributions add > stuff, directly > or indirectly; ActiveState and Enthought are doing that for windows, Nokia is > doing > that for the S60 platform, etc); the PEP 360 approach is an attempt to > emulate that > for the python.org distribution. I'm not sure if it's a consequence of ActiveState's process, or of the current state of Python library packaging, or something else, but one big disadvantage I see to the ActiveState distribution is that it does not allow upgrading of parts of their distribution (specifically, I had problems because I couldn't upgrade pywin32 with a bugfix version, as it clashed with their bundled version - this was in the days when ActiveState releases were infrequent, and is probably much less of an issue now). Until that packaging issue is resolved (and again, maybe eggs provide the answer here, I'm not sure) externally packaged sumo bundles have some issues before they can fully replace the stdlib. I'd hate to distribute something that had to depend on "Enthought Python" because "ActiveState Python" was bundled with too old a release of pywin32 - or whatever. This is purely speculation (and fairly negative speculation at that!) but I'd advocate caution for a while yet. Maybe ActiveState or Enthought could provide some input on how/if sumo bundles can address the need to upgrade "parts" of the distribution? Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
On 6/12/06, Edward C. Jones <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > developers contributing code without wanting > > to give up control are the problem. > > That hits the nail on the head. If something is added to the standard > library, it becomes part of Python and must be controlled by whoever > controls Python. Otherwise there will be chaos. If a developer puts his > code into the standard library, it may or may not increase their status, > ego, or income. Each developer must decide for himself. > > I suggest that the BDFL make a Pronouncement on this subject. I think I pretty much did already -- going forward, I'd like to see that contributing something to the stdlib means that from then on maintenance is done using the same policies and guidelines as the rest of the stdlib (which are pretty conservative as far as new features go), and not subject to the original contributor's veto or prior permission. Rolling back changes without discussion is out of the question. (Sometimes it's okay to roll back a change unilaterall, but that's pretty much only if it breaks the unit tests and the original author does not respond to requests to fix his mistake within a reasonable time.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
On 6/12/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > IMHO we should > require all modules with version constraints or external master source > to have comments indicating this *in the code*, at the top of every > source file, so that someone writing a patch or bugfix knows what the > requirements are. Agreed. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
Martin v. Löwis wrote: > Guido van Rossum wrote: >>> 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want >>> to get rid of it, *now* would be the time. >> >> I'm all for it. >> >> While I am an enthusiastic supporter of several of those additions, I >> am *not* in favor of the special status granted to software >> contributed by certain developers, since it is a burden for all other >> developers. > > Then I guess we should deal with before 2.5b1, and delay 2.5b1 until the > status of each of these has been clarified. > > Each maintainer should indicate whether he is happy with a "this is > part of Python" approach. If so, the entry should be removed from PEP > 360 (*); if not, the code should be removed from Python before beta 1. I will be happy to say "ctypes is part of Python" (although I *fear* it is not one of the packages enthusiastically supported by Guido ;-). Well, if the compatibility requirements can be retained, at least (ctypes should currently be compatible with Python 2.3, but that can probably be raised to 2.4 when Python 2.5 is officially released, or shortly thereafter). I am *very* thankful for the fixes, the code review, the suggestions, and the encouragement I got by various python-devers. I'm even happy to revert changes by others done by accident (which destroy comatibility with Python 2.3, for example. Well, there was only one). Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "can't unpack IEEE 754 special value on non-IEEE platform"
I just ran the PIL test suite using the current Python trunk, and the tests for a user-contributed plugin raised an interesting exception: ValueError: can't unpack IEEE 754 special value on non-IEEE platform fixing this is easy, but the error is somewhat confusing: since when is a modern Intel CPU not an IEEE platform? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 12 Jun 2006 15:12:20 -0400 "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > Now, Barry's approach to the email package makes good sense to me, > and I'd use it, except that SVN externals can't sync individual > files. I'd have to create Lib/wsgiref/tests (and make a dummy > Lib/test/test_wsgiref that invokes them) Which is email had to do. > and Lib/wsgiref/doc (and make Doc/lib/lib.tex include libwsgiref.tex > from there). See mimelib.tex in Python's docs -- I had to do the same thing. The PITA is that I have to build the docs in Python's svn and then copy them into the sandbox for the standalone distro. This isn't to bad when it's just one package, but if we adopt this approach more generally, we may want to establish some guidelines, which of course I'd be happy to stick to. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iQCVAwUBRI3L23EjvBPtnXfVAQLAEwP/dQNcTatFUz7saxzRw2SEDKfDYTIsd0On WdLkNbhr5E85upOg/12DQLmyHAKNbxO2OFZo6VuO7AdHF2OTgp8S6aAzAlOUq9eF y1fiQ0Qfto3xCx4y1RYI9caZTJPuIN/1n8IHHt9Gkx+IsV+VDl+dhE3tVUP7RqAY XxTRzc/sCys= =AJ/r -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
Paul Moore wrote: > This is purely speculation (and fairly negative speculation at that!) > but I'd advocate caution for a while yet. Maybe ActiveState or > Enthought could provide some input on how/if sumo bundles can address > the need to upgrade "parts" of the distribution? We at Enthought are moving towards distributing a smallish bootstrap distribution and provide most of the packages as eggs. Upgrades should then be an easy_install away. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
On 6/12/06, Thomas Heller <[EMAIL PROTECTED]> wrote: > I will be happy to say "ctypes is part of Python" (although I *fear* it > is not one of the packages enthusiastically supported by Guido ;-). I don't plan to use it myself, but I'm very happy that it's in the stdlib since so many people like it. Somebody please update PEP 360 (and PEP 291). > Well, if the compatibility requirements can be retained, at least (ctypes > should currently be compatible with Python 2.3, but that can probably be > raised > to 2.4 when Python 2.5 is officially released, or shortly thereafter). That ought to be indicated in PEP 291 and in the ctypes source code somewhere. > I am *very* thankful for the fixes, the code review, the suggestions, > and the encouragement I got by various python-devers. You're welcome. And we're thankful for your contribution! > I'm even happy > to revert changes by others done by accident (which destroy comatibility > with Python 2.3, for example. Well, there was only one). Please keep in mind that reverting someone else's changes without prior discussion is a very rude thing to do. The proper procedure is to point out their mistake and give them the opportunity to revert it themselves (or defend their change -- so a public discussion can ensue). Disagreements should not be settled by battling checkins; I'd like to see that developers who ignore this rule repeatedly risk having their commit privileges taken away temporarily. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
Guido van Rossum wrote: > On 6/12/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> I will be happy to say "ctypes is part of Python" (although I *fear* it >> is not one of the packages enthusiastically supported by Guido ;-). > > I don't plan to use it myself, but I'm very happy that it's in the > stdlib since so many people like it. ;-) > Somebody please update PEP 360 (and PEP 291). I'll do that. >> Well, if the compatibility requirements can be retained, at least (ctypes >> should currently be compatible with Python 2.3, but that can probably be >> raised >> to 2.4 when Python 2.5 is officially released, or shortly thereafter). > > That ought to be indicated in PEP 291 and in the ctypes source code somewhere. I'll add markers in the code. >> I am *very* thankful for the fixes, the code review, the suggestions, >> and the encouragement I got by various python-devers. > > You're welcome. And we're thankful for your contribution! > >> I'm even happy >> to revert changes by others done by accident (which destroy comatibility >> with Python 2.3, for example. Well, there was only one). > > Please keep in mind that reverting someone else's changes without > prior discussion is a very rude thing to do. The proper procedure is > to point out their mistake and give them the opportunity to revert it > themselves (or defend their change -- so a public discussion can > ensue). > Disagreements should not be settled by battling checkins; I'd like to > see that developers who ignore this rule repeatedly risk having their > commit privileges taken away temporarily. Ok, I'll follow this procedure from now on. Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
[posting back to python-dev in case others also perceived my original message as impolite] At 01:25 PM 6/12/2006 -0700, Guido van Rossum wrote: >Oh, and the tone of your email was *not* polite. Messages starting >with "I wasted an hour of my time" are not polite pretty much by >definition. Actually, I started out with "please" -- twice, after having previously asked please in advance. I've also seen lots of messages on Python-Dev where Tim Peters wrote about having wasted time due to other folks not following established procedures, and I tried to emulate his tone. I guess I didn't do a very good job, but not everybody is as funny as Tim is. :) Usually he manages to make it seem as though he would really be happy to give up his nights and weekends but that sadly, he just doesn't have any more time right at this particular moment. A sort of "it's not you, it's me" thing. I guess I just left out that particular bit of sleight-of-mouth. :) Anyway, will anyone who was offended by the original message please pretend that it was delightfully witty and written by Tim instead? Thanks. ;) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
A01:01 PM 6/12/2006 -0700, Guido van Rossum wrote: >I think I pretty much did already -- going forward, I'd like to see >that contributing something to the stdlib means that from then on >maintenance is done using the same policies and guidelines as the rest >of the stdlib (which are pretty conservative as far as new features >go), and not subject to the original contributor's veto or prior >permission. Rolling back changes without discussion is out of the >question. I think there's some kind of misunderstanding here. I didn't ask for veto or prior permission. I just want to keep the external release in sync. I also didn't roll anything back, at least not intentionally. I was trying to merge the Python changes into the external release, and vice versa. Two-way syncing is difficult and error-prone, especially when you're thinking you only need to do a one-way sync! So if I managed to roll something back *un*intentionally in the process last night, I would hope someone would let me know. That was my sole complaint: I requested a particular change process to ensure that syncing would be one-way, from wsgiref to Python. If it has to be the other way, from Python to wsgiref, so be it. However, my impression from PEP 360 was that the way I was asking for was the "One Obvious Way" of doing it. This is not now, nor was it ever a control issue; I'd appreciate it if you'd stop implying that control has anything to do with it. At most, it's a widespread ignorance and/or misunderstanding as to the optimum way of handling stdlib packages with external distribution. It sounds like Barry has a potentially workable way of managing it that might reasonably be blessed as the One Obvious Way, and I'm certainly willing to try it. I'd still rather have a Packages/ directory, but beggars can't be choosers. However, if this is to be the One Obvious Way, it should be documented in a PEP as part of the "how packages get in the stdlib and how they're maintained". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
[Tim] >> In addition, not shown above is that I changed test_wsgiref.py to stop >> a test failure under -O. Given that we're close to the next Python >> release, and test_wsgiref was the only -O test failure, I wasn't going >> to let that stand. I did wait ~30 hours between emailing about the >> problem and fixing it, but I like to whittle down my endless todo list >> too <0.4 wink>. [Phillip] > Your fix masked one of the *actual* problems, which was that > wsgiref.validate (contributed by Ian Bicking) was also using asserts to > check for validation failures. This required a more extensive fix. (See > my reply to your problem report.) No, I didn't mask that. Two individual tests in test_wsgiref were failing under -O, and I only fixed one of them (testFileWrapper) at the time. In the checkin message for that (rev 46871), I noted that the other failure (test_simple_validation_error) was due to the coding of wsgiref.validate, and also noted that extensive changes would be needed to repair that one. The failure of the test I did repair was solely due to code in test_wsgiref.py. > Your post about the error was on Friday afternoon; I had a corrected > version on Sunday evening, but I couldn't check it in because nobody told > me about any of the "ordinary everyday maintenance" they were doing, and I > had to figure out how to merge the now-divergent trees. I'm sorry, but I don't think you can expect to get special email about these never-ending kinds of small changes. It's not realistic. They all show up on the python-checkins list, which you could filter (you are subscribed to that, right?). You could also use the svn command I showed last time to get a list of all checkins that have modified one of your files since the last time you blessed it. I know this is possible, since at one point I had to keep track of random changes to ZODB from copies in umpteen different branches of Zope2 and Zope3. I also know it's a PITA ;-) But AFAIK you have only _one_ "external copy" to keep track of now, and IME the pain grew more like the square of the number of external copies (each pair of external copies effectively had to get compared). > The whitespace changes I expected, since you previously told me about > reindent.py. The other changes I did not expect, since my original message > about the checkin requested that people at least keep me informed of > changes (as does PEP 360), so I thought that people would abide by that or > at least notify me if they found it necessary to make a change to e.g. fix > a test. Well, I don't pay any attention to which files reindent.py changes, so you'll never get special email from me about that. It looked like Brett's checkin was the result of some similarly mechanical "look for code directories that forgot to svn:ignore compiled Python files" process. Neal's PyChecker checkin also touched more than one subproject, and he probably plain forgot that anything with "wsgiref" in its path was supposed to get special treatment. These things simply will happen, and especially in more-or-less mindless cleanup checkins. > Your email about the test problem didn't say you were making any changes. There's also a rule that all tests must pass, and as a release grows close that gets higher priority. As I said, I waited about 30 hours, but got no response and saw no action, so moved it along simply because it needed to be repaired and I was able to make time for it. If you hadn't repaired test_simple_validation_error, I would have had no qualms about hacking in anything to stop that failure too before the release. If we had been "far" away from a release, I wouldn't have done anything here (beyond sending the email). > Regardless of "everyday maintenance", my point was that I understood one > procedure to be in effect, per PEP 360. If nobody's expected to actually > pay any attention to that procedure, there's no point in having the > PEP. Or if "everyday maintenance" is expected to be exempt, the PEP should > reflect that. Since that one is the only realistic outcome I can see, I think the PEP should say so. > Assuming that everybody knows which rules do and don't count is a non-starter > on a project the size of Python. I expect most rules will never be written down, either. This works fine so long as people of good will cooperate with liberal doses of common sense and tolerance. It doesn't work at all when the process gets adversarial. This project's traditional response to that hasn't been to craft ever-more legalistic rules (in part because nobody will volunteer for that), but to give the BDFL the last word on everything. Alas, that shows signs of not scaling well to dozens of active developers either. Short of freezing the code base and dropping support for buggy platforms like Linux ;-), I don't pretend to have a solution. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo
Re: [Python-Dev] External Package Maintenance
At 03:42 PM 6/12/2006 -0400, Edward C. Jones wrote: >Guido van Rossum wrote: > > developers contributing code without wanting > > to give up control are the problem. > >That hits the nail on the head. Actually it's both irrelevant and insulting. I just want changes made by the Python core developers to be reflected in the external releases. I'd be more than happy to move the external release to the Python SVN server if that would make it happen. If there was only one release point for the package, I would've had no problem with any of the changes made by Tim or AMK or anybody else. The "control" argument is a total red herring. If I had an issue with the actual changes themselves, I'd address it on checkins or dev, as is normal! The "nail" here is simply that maintaining two versions of a package is awkward if changes are being made in both places. I'd love to have only one place in which wsgiref is maintained, but Python's current directory layout doesn't allow me to put all of wsgiref in "one place". And if we hit *that* "nail" on the head (instead of hitting the external authors on theirs), it is a win for all the external contributors. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
Phillip J. Eby wrote: > I'd still rather have a Packages/ directory, but beggars can't be > choosers. there's plenty of time to work on that for 2.6... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "can't unpack IEEE 754 special value on non-IEEE platform"
[Fredrik Lundh]
> I just ran the PIL test suite using the current Python trunk, and the
> tests for a user-contributed plugin raised an interesting exception:
>
> ValueError: can't unpack IEEE 754 special value on non-IEEE platform
>
> fixing this is easy, but the error is somewhat confusing: since when is
> a modern Intel CPU not an IEEE platform?
Which OS and compiler were in use? A possible cause is that the
platform didn't supply #defines for SIZEOF_DOUBLE and/or SIZEOF_FLOAT
when Python was compiled. This was, e.g., true on Windows before rev
46065.
On an Intel box, you should see this:
>>> float.__getformat__('double')
'IEEE, little-endian'
If you get 'unknown' instead, see above.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: Phillip J. Eby wrote:> I'd still rather have a Packages/ directory, but beggars can't be > choosers.there's plenty of time to work on that for 2.6...I have started a thread on python-3000 to try to get a PEP pulled together to solidify what we want for accepted PEPs and thus lock down what is expected. I purposely started out heavy-handed to get discussion going to get some back and forth going to work something out. Started the thread there instead of here since I hope the resulting PEP can be used to help decide what modules should be ripped out in Py3K. We can then use the guidelines for future acceptance for the 2.x branch. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
Phillip J. Eby wrote: > I just want changes made by the Python core developers to be reflected in > the external releases. and presumably, the reason for that isn't that you care about your ego, but that you care about your users. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "can't unpack IEEE 754 special value on non-IEEE platform"
Tim Peters wrote: > Which OS and compiler were in use? A possible cause is that the > platform didn't supply #defines for SIZEOF_DOUBLE and/or SIZEOF_FLOAT > when Python was compiled. This was, e.g., true on Windows before rev > 46065. and looking again, I was indeed running 2.5 alpha 2 (revision 45740), not 2.5 trunk. oh well. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
On 6/12/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: Perhaps issues like these should motivate us to consider a differentsource control tool. There's a new crop of tools out that could solvethis by having multiple repositories that can be sync'ed with eachother. This sounds like an important move towards world peace! It would be an important move towards world peace, if it didn't inspire whole new SCM-holy-wars :-) I have a fair bit of experience with different SCM (VC, source control tool, however you want to call them) so I'll take this opportunity to toss up some observations. Not that switching to another SCM will really solve the issues you are referring to, but I happen to think switching to another SCM is a great idea :) Although I don't see an obvious candidate at the moment... I'll explain why. First of all, changing SCM means changing how everyone works. It's nothing like the CVS->Subversion switch, which changed very little in workflow. All the cool SCMs use 'real branches', and to get full benefit you have to switch your development to a 'branch oriented model', if you'll pardon the buzzwordyness. At XS4ALL we've used BitKeeper for a few years now, and while it really took a while for some of the developers to catch on, the branch thing makes parallel development *much* easier. If you haven't experienced it yourself, it's hard to see why it matters so much (except maybe in cases with extreme parallel development, like the Linux kernel), but it really does make life a lot easier in the long run, for programmers and release managers. Secondly, the way most of the 'less-linear' SCMs work is that everyone has their own repository. That is, in fact, what makes it so useful -- no need for central repository access, no need for a network connection for full operability, no need for write access to get your changes checked in (locally), and easy interchanging between repositories. With a large (history-rich) project like Python, though, those repositories can get a tad large. Most of the SCMs have ways to work around it (not downloading the full history, side-storing the full history in a separate branch, etc) but it's still an extra inconvenience. Now, me, I don't mind downloading a couple hundred megabytes to get a 25Mb sourcetree with full history, but I have a 1Gbit link to the python.org servers :) On the other hand, with most of the SCMs, you only download that full history once, and then locally branch off of that.The real reason I think we should consider other SCMs is because I fear what the history will look like when 3.0 is done. In Subversion, merges of branches don't preserve history -- you have to do it yourself. Given the way Subversion works, I don't think that'll really change; it's just not what Subversion is meant to do (and that's fine.) It does mean, however, that when we switch the trunk to 3.0, we have to decide between the history of the trunk or the history of the p3yk branch. We either merge the p3yk branch into the trunk, making a single huge checkin message explaining all the changes (or not), or we swap the trunk and the p3yk branch. The former means 'svn blamelog', for instance, will show a single revision and a single author for *all* p3yk changes. The latter means 'svn blamelog' will group the trunk changes into the merge commits you can already see on the python-3000-checkins list: a block of merges at a time, based on whenever I (or someone else) has the time to merge the trunk in. So, in that case, 'svn blamelog' will show *me* as author of all 2.5-to-2.7 changes, at a time the original change didn't go in, with log messages that are largely irrelevant ;-) And the mess gets bigger if part of p3yk or trunk's development is done in other branches -- svnmerge log messages hidden in svnmerge log messages. ugh. Before XS4ALL switched to BitKeeper, I spent quite a while examining different SCMs, but at the time, they just weren't at the stage of development you'd trust your company development to (not if you can afford BitKeeper anyway ;) After (re-)experiencing the pain that is Subversion/CVS-style branching with the p3yk branch and the manual trunk merges, I went ahead and checked out the current state of the alternatives. There are quite a few, now (Monotone, Darcs, Git/Cogito, Mercurial, Arch/tla/Bazaar, Bazaar-NG, Arx, CodeVille, SVK) and I haven't had time to give them all the in-depth examination they are worthy of, but so far it looks like only a few of them currently scale well enough to handle a large (history-rich) project like Python. Not that it's fair to expect them to scale well, mind you, given that most of them are only a few years old and most don't claim to be " 1.0".Using 'tailor' ( http://www.darcs.net/DarcsWiki/Tailor ) I imported the Python sourcetree with full history into Darcs and Git. I also did a partial import into Monotone (history going back a few months) -- the Monotone import was a lot slower than the others, and I didn't feel like
Re: [Python-Dev] Switch statement
Maybe "switch" became a keyword with the patch.. Regards, Michael On 6/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Thomas Lee wrote: > > Hi all, > > > > As the subject of this e-mail says, the attached patch adds a "switch" > > statement to the Python language. > > > > However, I've been reading through PEP 275 and it seems that the PEP > > calls for a new opcode - SWITCH - to be added to support the new > > construct. > > > > I got a bit lost as to why the SWITCH opcode is necessary for the > > implementation of the PEP. The reasoning seems to be > > improving performance, but I'm not sure how a new opcode could improve > > performance. > > > > Anybody care to take the time to explain this to me, perhaps within the > > context of my patch? > > Could you upload your patch to SourceForge ? Then I could add > it to the PEP. > > Thomas wrote a patch which implemented the switch statement > using an opcode. The reason was probably that switch works > a lot like e.g. the for-loop which also opens a new block. > > Could you explain how your patch works ? > > BTW, I think this part doesn't belong into the patch: > > > Index: Lib/distutils/extension.py > > === > > --- Lib/distutils/extension.py(revision 46818) > > +++ Lib/distutils/extension.py(working copy) > > @@ -185,31 +185,31 @@ > > continue > > > > suffix = os.path.splitext(word)[1] > > -switch = word[0:2] ; value = word[2:] > > +switch_word = word[0:2] ; value = word[2:] > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jun 12 2006) > >>> Python/Zope Consulting and Support ...http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ > > 2006-07-03: EuroPython 2006, CERN, Switzerland 20 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
On 6/12/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: On 6/12/06, Guido van Rossum <[EMAIL PROTECTED] > wrote: Perhaps issues like these should motivate us to consider a differentsource control tool. There's a new crop of tools out that could solvethis by having multiple repositories that can be sync'ed with eachother. This sounds like an important move towards world peace! It would be an important move towards world peace, if it didn't inspire whole new SCM-holy-wars :-) I have a fair bit of experience with different SCM (VC, source control tool, however you want to call them) so I'll take this opportunity to toss up some observations. Not that switching to another SCM will really solve the issues you are referring to, but I happen to think switching to another SCM is a great idea :) Although I don't see an obvious candidate at the moment... I'll explain why. First of all, changing SCM means changing how everyone works. It's nothing like the CVS->Subversion switch, which changed very little in workflow. All the cool SCMs use 'real branches', and to get full benefit you have to switch your development to a 'branch oriented model', if you'll pardon the buzzwordyness. At XS4ALL we've used BitKeeper for a few years now, and while it really took a while for some of the developers to catch on, the branch thing makes parallel development *much* easier. If you haven't experienced it yourself, it's hard to see why it matters so much (except maybe in cases with extreme parallel development, like the Linux kernel), but it really does make life a lot easier in the long run, for programmers and release managers. Secondly, the way most of the 'less-linear' SCMs work is that everyone has their own repository. That is, in fact, what makes it so useful -- no need for central repository access, no need for a network connection for full operability, no need for write access to get your changes checked in (locally), and easy interchanging between repositories. With a large (history-rich) project like Python, though, those repositories can get a tad large. Most of the SCMs have ways to work around it (not downloading the full history, side-storing the full history in a separate branch, etc) but it's still an extra inconvenience. Now, me, I don't mind downloading a couple hundred megabytes to get a 25Mb sourcetree with full history, but I have a 1Gbit link to the python.org servers :) On the other hand, with most of the SCMs, you only download that full history once, and then locally branch off of that. The real reason I think we should consider other SCMs is because I fear what the history will look like when 3.0 is done. In Subversion, merges of branches don't preserve history -- you have to do it yourself. Given the way Subversion works, I don't think that'll really change; it's just not what Subversion is meant to do (and that's fine.) It does mean, however, that when we switch the trunk to 3.0, we have to decide between the history of the trunk or the history of the p3yk branch. We either merge the p3yk branch into the trunk, making a single huge checkin message explaining all the changes (or not), or we swap the trunk and the p3yk branch. The former means 'svn blamelog', for instance, will show a single revision and a single author for *all* p3yk changes. The latter means 'svn blamelog' will group the trunk changes into the merge commits you can already see on the python-3000-checkins list: a block of merges at a time, based on whenever I (or someone else) has the time to merge the trunk in. So, in that case, 'svn blamelog' will show *me* as author of all 2.5-to-2.7 changes, at a time the original change didn't go in, with log messages that are largely irrelevant ;-) And the mess gets bigger if part of p3yk or trunk's development is done in other branches -- svnmerge log messages hidden in svnmerge log messages. ugh. Before XS4ALL switched to BitKeeper, I spent quite a while examining different SCMs, but at the time, they just weren't at the stage of development you'd trust your company development to (not if you can afford BitKeeper anyway ;) After (re-)experiencing the pain that is Subversion/CVS-style branching with the p3yk branch and the manual trunk merges, I went ahead and checked out the current state of the alternatives. There are quite a few, now (Monotone, Darcs, Git/Cogito, Mercurial, Arch/tla/Bazaar, Bazaar-NG, Arx, CodeVille, SVK) and I haven't had time to give them all the in-depth examination they are worthy of, but so far it looks like only a few of them currently scale well enough to handle a large (history-rich) project like Python. Not that it's fair to expect them to scale well, mind you, given that most of them are only a few years old and most don't claim to be " 1.0".Using 'tailor' ( http://www.darcs.net/DarcsWiki/Tailor ) I imported the Python sourcetree with full history into Darcs and Git. I also did a partial import into Monotone (history going back a few months) -- the Monotone import
Re: [Python-Dev] Source control tools
On 6/12/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > [*] Short? This whole mail was short! I can talk for hours about the benefit > of proper branches and what kind of stuff is easier, better and more > efficient with them. I can draw huge ASCII diagrams explaining the > fundamental difference between CVS/SVN, > BitKeeper/Arch/Darcs/Bazaar-NG/Mercurial and Monotone (yes, > that's three groups), and I have powerpoint(!) sheets I used to give a > presentation about how and why BitKeeper works at work. It's probably a bit > off-topic here, though, so don't tempt me ;P Will you be at EuroPython? This might be a good OpenSpace topic if you haven't already secured your speaking slot. It so happens that I saw a talk about Mercurial at last week's baypiggies meeting and the author claimed that it's as fast as Git. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "can't unpack IEEE 754 special value on non-IEEE platform"
Fredrik Lundh <[EMAIL PROTECTED]> writes:
> I just ran the PIL test suite using the current Python trunk, and the
> tests for a user-contributed plugin raised an interesting exception:
>
> ValueError: can't unpack IEEE 754 special value on non-IEEE platform
>
> fixing this is easy, but the error is somewhat confusing: since when is
> a modern Intel CPU not an IEEE platform?
When it doesn't define SIZEOF_DOUBLE or maybe SIZEOF_FLOAT, IIRC. But
I thought Tim fixed this, so I'm reduced to guessing again. Some
questions that will help me help you:
* What OS/compiler/etc?
* What is the user plugin doing (i.e. is it C or Python)?
* Any chance of a minimal example (if it's Python code, it'll be
struct usage, most likely, if C, one of _PyFloat_Unpack{4,8} or
something that calls one of those)?
* What does [float.__getformat__(f) for f in ('float', 'double')] say?
Cheers,
mwh
--
Just put the user directories on a 486 with deadrat7.1 and turn the
Octane into the afforementioned beer fridge and keep it in your
office. The lusers won't notice the difference, except that you're
more cheery during office hours. -- Pim van Riezen, asr
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
On Mon, Jun 12, 2006 at 11:31:14PM +0200, Thomas Wouters wrote: > First of all, changing SCM means changing how everyone works. Distributed branches is not the only requirement. There are also: -- subtree authorization (different access rights in different parts of the tree); in distributed SCMs this is solved by policies, not by tools, as far as I understand; -- web-based access (ViewCV or like); -- tracker integration (like Subversion with Trac); -- mail notification. Slightly offtopic: I am working for a company where developers work in different OS (Linux, w32, FreeBSD) and speak different languages (Russian, Latvian and English). Two features I really love in Subversion: svn:mime-type and svn:eol-style. The former allows to set character encoding for a file (useful for web-based access); the latter allow SVN to automatically convert line endings between different OSes, but it also allow to set a fixed line ending style for specific files. I don't know another SCM that supports such useful features. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
Fredrik Lundh wrote: >> But I don't think this is trying to say they don't care. People just want >> to lower the overhead of maintaining the distro. > > well, wouldn't the best way to do that be to leave all non-trivial > maintenance of a > given component to an existing external community? If you remember that this is the procedure: sure. However, if the maintainer of a package thinks (and says) "somebody edited my code, this should not happen again", then I really think the code is better not part of the Python distribution. > I mean, we're not really talking about ordinary leak-elimination or > portability-fixing > or security-hole-plugging maintenance; it's the > let's-extend-the-api-in-incompatible- > ways and fork-because-we-can stuff that I'm worried about. I can understand that (and supported it in the first place, as you may well recall). You should decide whether you worry about that so much that you don't trust python-dev contributors to treat this in a sensible way. If you don't trust them, you should withdraw your code. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
On 6/13/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote: On Mon, Jun 12, 2006 at 11:31:14PM +0200, Thomas Wouters wrote:> First of all, changing SCM means changing how everyone works. Distributed branches is not the only requirement. Oh, I know, no worries about that. There are also:-- subtree authorization (different access rights in different parts of the tree); in distributed SCMs this is solved by policies, not by tools, as far as I understand;Pretty much a no-brainer in most SCMs, yes: you need privileges to push certain changes to a repository, not to commit them locally. The receiving repository can make as complicated an authentication and authorization step as it wants. Monotone's approach to this is particularly enjoyable: it works with digital signatures, and you can (have to) tell Monotone who's checkins *you* trust ;) -- web-based access (ViewCV or like); -- tracker integration (like Subversion with Trac);-- mail notification.All of these are of course requirements before Python can switch to another SCM, but not for looking at them in the first place -- in most cases, it's not hard to add, if they don't have it already. And besides, while svn has trac integration, we don't actually use it (yet). Slightly offtopic: I am working for a company where developers work indifferent OS (Linux, w32, FreeBSD) and speak different languages (Russian, Latvian and English). Two features I really love in Subversion:svn:mime-type and svn:eol-style. The former allows to set characterencoding for a file (useful for web-based access); the latter allow SVN toautomatically convert line endings between different OSes, but it also allow to set a fixed line ending style for specific files. I don't knowanother SCM that supports such useful features.Those two I actually consider more important features than the three you mentioned above -- as they aren't as easily bolted-on. Thanks, I'll keep them in mind :) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
Brett Cannon wrote: > Well, I don't know if that is necessarily the case. PEP 360 doesn't > have a single project saying that minor fixes can just go right in. If > we want to just change the wording such that all code in the tree can be > touched for bug fixes and compatibility issues without clearance, that's > great. I think this is what Philipp Eby essentially said about wsgiref (re-read the subject line for reference). If the external maintainer really has a strict "don't change anything" policy, the only reasonable way to enforce this policy is to withdraw the code. > But Phillip's email that sparked all of this was about basic changes to > wsgiref, not some API change (at least to the best of my knowledge). That's my understanding as well. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
Phillip J. Eby wrote: > Actually it's both irrelevant and insulting. > > I just want changes made by the Python core developers to be reflected in > the external releases. I'd be more than happy to move the external release > to the Python SVN server if that would make it happen. > I think the only way to guarantee that is that you track the Python source code yourself. Here is how I did it with PyXML: - whenever I want a two-way sync, I first look at the changes that happened in Python since the last two-way sync. - of those changes, I eliminate all that where already applied to PyXML. I had the habit of using identical checkin messages, so it was easy to identify which changes already existed in the other tree. - I applied the remaining changes, one by one, to PyXML (but with a single commit), using the same commit messages, and indicating that PyXML was syncronized up to revsion XY with Python. - Then I copied all remaining changes from PyXML to Python, again indicating in the commit messages what the original changes were, and how they got synchronized. Ideally, the PyXML sources and the Python sources should now be identical, byte for byte. Of course, this approach recently broke when byte-for-byte identity was deliberately broken; until then, it worked fine for several years. > The "nail" here is simply that maintaining two versions of a package is > awkward if changes are being made in both places. I'd love to have only > one place in which wsgiref is maintained, but Python's current directory > layout doesn't allow me to put all of wsgiref in "one place". I guess you just have to accept that. It will happen again. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
Fredrik Lundh wrote: >> I just want changes made by the Python core developers to be reflected in >> the external releases. > > and presumably, the reason for that isn't that you care about your ego, > but that you care about your users. For that, yes. However, the reason to desire that no changes are made to Python's wsgiref is just that he wants to reduce the amount of work he has to do to keep the sources synchronized - which reduces his amount of work, but unfortunately increases the amount of work to be done for the other python-dev committers. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
[EMAIL PROTECTED] wrote: > > > Greg> Before accepting this, we could do with some debate about the > Greg> syntax. It's not a priori clear that C-style switch/case is the > Greg> best thing to adopt. > > Oh sure. That debate should probably leverage PEP 275. Along the lines of PEP 275, one of my concerns with the use of a switch/case automatic conversion or even explicit syntax is that of low-hanging fruit... In my experience, switch/case statements are generally used to either structure code explicitly with state handling code, improve performance of such state handling, or both. I think that if we are going to be modifying Python to include such a syntax or automatic conversion, those standard use-cases be considered primary. With that said, the low-hanging fruit, in my opinion, are precisely those cases specified in PEP 275 in the Solution 1 option. For the majority of use-cases that I've seen, automatic conversion for the if/elif/else blocks with a hash table would cover this low-hanging fruit, and would be a nice transparent optimization. One other nice thing about such an optimization is that it could work fine for known-immutable types (strings, ints, ...), and with work, could preserve previous behavior for not-known-immutable types.* - Josiah * This would basically work by compiling the if/elif/else block normally, adding a type check for the switched-on item, on success, switch to just after the comparison operator in the if/elif/else bodies, and on failure, proceed to the first comparison. To handle the case of if x.i ==...: ... elif x.i == ...: ..., we could state that the optimization will only occur if the 'switched on' value is a bare name (x is OK, x.i and x[i] are not). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 issues need resolving in a few days
Guido van Rossum wrote: > PyXML appears pretty stable (in terms of release frequency -- I have > no opinion on the code quality :-). Perhaps it could just be > incorporated into the Python svn tree, if the various owners are > willing to sign a contributor statement? That is, in itself, a medium-sized project. There are many components to PyXML, and finding all the authors might be a challenge already. Some code is outdated, and part of PyXML only to support old applications; that should not be moved into Python. Some code is still incomplete. I used to say it's "work in progress", but for some of it, that isn't really true. Still, there are users of these pieces as well. The only parts that I personally would like to see in Python is some XPath implementation, and some XSLT implementation. Others might have other preferences, of course. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
Phillip J. Eby wrote: > [posting back to python-dev in case others also perceived my original > message as impolite] > > At 01:25 PM 6/12/2006 -0700, Guido van Rossum wrote: > >>Oh, and the tone of your email was *not* polite. Messages starting >>with "I wasted an hour of my time" are not polite pretty much by >>definition. > > > Actually, I started out with "please" -- twice, after having previously > asked please in advance. I've also seen lots of messages on Python-Dev > where Tim Peters wrote about having wasted time due to other folks not > following established procedures, and I tried to emulate his tone. I guess > I didn't do a very good job, but not everybody is as funny as Tim is. :) > > Usually he manages to make it seem as though he would really be happy to > give up his nights and weekends but that sadly, he just doesn't have any > more time right at this particular moment. A sort of "it's not you, it's > me" thing. I guess I just left out that particular bit of > sleight-of-mouth. :) > > Anyway, will anyone who was offended by the original message please pretend > that it was delightfully witty and written by Tim instead? Thanks. ;) > I wonder what the hell's up with Tim. He's been really crabby lately ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Love me, love my blog http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
At 12:28 AM 6/13/2006 +0200, Martin v. Löwis wrote: >If you remember that this is the procedure: sure. However, if the >maintainer of a package thinks (and says) "somebody edited my code, >this should not happen again", then I really think the code is better >not part of the Python distribution. The "this should not happen again" in this case was the *merge problem*, not the *editing*. There is a significant difference between the two. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
At 12:56 AM 6/13/2006 +0200, Martin v. Löwis wrote: >Fredrik Lundh wrote: > >> I just want changes made by the Python core developers to be reflected in > >> the external releases. > > > > and presumably, the reason for that isn't that you care about your ego, > > but that you care about your users. > >For that, yes. However, the reason to desire that no changes are made >to Python's wsgiref is just that he wants to reduce the amount of work >he has to do to keep the sources synchronized - which reduces his amount >of work, but unfortunately increases the amount of work to be done for >the other python-dev committers. I see *now* why that would appear to be the case. However, my previous assumption was that if somebody found a bug, they'd tell me about it and I'd do the work of fixing it, updating the tests, etc. In other words, I was willing to do *all* the work, for changes that made sense to wsgiref. What I didn't really "get" until now is that people might be making Python-wide changes that don't have anything to do with wsgiref per se, and that is the place where the increased work comes in. This should definitely be explained to authors who are donating libraries to the stdlib, because from my perspective it seemed to me that I was graciously volunteering to be responsible for *all* the work related to wsgiref. (And yes, I understand now why it doesn't actually work that way.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
At 12:09 AM 6/13/2006 +0100, Steve Holden wrote: >Phillip J. Eby wrote: > > Anyway, will anyone who was offended by the original message please > pretend > > that it was delightfully witty and written by Tim instead? Thanks. ;) > > >I wonder what the hell's up with Tim. He's been really crabby lately ... It's probably all that time he's been spending tracking down the wsgiref test failures. ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)
Phillip J. Eby wrote: > At 12:28 AM 6/13/2006 +0200, Martin v. Löwis wrote: >> If you remember that this is the procedure: sure. However, if the >> maintainer of a package thinks (and says) "somebody edited my code, >> this should not happen again", then I really think the code is better >> not part of the Python distribution. > > The "this should not happen again" in this case was the *merge problem*, > not the *editing*. There is a significant difference between the two. Well, you wrote, in http://mail.python.org/pipermail/python-dev/2006-June/065908.html "only to find that it doesn't correspond to any particular point in the trunk, because people made changes without contacting me or the Web-SIG. ... Please don't do this again." (where the three dots indicate something that you have done, not somebody else) >From that, I can only conclude that you requested that people should not make changes again without contacting you or the Web-SIG. It's not clear whether you want to be contacted before or after the changes have been made. If "after" is ok, you should just subscribe to python-checkins. Still, Guido dislikes the notion of having to contact anybody when making changes, as a matter of principle. I can sympathize with that view. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
Boris Borcic <[EMAIL PROTECTED]> wrote: > Hello, > > Armin Rigo wrote: > > Hi, > > > > On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote: > >> I just submitted http://python.org/sf/1501934 and assigned it to Neal so it > >> doesn't get forgotten before 2.5 goes out ;) It seems Python 2.5 compiles > >> the following code incorrectly: > > > > No, no, it's an underground move by Jeremy to allow assignment to > > variables of enclosing scopes: > ... > > Credits to Samuele's evil side for the ideas. His non-evil side doesn't > > agree, and neither does mine, of course :-) > ... > > More seriously, a function with a variable that is only written to as > > the target of augmented assignments cannot possibly be something else > > than a newcomer's mistake: the augmented assignments will always raise > > UnboundLocalError. > > I am not really a newcomer to python. But lately I find myself regularly > bitten > by this compiler behavior that I tend to view as a (design) bug. This started > happening after I saw that sets are just as good as lists performance-wise > and I > began changing code like this I see your attempted use of a closure as a design bug in your code. Remember that while closures can be quite convenient, there are other methods to do precisely the same thing without needing to use nested scopes. I find that it would be far easier (for the developers of Python) and significantly more readable if it were implemented as a class. class solve: def __init__(self, problem): self.freebits = ... ... def search(self, data): ... self.freebits ^= swaps ... ... Not everything needs to (or should) be a closure - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] socket._socketobject.close() doesn't really close sockets
In implementing the IronPython _socket module, I've discovered some puzzling behavior in the standard Python socket wrapper module: socket._socketobject.close() doesn't actually close sockets; rather, it just sets _sock to an instance of _closedsocket and lets the GC clean up the real socket. (See socket.py around line 160.) This works fine with a reference counting GC, but can potentially leave sockets hanging around for a long time on platforms (e.g. the CLR) with other GC algorithms. It causes most of the socket unit tests to fail on IronPython. Is there a reason for this implementation? This patch to _socketobject.close() makes socket.py work with IronPython: def close(self): +if not isinstance(self._sock, _closedsocket): +self._sock.close() self._sock = _closedsocket() self.send = self.recv = self.sendto = self.recvfrom = self._sock._dummy --Bruce ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] External Package Maintenance
Phillip J. Eby wrote: > This should definitely be explained to authors who are donating > libraries to the stdlib, because from my perspective it seemed to me > that I was graciously volunteering to be responsible for *all* the work > related to wsgiref. It's not only about python-wide changes. It is also for regular error corrections: whenever I commit a bug fix that somebody contributed, I now have to understand the code, and the bug, and the fix. Under PEP 360, I have to do all of these, *plus* checking PEP 360 to determine whether I will step on somebodies' toes. I also have to consult PEP 291, of course, to find out whether the code has additional compatibility requirements. I currently mostly manage to do this all because I remember (in brain) whether something is externally maintained, and how to proceed in this case. However, I can see how this doesn't scale. So ideally, I would like to see the external maintainers state "we can deal with occasional breakage arising from somebody forgetting the procedures". This would scale, as it would put the responsibility for the code on the shoulders of the maintainer. It appears that Thomas Heller says this would work for him, and it worked for bsddb and PyXML. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
