Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
On Jan 10, 2008 8:01 AM, Joseph Armbruster <[EMAIL PROTECTED]> wrote: > I am not a developer but i'm interested in browsing it. Is it > possible to be added? Yes, I've added you to the list. I'll probably send the list off tomorrow, so let me know if you would like to be added. n -- > > > On Jan 10, 2008 10:57 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Neal Norwitz wrote: > > > I think only Coverity can add people. You can send them a message if > > > you would like to be added: [EMAIL PROTECTED] Or you can send > > > mail to me and I can forward along all the people that would like to > > > be added. > > > > > > I'll wait a few days to collect names so I can batch up the request. > > > > Count me in! > > > > Christian > > > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.com > > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Reed O'Brien wrote: > On Jan 9, 2008, at 1:48 AM, Jeroen Ruigrok van der Werven wrote: >> -On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote: >>> Python's _winreg module and pywin32 expose several functions to >>> get the paths from the registry but I don't think it has a simple >>> function like get_mydocuments(). >> Careful with the name though. Microsoft Windows Vista did away with >> 'My Documents & Settings'. It is now C:\Users. >> >> So you get: >> C:\Users\\AppData\Local\ (former Local Settings\Application Data) >> C:\Users\\AppData\Roaming\ (former Application Data) >> C:\Users\\Documents(former My Documents) >> C:\Users\\Music(former My Music) >> C:\Users\\Pictures (former My Pictures) >> C:\Users\\Videos (former My Videos) > yay, next up posix support I suspect that the whole thing was done to make sure that developers of applications could: A: cope with stupidly long path names. V: cope with spaces in path names. I bet they never intended to keep the huge names, just to make you cope with them. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
At 12:08 AM 1/11/2008 +0100, Christian Heimes wrote: >Phillip J. Eby wrote: > > Yes, that's the general idea. But what happens if you are in the middle > > of firing hooks for 'a', and a new hook for 'a.b.c' is added? What > > about a new hook for 'a'? > >If 'a' registers a new hook for a child of 'a' (e.g. 'a.b.c' or 'a.f') >then the new hooks are called with the remaining hooks for 'a.b.c': > >import a.b.c >* hook_a1 >* hook_a1 -> registers the hook_ab2 for 'a.b' >* hook_ab1 -> registers a hook_aX for 'a' >hook_aX is fired immediately >* hook_ab2 -- the hook registered by hook_a1 This scenario isn't specific enough to produce/deduce the problem. > > Well, it certainly can (and should) do the same if a module object is > > provided, since the module has a __name__. > >Maybe I should add two methods to imp. One that calls the parent hooks >of a module automatically but relies on the existence of the parents and >the module in sys.modules. >And a second method which calls the hooks for a module object w/o >inspecting sys.modules. *sigh*. We seem to be getting further and further off course, here. The more different you make the semantics of the system, the harder it will be to verify that it's doing the right thing without having real field experience with the new approach. > > Only if you can guarantee that no hook for a submodule is run until all > > the parent hooks are finished being called *and* that adding new > > callbacks while callbacks are being run will still call them... *after* > > any already-added callbacks. > >Uhm, now it starts to become a mind bending problem. I may have to queue >and delay the registration of new hooks while other hooks are called by >the system. If an user registers a callback for 'a' while the callbacks >for 'a' are called than the registration is queued and the called after >the remaining hooks for 'a' are called. This could probably be >implemented by *not* setting the entry to None after I get hold of the >iterator but after the end of the iteration. iter() notices when a new >element is appended. Yep - that's precisely what peak.util.imports does, and is why it does it that way. However, it has other ways of guaranteeing that the notification callback occurs only once, because the module object keeps track of that. >In the above sample can hook_aX be called after hook_ab1 or should it be >called after hook_ab2? That question can't be answered from the limited information you supplied about the scenario. What must not happen is that hook_aX must not be called before any *already-registered* hooks for 'a'. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
At 01:47 AM 1/11/2008 +0100, Christian Heimes wrote: >Phillip J. Eby wrote: > > At 11:45 PM 1/10/2008 +0100, Christian Heimes wrote: > >> In my version a hook is immediately called when the the registry value > >> is set to None. When a hook is registered for a module during the > >> execution of the callback then the hook is fired directly and not after > >> the existing hooks are called. Is this a problem for you? > > > > Yes, because it violates the invariant that hooks for a given module > > are called in the same order that they were registered in. > >Please check the changes and the new unit test in r59902 ( >http://svn.python.org/view?rev=59902&view=rev ). Are you satisfied with >the ordering or do you think I should queue the hooks for already loaded >modules? As I said above, calling the callbacks immediately is a problem, because it leads to significantly less predictability (and therefore control) of callback order. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
Phillip J. Eby wrote: > At 11:45 PM 1/10/2008 +0100, Christian Heimes wrote: >> In my version a hook is immediately called when the the registry value >> is set to None. When a hook is registered for a module during the >> execution of the callback then the hook is fired directly and not after >> the existing hooks are called. Is this a problem for you? > > Yes, because it violates the invariant that hooks for a given module > are called in the same order that they were registered in. Please check the changes and the new unit test in r59902 ( http://svn.python.org/view?rev=59902&view=rev ). Are you satisfied with the ordering or do you think I should queue the hooks for already loaded modules? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
At 11:45 PM 1/10/2008 +0100, Christian Heimes wrote: >In my version a hook is immediately called when the the registry value >is set to None. When a hook is registered for a module during the >execution of the callback then the hook is fired directly and not after >the existing hooks are called. Is this a problem for you? Yes, because it violates the invariant that hooks for a given module are called in the same order that they were registered in. In case you're wondering why it's a problem, it's because if a hook imports something that registers a hook, when previously that thing wasn't imported until later, all of a sudden your callback order is very different than what it was before. More succinctly: if making small changes to your program can cause large differences in the result, it's hard to debug. (Especially if you have no idea what 3rd party module changed its import order and messed things up.) Believe me, it's a lot easier to debug if there is a globally understandable hook order, even if it's still a partial ordering. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
Phillip J. Eby wrote: > Yes, that's the general idea. But what happens if you are in the middle > of firing hooks for 'a', and a new hook for 'a.b.c' is added? What > about a new hook for 'a'? If 'a' registers a new hook for a child of 'a' (e.g. 'a.b.c' or 'a.f') then the new hooks are called with the remaining hooks for 'a.b.c': import a.b.c * hook_a1 * hook_a1 -> registers the hook_ab2 for 'a.b' * hook_ab1 -> registers a hook_aX for 'a' hook_aX is fired immediately * hook_ab2 -- the hook registered by hook_a1 > Well, it certainly can (and should) do the same if a module object is > provided, since the module has a __name__. Maybe I should add two methods to imp. One that calls the parent hooks of a module automatically but relies on the existence of the parents and the module in sys.modules. And a second method which calls the hooks for a module object w/o inspecting sys.modules. > Only if you can guarantee that no hook for a submodule is run until all > the parent hooks are finished being called *and* that adding new > callbacks while callbacks are being run will still call them... *after* > any already-added callbacks. Uhm, now it starts to become a mind bending problem. I may have to queue and delay the registration of new hooks while other hooks are called by the system. If an user registers a callback for 'a' while the callbacks for 'a' are called than the registration is queued and the called after the remaining hooks for 'a' are called. This could probably be implemented by *not* setting the entry to None after I get hold of the iterator but after the end of the iteration. iter() notices when a new element is appended. In the above sample can hook_aX be called after hook_ab1 or should it be called after hook_ab2? > In general, if you think something in peak.util.imports isn't required, > you're probably wrong. ;) *g* ok. I'll check your implementation again. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
Phillip J. Eby wrote: >> I'm not setting the hooks to Py_None before the hook are called. Err, make that NOW, not NOT ... stupid typo. I'm NOW setting the hooks to Py_None before the hooks are called. > That's fine, but here's a different catch: are you iterating over the > hooks by taking the length before you start? If so, then hooks that are > added *while* the hooks are being called back, will never get called, > because they'll be added to the end of the list (and you'll never reach > the end). Make sure there's a test for that case. it = iter(self.post_import_registry[name]) self.post_import_registry[name] = None for hook in it: hook(module) > peak.util.imports sets to None after callbacks, but it uses regular list > iteration, so hooks can be added to the end of the list while the hooks > are still being called. In my version a hook is immediately called when the the registry value is set to None. When a hook is registered for a module during the execution of the callback then the hook is fired directly and not after the existing hooks are called. Is this a problem for you? module "foo" is loaded: hook1 hook2 -> registers hookX for "foo" hookX is called directly hook3 hook4 > An error while running the hooks should also set the hook list to None > and discard all the hooks. There isn't any sane way to recover from an > error in a post-import hook. The hooks are set to None even when an exception is raised by a hook. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] distutils.cygwinccompiler: invalid executable for interpreters
Hi everyone, Some time ago I've stumbled upon a problem with compiling py2exe with mingw: it resulted in invalid executable run.exe. At first I dismissed it as some very strange problem, but recently I decided to look into it again and found that the reason for this is a .def file, supplied during compilation, that causes linker to produce executable with IMAGE_FILE_DLL in its PE Header Characteristics field, and operating system refuses to execute it. I traced this problem to the following block in distutils/cygwinccompiler.py: # handle export symbols by creating a def-file # with executables this only works with gcc/ld as linker if ((export_symbols is not None) and (target_desc != self.EXECUTABLE or self.linker_dll == "gcc")): Removing 'or self.linker_dll == "gcc"' obviously helps. To me this sounds like a bug (introduced in revision 17747 on trunk, more that 7 years old!), but I was wondering if there's any logic behind generating a .def file for the executable (sidenote: look at distutils/emxccompiler.py where .def file is generated for executables only). To me it's very unlikely that anyone *ever* needs to export symbols from an executable (I'm not even sure if it can work as intended on Windows). Even then, if there's anyone at all who needs such a machinery (again, what for?), at the very least it shouldn't produce "LIBRARY" line. As minimal change as this: # Generate .def file contents = [ "LIBRARY %s" % os.path.basename(output_filename), "EXPORTS"] if target_desc == self.EXECUTABLE: contents.pop(0) Did the trick (generated executable runs fine). Is anyone interested in a bug report for this? Also, is there any chance that if there is interest it could end up in release25-maint? Best regards, Alexey. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
At 09:40 PM 1/10/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
>[...]
>
> > There's also one twist that I haven't sorted out yet: "Importing"
> > guarantees that a parent module 'foo' will have a 'bar' attribute for
> > the 'foo.bar' module, if 'foo.bar' is lazy. It does this by
> > registering a callback, ideally *before* any other callback is
> > registered for 'foo' or 'foo.bar' that would look at 'foo.bar'. I
> > don't see how to maintain this condition in a world where import
> > callbacks can be registered independently.
>
>I've moved the PyImport_NotifyModuleLoaded() call to import_submodule().
>It (should) guarantee that the hooks for a parent package is called
>before the hooks for its children are called. I've analyzed the code
>carefully enough to be sure but all unit test results are on my side.
>
>On other words "import a.b.c" fires the hooks for "a", then "a.b" and at
>last "a.b.c".
Yes, that's the general idea. But what happens if you are in the
middle of firing hooks for 'a', and a new hook for 'a.b.c' is
added? What about a new hook for 'a'?
>I could also modify imp.notify_module_loaded to accepts the module name
>as string ("a.b.c."). If the module is provided by name (e.g. "a.b.c.")
>rather than by object it makes sure that the hooks for "a", "a.b" and
>"a.b.c" are called in the right order.
Well, it certainly can (and should) do the same if a module object is
provided, since the module has a __name__.
>Would the modification fulfill your needs if
>imp.notify_module_loaded("foo.bar.baz") call the hooks for "foo",
>"foo.bar" and "foo.bar.baz" in that order?
Only if you can guarantee that no hook for a submodule is run until
all the parent hooks are finished being called *and* that adding new
callbacks while callbacks are being run will still call them...
*after* any already-added callbacks.
>The initial design used to set the hooks to None *after* the hooks were
>called. I removed code yesterday because I thought it's not required.
>Today I've re-added the checks for Py_None.
In general, if you think something in peak.util.imports isn't
required, you're probably wrong. ;)
>I'm not setting the hooks to Py_None before the hook are called.
That's fine, but here's a different catch: are you iterating over the
hooks by taking the length before you start? If so, then hooks that
are added *while* the hooks are being called back, will never get
called, because they'll be added to the end of the list (and you'll
never reach the end). Make sure there's a test for that case.
peak.util.imports sets to None after callbacks, but it uses regular
list iteration, so hooks can be added to the end of the list while
the hooks are still being called.
An error while running the hooks should also set the hook list to
None and discard all the hooks. There isn't any sane way to recover
from an error in a post-import hook.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
Phillip J. Eby wrote:
[...]
> There's also one twist that I haven't sorted out yet: "Importing"
> guarantees that a parent module 'foo' will have a 'bar' attribute for
> the 'foo.bar' module, if 'foo.bar' is lazy. It does this by
> registering a callback, ideally *before* any other callback is
> registered for 'foo' or 'foo.bar' that would look at 'foo.bar'. I
> don't see how to maintain this condition in a world where import
> callbacks can be registered independently.
I've moved the PyImport_NotifyModuleLoaded() call to import_submodule().
It (should) guarantee that the hooks for a parent package is called
before the hooks for its children are called. I've analyzed the code
carefully enough to be sure but all unit test results are on my side.
On other words "import a.b.c" fires the hooks for "a", then "a.b" and at
last "a.b.c".
I could also modify imp.notify_module_loaded to accepts the module name
as string ("a.b.c."). If the module is provided by name (e.g. "a.b.c.")
rather than by object it makes sure that the hooks for "a", "a.b" and
"a.b.c" are called in the right order.
> Bleah. All of the above isn't really a good explanation of the
> problem. Let me try to simplify it:
>
> * Lazy importing needs to guarantee that foo.bar =
> sys.modules['foo.bar'], when callbacks for 'foo.bar' execute (in case
> they refer to foo.bar)
>
> * To do this, it registers a callback that sets foo.bar =
> sys.modules['foo.bar'], and does not actually register any foo.bar
> callbacks until 'foo' is really imported (and thus foo.bar gets set
> by that callback)
Would the modification fulfill your needs if
imp.notify_module_loaded("foo.bar.baz") call the hooks for "foo",
"foo.bar" and "foo.bar.baz" in that order?
> In the case of the PEP, it's harder for me to figure out what
> happens, because you might not have any lazy modules around, and the
> foo.bar issue would then not come up. You also have the possibility
> of a problem where a lazy import callback occurs in 3rd party code,
> while callbacks are occurring from the import machinery. (Which
> means that the notification API should probably set the hooks entry
> to None while it's running, so that if it's called from inside a
> hook, it will not double-run the hooks, and new hooks registered
> while hooks are running will get run immediately as they are
> encountered, instead of getting added to the list.)
The initial design used to set the hooks to None *after* the hooks were
called. I removed code yesterday because I thought it's not required.
Today I've re-added the checks for Py_None. I'm not setting the hooks to
Py_None before the hook are called.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
Guido van Rossum wrote:
> On Jan 10, 2008 9:57 AM, Eric Smith <[EMAIL PROTECTED]> wrote:
>> Eric Smith wrote:
>>> 1: How should the builtin format() work? It takes 2 parameters, an
>>> object o and a string s, and returns o.__format__(s). If s is None, it
>>> returns o.__format__(empty_string). In 3.0, the empty string is of
>>> course unicode. For 2.6, should I use u'' or ''?
>> I just re-read PEP 3101, and it doesn't mention this behavior with None.
>> The way the code actually works is that the specifier is optional, and
>> if it isn't present then it defaults to an empty string. This behavior
>> isn't mentioned in the PEP, either.
>>
>> This feature came from a request from Talin[0]. We should either add
>> this to the PEP (and docs), or remove it. If we document it, it should
>> mention the 2.x behavior (as other places in the PEP do). If we removed
>> it, it would remove the one place in the backport that's not just hard,
>> but ambiguous. I'd just as soon see the feature go away, myself.
>
> IIUC, the 's' argument is the format specifier. Format specifiers are
> written in a very conservative character set, so I'm not sure it
> matters. Or are you assuming that the *type* of 's' also determines
> the type of the output?
Yes, 's' is the format specifier. I should have used its actual name.
I'm am saying that the type of 's' determines the type of the output.
Maybe that's a needless assumption for the builtin format(), since it
doesn't inspect the value of 's' (other than to verify its type). But
for ''.format() and u''.format(), I was thinking it will be true (but
see below).
It just seems weird to me that the result of format(3, u'd') would be a
'3', not u'3'.
> I may be in the minority here, but I think I like having a default for
> 's' (as implemented -- the PEP ought to be updated) and I also think
> it should default to an 8-bit string, assuming you support 8-bit
> strings at all -- after all in 2.x 8-bit strings are the default
> string type (as reflected by their name, 'str').
As long as it's defined, I'm okay with it. I think making the 2.6
default be an empty str is reasonable.
>>> 3: Every overridden __format__() method is going to have to check for
>>> string or unicode, just like object.__format() does, and return either a
>>> string or unicode object, appropriately. I don't see any way around
>>> this, but I'd like to hear any thoughts. I guess there aren't all that
>>> many __format__ methods that will be implemented, so this might not be a
>>> big burden. I'll of course implement the built in ones.
>> The PEP actually mentions that this is how 2.x will have to work. So
>> I'll go ahead and implement it that way, on the assumption that getting
>> string support into 2.6 is desirable.
>
> I think it is. (But then I still live in a predominantly ASCII world. :-)
I live in that same world, which is why I started implementing this to
begin with! I've always been more interested in the ascii version for
2.6 than for the 3.0 unicode version. Doing it first in 3.0 was my way
of getting it into 2.6.
> For data types whose output uses only ASCII, would it be acceptable if
> they always returned an 8-bit string and left it up to the caller to
> convert it to Unicode? This would apply to all numeric types. (The
> date/time types have a strftime() style API which means the user must
> be able to specifiy Unicode.)
I guess in str.format() I could require the result of format(obj,
format_spec) to be a str, and in unicode.format() I could convert it to
be unicode, which would either succeed or fail. I think all I need to
do is have the numeric formatters work with both unicode and str format
specifiers, and always return str results. That should be doable. As
you say, the format specifiers for the numerics are restricted to 8-bit
strings, anyway.
Now that I think about it, the str .__format__() will also need to
accept unicode and produce a str, for this to work:
u"{0}{1}{2}".format('a', u'b', 3)
I'll give these ideas a shot and see how far I get. Thanks for the
feedback!
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
On Jan 10, 2008 9:57 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > Eric Smith wrote: > > (I'm posting to python-dev, because this isn't strictly 3.0 related. > > Hopefully most people read it in addition to python-3000). > > > > I'm working on backporting the changes I made for PEP 3101 (Advanced > > String Formatting) to the trunk, in order to meet the pre-PyCon release > > date for 2.6a1. > > > > I have a few questions about how I should handle str/unicode. 3.0 was > > pretty easy, because everything was unicode. > > > > 1: How should the builtin format() work? It takes 2 parameters, an > > object o and a string s, and returns o.__format__(s). If s is None, it > > returns o.__format__(empty_string). In 3.0, the empty string is of > > course unicode. For 2.6, should I use u'' or ''? > > I just re-read PEP 3101, and it doesn't mention this behavior with None. > The way the code actually works is that the specifier is optional, and > if it isn't present then it defaults to an empty string. This behavior > isn't mentioned in the PEP, either. > > This feature came from a request from Talin[0]. We should either add > this to the PEP (and docs), or remove it. If we document it, it should > mention the 2.x behavior (as other places in the PEP do). If we removed > it, it would remove the one place in the backport that's not just hard, > but ambiguous. I'd just as soon see the feature go away, myself. IIUC, the 's' argument is the format specifier. Format specifiers are written in a very conservative character set, so I'm not sure it matters. Or are you assuming that the *type* of 's' also determines the type of the output? I may be in the minority here, but I think I like having a default for 's' (as implemented -- the PEP ought to be updated) and I also think it should default to an 8-bit string, assuming you support 8-bit strings at all -- after all in 2.x 8-bit strings are the default string type (as reflected by their name, 'str'). > > 3: Every overridden __format__() method is going to have to check for > > string or unicode, just like object.__format() does, and return either a > > string or unicode object, appropriately. I don't see any way around > > this, but I'd like to hear any thoughts. I guess there aren't all that > > many __format__ methods that will be implemented, so this might not be a > > big burden. I'll of course implement the built in ones. > > The PEP actually mentions that this is how 2.x will have to work. So > I'll go ahead and implement it that way, on the assumption that getting > string support into 2.6 is desirable. I think it is. (But then I still live in a predominantly ASCII world. :-) For data types whose output uses only ASCII, would it be acceptable if they always returned an 8-bit string and left it up to the caller to convert it to Unicode? This would apply to all numeric types. (The date/time types have a strftime() style API which means the user must be able to specifiy Unicode.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
Eric Smith wrote: > (I'm posting to python-dev, because this isn't strictly 3.0 related. > Hopefully most people read it in addition to python-3000). > > I'm working on backporting the changes I made for PEP 3101 (Advanced > String Formatting) to the trunk, in order to meet the pre-PyCon release > date for 2.6a1. > > I have a few questions about how I should handle str/unicode. 3.0 was > pretty easy, because everything was unicode. > > 1: How should the builtin format() work? It takes 2 parameters, an > object o and a string s, and returns o.__format__(s). If s is None, it > returns o.__format__(empty_string). In 3.0, the empty string is of > course unicode. For 2.6, should I use u'' or ''? I just re-read PEP 3101, and it doesn't mention this behavior with None. The way the code actually works is that the specifier is optional, and if it isn't present then it defaults to an empty string. This behavior isn't mentioned in the PEP, either. This feature came from a request from Talin[0]. We should either add this to the PEP (and docs), or remove it. If we document it, it should mention the 2.x behavior (as other places in the PEP do). If we removed it, it would remove the one place in the backport that's not just hard, but ambiguous. I'd just as soon see the feature go away, myself. > 3: Every overridden __format__() method is going to have to check for > string or unicode, just like object.__format() does, and return either a > string or unicode object, appropriately. I don't see any way around > this, but I'd like to hear any thoughts. I guess there aren't all that > many __format__ methods that will be implemented, so this might not be a > big burden. I'll of course implement the built in ones. The PEP actually mentions that this is how 2.x will have to work. So I'll go ahead and implement it that way, on the assumption that getting string support into 2.6 is desirable. Eric. [0] http://mail.python.org/pipermail/python-3000/2007-August/010089.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 10:47 AM 1/10/2008 +, Paul Moore wrote: >On 09/01/2008, Steve Holden <[EMAIL PROTECTED]> wrote: > > The idea that users would /program their own computers/ was totally > > alien to the Windows mindset. > >Actually, the alien idea is that more than one person would use the >same (Windows) computer. Not surprising as these were *personal* >computers. It's Windows as a server OS that's the bizarre idea... multiuser != server I've been in a couple of organizations where PCs were shared and thus had different users logging into them. Cash registers and call centers, for example. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
At 07:22 PM 1/10/2008 +1000, Nick Coghlan wrote: >Christian Heimes wrote: > > A module is successfully loaded > > ''' > > > > The import machinery checks if sys.post_import_hooks contains post import > > hooks for the newly loaded module. If hooks are found then the hooks are > > called in the order they were registered with the module instance as first > > argument. The processing of the hooks is stopped when a method raises an > > exception. At the end the entry for the module name is removed from > > sys.post_import_hooks, even when an error has occured. > >Doesn't the module remain in post_import_hooks, only mapped to None to >indicate that any hooks should be run immediately? It should be, yes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
I am not a developer but i'm interested in browsing it. Is it possible to be added? On Jan 10, 2008 10:57 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > I think only Coverity can add people. You can send them a message if > > you would like to be added: [EMAIL PROTECTED] Or you can send > > mail to me and I can forward along all the people that would like to > > be added. > > > > I'll wait a few days to collect names so I can batch up the request. > > Count me in! > > Christian > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
Neal Norwitz wrote: > I think only Coverity can add people. You can send them a message if > you would like to be added: [EMAIL PROTECTED] Or you can send > mail to me and I can forward along all the people that would like to > be added. > > I'll wait a few days to collect names so I can batch up the request. Count me in! Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
Neal Norwitz wrote: > For traceback.c, namebuf defined on line 155 should be moved out one > block since filename is an alias to namebuf and it is used outside the > current scope. I think this is unlikely to be a problem in practice, > but is technically wrong and should be fixed. Agreed, the early allocation of a few hundreds bytes on the stack won't kill us. > For codeobject.c, line 327 should not be reachable. I kinda like the > code as it is even though it is currently dead. I never decided if I > wanted to change that or suppress the warning. Please suppress the warning. I removed the last two lines and GCC complained "control reaches end of non-void function". It's not clever enough to understand that cmp can never be 0. > For mmapmodule.c, fd should be checked for -1 before calling stat on line > 1064. if (fd != -1 && fstat(fd, &st) == 0 && S_ISREG(st.st_mode)) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
M.-A. Lemburg wrote: > On 2008-01-10 14:31, Eric Smith wrote: >> (I'm posting to python-dev, because this isn't strictly 3.0 related. >> Hopefully most people read it in addition to python-3000). >> >> I'm working on backporting the changes I made for PEP 3101 (Advanced >> String Formatting) to the trunk, in order to meet the pre-PyCon release >> date for 2.6a1. >> >> I have a few questions about how I should handle str/unicode. 3.0 was >> pretty easy, because everything was unicode. > > Since this is a new feature, why bother with strings at all > (even in 2.6) ? > > Use Unicode throughout and be done with it. I was hoping someone would say that! It would certainly make things much easier. But for my own selfish reasons, I'd like to have str.format() work in 2.6. Other than the issues I raised here, I've already done the vast majority of the work for the code to support either string or unicode. For example, I put most of the implementation in Objects/stringlib, so I can include it either as string or unicode. But I can live with unicode only if that's the consensus. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 10, 2008, at 9:07 AM, M.-A. Lemburg wrote: > On 2008-01-10 14:31, Eric Smith wrote: >> (I'm posting to python-dev, because this isn't strictly 3.0 related. >> Hopefully most people read it in addition to python-3000). >> >> I'm working on backporting the changes I made for PEP 3101 (Advanced >> String Formatting) to the trunk, in order to meet the pre-PyCon >> release >> date for 2.6a1. >> >> I have a few questions about how I should handle str/unicode. 3.0 >> was >> pretty easy, because everything was unicode. > > Since this is a new feature, why bother with strings at all > (even in 2.6) ? > > Use Unicode throughout and be done with it. +1 - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4YrpHEjvBPtnXfVAQJcgwP+PV+XsqtZZ2aFA4yxIYRzkVVCyk+rwFSN H58DygPu4AQvhb1Dzuudag1OkfdpUHeRkvTyjSkUTWbK/03Y4R5A8X8iDkkQozQd m92DynvSEIOtX3WJZT4SOvGj+QavQC4FmkTPlEPNwqBkIl4GkjfOnwMsKx2lwKN+ rOXUf7Mtvd8= =1ME/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 3101 to 2.6
On 2008-01-10 14:31, Eric Smith wrote: > (I'm posting to python-dev, because this isn't strictly 3.0 related. > Hopefully most people read it in addition to python-3000). > > I'm working on backporting the changes I made for PEP 3101 (Advanced > String Formatting) to the trunk, in order to meet the pre-PyCon release > date for 2.6a1. > > I have a few questions about how I should handle str/unicode. 3.0 was > pretty easy, because everything was unicode. Since this is a new feature, why bother with strings at all (even in 2.6) ? Use Unicode throughout and be done with it. > 1: How should the builtin format() work? It takes 2 parameters, an > object o and a string s, and returns o.__format__(s). If s is None, it > returns o.__format__(empty_string). In 3.0, the empty string is of > course unicode. For 2.6, should I use u'' or ''? > > > 2: In 3.0, object.__format__() is essentially this: > > class object: > def __format__(self, format_spec): > return format(str(self), format_spec) > > In 2.6, I assume it should be the equivalent of: > > class object: > def __format__(self, format_spec): > if isinstance(format_spec, str): > return format(str(self), format_spec) > elif isinstance(format_spec, unicode): > return format(unicode(self), format_spec) > else: > error > > Does that seem right? > > > 3: Every overridden __format__() method is going to have to check for > string or unicode, just like object.__format() does, and return either a > string or unicode object, appropriately. I don't see any way around > this, but I'd like to hear any thoughts. I guess there aren't all that > many __format__ methods that will be implemented, so this might not be a > big burden. I'll of course implement the built in ones. > > Thanks in advance for any insights. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 10 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backporting PEP 3101 to 2.6
(I'm posting to python-dev, because this isn't strictly 3.0 related. Hopefully most people read it in addition to python-3000). I'm working on backporting the changes I made for PEP 3101 (Advanced String Formatting) to the trunk, in order to meet the pre-PyCon release date for 2.6a1. I have a few questions about how I should handle str/unicode. 3.0 was pretty easy, because everything was unicode. 1: How should the builtin format() work? It takes 2 parameters, an object o and a string s, and returns o.__format__(s). If s is None, it returns o.__format__(empty_string). In 3.0, the empty string is of course unicode. For 2.6, should I use u'' or ''? 2: In 3.0, object.__format__() is essentially this: class object: def __format__(self, format_spec): return format(str(self), format_spec) In 2.6, I assume it should be the equivalent of: class object: def __format__(self, format_spec): if isinstance(format_spec, str): return format(str(self), format_spec) elif isinstance(format_spec, unicode): return format(unicode(self), format_spec) else: error Does that seem right? 3: Every overridden __format__() method is going to have to check for string or unicode, just like object.__format() does, and return either a string or unicode object, appropriately. I don't see any way around this, but I'd like to hear any thoughts. I guess there aren't all that many __format__ methods that will be implemented, so this might not be a big burden. I'll of course implement the built in ones. Thanks in advance for any insights. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
On Wed, Jan 09, 2008 at 09:11:21PM -0800, Neal Norwitz wrote:
> For mmapmodule.c, fd should be checked for -1 before calling stat on line
> 1064.
On looking at this, it doesn't seem like an actual problem. fstat(-1,
...) returns a -1 and errno is set to EBADF, 'bad file descriptor'.
/* on OpenVMS we must ensure that all bytes are written to the file */
fsync(fd);
# endif
if (fstat(fd, &st) == 0 && S_ISREG(st.st_mode)) {
...
In rev. 59888, I've added 'fd != -1' to the 'if' just to save a
pointless fstat() call, and made the OpenVMS fsync() call similarly
conditional, but I don't think this item is a bug, much less a
security bug. I won't bother backporting this to 25-maint, unless
asked to do so by the 2.5 maintainer.
--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
On Wed, Jan 09, 2008 at 09:11:21PM -0800, Neal Norwitz wrote: > For mmapmodule.c, fd should be checked for -1 before calling stat on line > 1064. I'll fix the mmap problem. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Steve Holden <[EMAIL PROTECTED]> wrote: > The idea that users would /program their own computers/ was totally > alien to the Windows mindset. Actually, the alien idea is that more than one person would use the same (Windows) computer. Not surprising as these were *personal* computers. It's Windows as a server OS that's the bizarre idea... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Post import hooks
Christian Heimes wrote: > A module is successfully loaded > ''' > > The import machinery checks if sys.post_import_hooks contains post import > hooks for the newly loaded module. If hooks are found then the hooks are > called in the order they were registered with the module instance as first > argument. The processing of the hooks is stopped when a method raises an > exception. At the end the entry for the module name is removed from > sys.post_import_hooks, even when an error has occured. Doesn't the module remain in post_import_hooks, only mapped to None to indicate that any hooks should be run immediately? (Finding an object in sys.modules isn't enough, due to the possibility of it being a 3rd party lazy module rather than the actual module). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some bugs that need attention
Ralf Schmitt wrote: > Hi, > > I've taken a look at some bugs in the bugtracker. I think these should > be closed: > > http://bugs.python.org/issue1720992 is about automatic imports. > > http://bugs.python.org/issue1448325 > and > http://bugs.python.org/issue1566086 > > is about the regular expression engine "hanging". These are duplicates of > http://bugs.python.org/issue1662581 and should be closed. To save anyone else needing to go and look: Christian and Georg have now taken care of closing these. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
