Re: [Python-Dev] Backporting PEP 3101 to 2.6

[Nick Coghlan]

Guido van Rossum wrote:
> 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.)

To elaborate on this a bit (and handwaving a lot of important details 
out of the way) do you mean something like the following for the builtin 
format?:

def format(obj, fmt_spec=None):
 if fmt_spec is None: fmt_spec=''
 result = obj.__format__(fmt_spec)
 if isinstance(fmt_spec, unicode):
 if isinstance(result, str):
 result = unicode(result)
 return result

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] Passing contextual information when logging

[Nick Coghlan]

Vinay Sajip at Red Dove wrote:
> One solution is to create a generic wrapper around loggers to which a logger
> name and contextual information can be passed. The wrapper would delegate
> logging calls to the logger with the specified name, but would manipulate
> the arguments passed to the logging call to insert the contextual
> information. I have created such a wrapper class, called LoggerAdapter,
> which is in the example script located at
> 
> http://dpaste.com/30613/
> 
> I would welcome your views on whether the LoggerAdapter class is suitable
> for adding to the logging package in Python 2.6/3.0. Does it do what might
> reasonably be expected out of the box? LoggerAdapters are, of course,
> garbage collected in the normal way and so impose no particular memory
> burden.

It looks pretty good (and useful) to me, but I have a couple of questions.

When you talk about stacking in the constructor docstring, do you mean 
something like having LoggerAdapterA delegating to LoggerAdapterB which 
in turn delegates to the real logger?

If that's what you mean, then I think the process() method will need to 
be changed to handle the case where there is already an "extras" entry 
in the keyword arguments. If that's not what you mean... then please 
explain because I don't have any other ideas :)

I was also going to suggest modifying the constructor to accept keyword 
arguments, but realised that case can be adequately handled just by 
using a dict:

   logger_with_extra = LoggerAdapter(logger, dict(attr1=5, attr2=True))

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

[Python-Dev] Passing contextual information when logging

[Vinay Sajip at Red Dove]

I recently posted the following to c.l.py, and didn't get much feedback. I'm
planning to add a new class to the logging package, and before I do so I'd
like to get feedback from python-dev. I know many of the devs may not be
monitoring c.l.py, so I'm reposting here for your feedback.

Some users of the logging package have raised an issue regarding the
difficulty of passing additional contextual information when logging. For
example, the developer of a networked application may want to log, in
addition to specifics related to to the network service being provided,
information about the IP address of the remote machine and the username of
the person logged into and using the service.

Python 2.4 introduced an 'extra' keyword argument which was intended to hold
a dict-like object containing additional information to be added to a
LogRecord. The additional information would then be printed via placeholders
in a format string.

While this works, it is a little unwieldy to use in practice, because users
need to provide the 'extra' parameter in every logging call. This has led
people in some instances to create context-specific Logger instances (e.g.
one logger for every connection). This has a drawback in that a logger name
can only provide limited contextual information, and moreover, if the number
of connections is effectively unbounded over time, the number of Logger
instances will also grow in an unbounded way. (Logger instances are never
garbage collected, because references to them are always held in the logging
package. This alleviates a burden on users in that they never have to pass
loggers around, but means that creating a lot of Logger instances will lead
to a long-lived memory burden.)

One solution is to create a generic wrapper around loggers to which a logger
name and contextual information can be passed. The wrapper would delegate
logging calls to the logger with the specified name, but would manipulate
the arguments passed to the logging call to insert the contextual
information. I have created such a wrapper class, called LoggerAdapter,
which is in the example script located at

http://dpaste.com/30613/

I would welcome your views on whether the LoggerAdapter class is suitable
for adding to the logging package in Python 2.6/3.0. Does it do what might
reasonably be expected out of the box? LoggerAdapters are, of course,
garbage collected in the normal way and so impose no particular memory
burden.

I'll wait a few days for any comments/suggestions from this list, then
(assuming no adverse comments) go ahead and add the LoggerAdapter class and
update the docs.

Best regards,

Vinay Sajip

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

Nick Coghlan wrote:
> Guido van Rossum wrote:
>> 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.)
> 
> To elaborate on this a bit (and handwaving a lot of important details 
> out of the way) do you mean something like the following for the builtin 
> format?:
> 
> def format(obj, fmt_spec=None):
> if fmt_spec is None: fmt_spec=''
> result = obj.__format__(fmt_spec)
> if isinstance(fmt_spec, unicode):
> if isinstance(result, str):
> result = unicode(result)
> return result

That's the approach I'm taking.  The builtin format is the only caller 
of __format__ that I know of, so it's the only place this would need to 
be done.
___
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]

Steve Holden wrote:
> Nick Coghlan wrote:
>> To elaborate on this a bit (and handwaving a lot of important details 
>> out of the way) do you mean something like the following for the builtin 
>> format?:
>>
>> def format(obj, fmt_spec=None):
>>  if fmt_spec is None: fmt_spec=''
>>  result = obj.__format__(fmt_spec)
>>  if isinstance(fmt_spec, unicode):
>>  if isinstance(result, str):
>>  result = unicode(result)
>>  return result
>>
> Isn't unicode idempotent? Couldn't
> 
>   if isinstance(result, str):
>   result = unicode(result)
> 
> 
> avoid repeating in Python a test already made in C by re-spelling it as
> 
>  result = unicode(result)
> 
> or have you hand-waved away important details that mean the test really 
> is required?

This code is written in C.  It already has a check to verify that the 
return from __format__ is either str or unicode, and another check that 
fmt_spec is str or unicode.  So doing the conversion only if result is 
str and fmt_spec is unicode would be a cheap decision.

Good catch, though.  I wouldn't have thought of it, and there are parts 
that are written in Python, so maybe I can leverage this elsewhere.  Thanks!

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] Passing contextual information when logging

[Nick Coghlan]

Vinay Sajip wrote:
> When I check it in I will elaborate on the class docstring to explain the 
> usage
> in a bit more detail, as well as of course detailing it in the docs in a
> separate section entitled "Passing contextual information to the log" (or
> similar).

Thanks, I understand what you meant quite a bit better now. The comment 
didn't make a great deal of sense looking at the LoggingAdapter class in 
isolation, but is significantly more meaningful once you start 
discussing other possibilities for what can be done in the process() method.

I also like that the design of the class allows users to easily create 
their own adapters simply by subclassing this one and overriding the 
process() method. I imagine that's why you wrote it that way :)

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] Backporting PEP 3101 to 2.6

[Steve Holden]

Nick Coghlan wrote:
> Guido van Rossum wrote:
>> 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.)
> 
> To elaborate on this a bit (and handwaving a lot of important details 
> out of the way) do you mean something like the following for the builtin 
> format?:
> 
> def format(obj, fmt_spec=None):
>  if fmt_spec is None: fmt_spec=''
>  result = obj.__format__(fmt_spec)
>  if isinstance(fmt_spec, unicode):
>  if isinstance(result, str):
>  result = unicode(result)
>  return result
> 
Isn't unicode idempotent? Couldn't

  if isinstance(result, str):
  result = unicode(result)


avoid repeating in Python a test already made in C by re-spelling it as

 result = unicode(result)

or have you hand-waved away important details that mean the test really 
is required?

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.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] Passing contextual information when logging

[Vinay Sajip]

Nick Coghlan  gmail.com> writes:

> It looks pretty good (and useful) to me, but I have a couple of questions.
> 
> When you talk about stacking in the constructor docstring, do you mean 
> something like having LoggerAdapterA delegating to LoggerAdapterB which 
> in turn delegates to the real logger?
> 
> If that's what you mean, then I think the process() method will need to 
> be changed to handle the case where there is already an "extras" entry 
> in the keyword arguments. If that's not what you mean... then please 
> explain because I don't have any other ideas :)
> 
> I was also going to suggest modifying the constructor to accept keyword 
> arguments, but realised that case can be adequately handled just by 
> using a dict:
> 
>logger_with_extra = LoggerAdapter(logger, dict(attr1=5, attr2=True))
> 

Hi Nick,

Thanks for the feedback. The stacking is a bit of a corner case, so maybe I
should take that comment out of the docstring - but that's what I meant by
stacking. A set of stacked adapters could work by e.g. appending or prepending
their contextual info to the message, or by manipulating the "extra" keyword
argument to the base logger. The example implementation uses the "extra"
method, but if another adapter was to be stacked on top of that one, its
process method would need to check the passed in kwargs for key "extra" and
replace it with some merged version of the two sets of contexts - its own and
that of the underlying logger.

Another point about the "extra" method is that it lends itself to working with
a Formatter whose format string can hold user-defined placeholders like %(ip)s
in the example. This will work well in some scenarios, but in other scenarios
(where it may be desired to share formatters across various handlers, or
because stacking is desired and there's no way for one formatter to know all
the placeholders) it makes sense to just manipulate msg in the process method,
for example:

def process(self, msg, kwargs):
prefix = "IP: %(ip)-15s User: %(user)-8s" % self.extra
return "%s %s" % (prefix, msg), kwargs

When I check it in I will elaborate on the class docstring to explain the usage
in a bit more detail, as well as of course detailing it in the docs in a
separate section entitled "Passing contextual information to the log" (or
similar).

Best regards,


Vinay Sajip

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

Re: [Python-Dev] Bug day preparations: tagging bugs?

[Guido van Rossum]

On Jan 11, 2008 12:13 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> No one pushed back on the 19th as a bug day, so I'm going to go ahead
> and send out announcements this evening.
>
> We should mark issues in the tracker that are good candidates for new
> developers.  How do we want to do this?  We could add a new keyword
> ('beginner', 'bugday', ???) or add a prefix to the subject line.
>
> Does Roundup search also look at the text of the change notes added to
> a bug?  If yes, then just adding a comment with the magic keyword
> would be sufficient.

Yes, it does. Unfortunately, I've been using "bug day" in some
comments and that doesn't seem to work well in the search.

I think a keyword is easier, I can add it if you want me to.

-- 
--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] Bug day preparations: tagging bugs?

[A.M. Kuchling]

On Fri, Jan 11, 2008 at 09:45:14PM +0100, Christian Heimes wrote:
> Please add two keywords, one for bug day and one for easy tasks. May
> "beginner task", "easy" or "novice level" makes a good keyword.

I think marking easy tasks is all we need.  That would certainly be
useful during ongoing non-bugday development, but marking issues as
'bug-day' doesn't seem useful to me.  What would it mean?

> We could also mark complex/hard tasks, tasks which require C programming
> and documentation only tasks, even though I'm not sure how useful the
> additional tags would be.

Shouldn't documentation-only bugs be marked as being for the
'Documentation' component?  The C vs. Python requirement is also
discoverable from the component field, sort of; Library is for issues
in Lib/, which is all Python, and C extensions are the 'Extension
Modules' component.

--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] PEP: Post import hooks

[Christian Heimes]

Phillip J. Eby wrote:
> *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.

*sigh*, too. :/

This discussion has neither helping me nor you. Could you please write
an unit test or two to show me exactly what my implementation is doing
wrong and how you think the callbacks should be called. I know a simple
test won't proof the correctness of the implementation but a failing
test would at least show the incorrectness.

I'm still not sure which way is the correct way in your opinion and I
hate guessing what you are trying to explain to me.

Christian

PS: I've a pending patch that queues new registrations while hooks are
processed in PyImport_NotifyModuleLoaded().
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Bug day preparations: tagging bugs?

[A.M. Kuchling]

No one pushed back on the 19th as a bug day, so I'm going to go ahead
and send out announcements this evening.  

We should mark issues in the tracker that are good candidates for new
developers.  How do we want to do this?  We could add a new keyword
('beginner', 'bugday', ???) or add a prefix to the subject line.

Does Roundup search also look at the text of the change notes added to
a bug?  If yes, then just adding a comment with the magic keyword
would be sufficient.

--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] Bug day preparations: tagging bugs?

[Christian Heimes]

Guido van Rossum wrote:
> Yes, it does. Unfortunately, I've been using "bug day" in some
> comments and that doesn't seem to work well in the search.
> 
> I think a keyword is easier, I can add it if you want me to.
> 

Please add two keywords, one for bug day and one for easy tasks. May
"beginner task", "easy" or "novice level" makes a good keyword.

We could also mark complex/hard tasks, tasks which require C programming
and documentation only tasks, even though I'm not sure how useful the
additional tags would be.

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] PySequence_Concat for dicts

[Jared Flatow]

Hi all,

I am fairly new to the Python community so please forgive me (and  
correct me) if I am going about this wrong.

I think it would be convenient and pythonic if dict objects  
implemented the PySequence_Concat method. I see there was once a  
short-lived discussion about this here:

http://mail.python.org/pipermail/patches/2004-March/014323.html

I have also been following the discussion about contributing to  
Python. It seems to me that this would be a fairly easy feature to  
implement (perhaps naively?), and I would be glad to try writing a  
patch for this if there is at least some chance of it making it into  
one of the branches. Can someone please advise me on what the correct  
order for going about this would be? Do I need to first write a PEP  
justifying why I think it would be an improvement? Which version of  
Python (if any), should a patch be targeted at?

Otherwise, is there a good reason dicts do not already implement this  
method? I somewhat understand the complaint about commutativity, but  
as mentioned in the previous discussion, list concatenation is not  
commutative either. Seeing as update is the only builtin method for  
concatenation of dicts in the first place, it doesn't seem all that  
confusing that 'summing' two dicts should conveniently return a new  
instance that is the (only form of) concatenation of the two dicts.

regards,
jared
___
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] PEP: per user site-packages directory

[Christian Heimes]

MA Lemburg has suggested a per user site-packages directory in the
"pkgutil, pkg_resource and Python 3.0 name space packages" thread. I've
written a short PEP about it for Python 2.6 and 3.0.

PEP: XXX
Title: Per user site-packages directory
Version: $Revision$
Last-Modified: $Date$
Author: Christian Heimes 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Jan-2008
Python-Version: 2.6, 3.0
Post-History:


Abstract


This PEP proposes a new a per user site-packages directory to allow
users the local installation of Python packages in their home directory.


Rationale
=

Current Python versions don't have an unified way to install packages
into the home directory of an user (except for Mac Framework
builds). Users are either forced to ask the system administrator to
install or update a package for them or to use one of the many
workaround like Virtual Python [1]_, Working Env [2]_ or
Virtual Env [3]_.

It's not the goal of the PEP to replace the tools or to implement
isolated installations of Python. It only implements the most common
use case of an additional site-packages directory for each user.

The feature can't be implemented using the environment variable
*PYTHONPATH*. The env var just inserts a new directory to the beginning
of *sys.path* but it doesn't parse the pth files in the directory. A
full blown site-packages path is required for several applications
and Python eggs.


Specification
=

site directory (site-packages)

   A directory in sys.path. In contrast to ordinary directories the pth
   files in the directory are processed, too.


user site directory

   A site directory inside the users' home directory. An user site
   directory is specific to a Python version. The path contains
   the version number (major and minor only).

   Windows: %APPDATA%/Python/Python26/site-packages
   Mac: ~/Library/Python/2.6/site-packages
   Unix: ~/.local/lib/python2.6/site-packages


user configuration directory

   Usually the parent directory of the user site directory. It's meant
   for Python version specific data like config files.

   Windows: %APPDATA%/Python/Python26
   Mac: ~/Library/Python/2.6
   Unix: ~/.local/lib/python2.6

user base directory

   It's located inside the user's home directory. The user site and
   use config directory are inside the base directory. On some systems
   the directory may be shared with 3rd party apps.

   Windows: %APPDATA%/Python
   Mac: ~/Library/Python
   Unix: ~/.local


On Windows APPDATA was chosen because it is the most logical place for
application data. Microsoft recommands that software doesn't write to
USERPROFILE [5]_ and My Documents is not suited for application data,
too. [8]_

On Linux ~/.local/ was chosen in favor over ./~python/ because the
directory is already used by several other programs in analogy to
/usr/local. [7]_


Implementation
==

The site module gets a new method adduserpackage() which adds the
appropriate directory to the search path. The directory is not added if
it doesn't exist when Python is started. However the location of the
user site directory and user base directory is stored in an internal
variable for distutils.

The user site directory is added before the system site directories
but after Python's search paths and PYTHONPATH. This setup allows the
user to install a different version of a package than the system
administrator but it prevents the user from accidently overwriting a
stdlib module. Stdlib modules can still be overwritten with PYTHONPATH.

distutils.command.install (setup.py install) gets a new argument
--user to install packages in the user site directory. The required
directories are created by install.

distutils.sysconfig will get methods to access the private variables
of site. (not yet implemented)

The Windows updater needs to be updated, too. It should create an menu
item which opens the user site directory in a new explorer windows.


Backwards Compatibility
===

TBD


Open Questions
==

* Are the directories for Windows, Mac and Unix fine?

* Mac: Should framework and non-framework builds of Python use the
  same directories?

* The patch also adds a usecustomize hook to site. Is it useful and
  should it stay?


Reference Implementation


A reference implementation is available in the bug tracker. [4]_


Acknowledgments
===

The implementation of this PEP, if accepted, is sponsored by Google
through the Google Summer of Code program.


Copyright
=

This document has been placed in the public domain.


References
==

.. [1] Virtual Python

http://peak.telecommunity.com/DevCenter/EasyInstall#creating-a-virtual-python

.. [2]  Working Env
   http://pypi.python.org/pypi/workingenv.py
   http://blog.ianbicking.org/workingenv-revisited.html

.. [3] Virtual Env
   http://pypi.python.org/pypi/virtualenv

.. [4] reference implementation
   http://bugs.python.org/

[Python-Dev] Coverity Scan, Python upgraded to rung 2

[Jim Jewett]

Neal Norwitz wrote:
>> For codeobject.c, line 327 should not be reachable.
...

Christian Heimes wrote:
> Please suppress the warning. I removed the last
> two lines and GCC complained ...

Either way, it would be worth adding a comment to the source code so
this doesn't come up again.

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

Re: [Python-Dev] Bug day preparations: tagging bugs?

[Christian Heimes]

Guido van Rossum wrote:
> (I have no idea if anyone can add keywords or if I have magical
> powers. On the left side bar there's a section "Administration" which
> contains a link "Edit Keywords".)

I'm unable to add new keywords although I've the developer role. I guess
one needs to be a coordinator to add new keywords.

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] Bug day preparations: tagging bugs?

[Guido van Rossum]

I've added an "easy" keyword, with description "This is an easy task
(e.g. suitable for GHOP or bug day beginners)".

Let me know if more is needed, Andrew.

(I have no idea if anyone can add keywords or if I have magical
powers. On the left side bar there's a section "Administration" which
contains a link "Edit Keywords".)

--Guido

On Jan 11, 2008 1:10 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 11, 2008 at 09:45:14PM +0100, Christian Heimes wrote:
> > Please add two keywords, one for bug day and one for easy tasks. May
> > "beginner task", "easy" or "novice level" makes a good keyword.
>
> I think marking easy tasks is all we need.  That would certainly be
> useful during ongoing non-bugday development, but marking issues as
> 'bug-day' doesn't seem useful to me.  What would it mean?
>
> > We could also mark complex/hard tasks, tasks which require C programming
> > and documentation only tasks, even though I'm not sure how useful the
> > additional tags would be.
>
> Shouldn't documentation-only bugs be marked as being for the
> 'Documentation' component?  The C vs. Python requirement is also
> discoverable from the component field, sort of; Library is for issues
> in Lib/, which is all Python, and C extensions are the 'Extension
> Modules' component.
>
> --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/guido%40python.org
>



-- 
--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] PySequence_Concat for dicts

[Raymond Hettinger]

[Jared]
> I think it would be convenient and pythonic if dict
> objects implemented the PySequence_Concat method. 

IMO, the chainmap() recipe on ASPN is a much better solution since it doesn't 
create a third dictionary with the all the attendant allocation and copying 
effort. It isn't a common use case to need to sum two dictionaries while 
keeping both of the inputs unaltered.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305268.

Raymond
___
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] PySequence_Concat for dicts

[Jared Flatow]

On Jan 11, 2008, at 6:45 PM, Raymond Hettinger wrote:
> IMO, the chainmap() recipe on ASPN is a much better solution since  
> it doesn't create a third dictionary with the all the attendant  
> allocation and copying effort.

I wasn't suggesting that the result of concatenation would be a  
chained table, rather that it would perform the equivalent of an  
update and return the new dict (the same way extend works for lists).

> It isn't a common use case to need to sum two dictionaries while  
> keeping both of the inputs unaltered.

Inplace concatenation could be implemented more efficiently but would  
be exactly the same as calling update.

jared
___
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] PySequence_Concat for dicts

[Raymond Hettinger]

> I wasn't suggesting that the result of concatenation would 
> be a  chained table, rather that it would perform the 
> equivalent of an  update and return the new dict 
>(the same way extend works for lists)

When does it come-up that you want a third summed dict 
while keeping the two originals around unchanged?  Does
it matter that the addition is non-commutative?  Would
a + b + c produce an intermediate a/b combo and then
another new object for a/b/c so that the entries in
a get copied twice and memory usage has to hold a, b,
a/b, c, and a/b/c in memory all at the same time?  
What are the use cases?

FWIW, the Py3.0 API for dicts will support some set-like
operations.  Perhaps, that fits the bill.


Raymond
___
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] New Developer

[Fernando Perez]

Mark Dickinson wrote:

> Hello all,
> I've recently been granted commit privileges; so, following the usual
> protocol, here's a quick introduction.  I'm a mathematician by day;  my
> degree is in number theory, but five summers of Fortran 77 programming and
> two semesters of teaching numerical analysis have given me a taste for
> numerics as well.  I discovered Python around twelve years ago and found
> that it fit my brain nicely (even more so after nested namespaces were
> introduced) and now use it almost daily for a wide variety of tasks.  I've
> been lurking on python-dev for longer than I care to admit to.  I also
> dabble in Haskell and O'Caml.

Very interesting!  Are you aware of Sage? http://sagemath.org.  All
Python-based, developed originally by a number theorist
(http://wstein.org), and with a rapidly growing team of developers
(including John Cremona, who's contributed a lot of his code to Sage).  

The Python-dev team should be proud of the impact Python is having in
scientific computing: python is without a doubt the leading tool for open
source, high-level scientific codes (i.e. not Fortran/C), and growing. 
Thanks!


I normally wouldn't announce this here, but please forgive the mini-spam
(and let's continue off list if you are interested):

http://wiki.sagemath.org/days8

Just contact me off list at [EMAIL PROTECTED] if you think you'd
like to attend.

Cheers,

f

___
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] How to change path at compile time?

[Jason Garber]

Hello,

 

Is there any reasonable way to change the default sys.path at compile
time?  (ie. add a directory).

 

(I am aware of $PYTHONPATH for runtime)

 

--

Best Regards,

 

Jason Garber

Senior Systems Engineer

IonZoft, Inc.

 

(814) 941-2390

[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: per user site-packages directory

[Alexandre Vassalotti]

I can't comment on the implementation details, but +1 for the idea. I
think this feature will be very useful in a shared hosting
environment.

-- Alexandre

On Jan 11, 2008 6:27 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> PEP: XXX
> Title: Per user site-packages directory
> Version: $Revision$
> Last-Modified: $Date$
> Author: Christian Heimes 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 11-Jan-2008
> Python-Version: 2.6, 3.0
> Post-History:
>
___
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] PySequence_Concat for dicts

[Guido van Rossum]

On Jan 11, 2008 5:21 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I wasn't suggesting that the result of concatenation would
> > be a  chained table, rather that it would perform the
> > equivalent of an  update and return the new dict
> >(the same way extend works for lists)
>
> When does it come-up that you want a third summed dict
> while keeping the two originals around unchanged?  Does
> it matter that the addition is non-commutative?  Would
> a + b + c produce an intermediate a/b combo and then
> another new object for a/b/c so that the entries in
> a get copied twice and memory usage has to hold a, b,
> a/b, c, and a/b/c in memory all at the same time?
> What are the use cases?
>
> FWIW, the Py3.0 API for dicts will support some set-like
> operations.  Perhaps, that fits the bill.

While that was at one point proposed, It's been retracted.

It does suggest that we have two choices for the proposed operation:
d1+d2 or d1|d2. I think the latter may be more appropriate:
len(seq1+seq2) == len(seq1) ++len(seq2), but no such invariant exists
for set union.

I'd like to take an "all or nothing" approach to this: either we
implement the same 4 operations as for sets (|, &, ^ and -) or we
implement none of them. We can assign semantics to these such that if
the values are all the same, these work the same as set operations on
the keys. E.g.:

  {1:1, 2:2} | {2:2, 3:3} == {1:1, 2:2, 3:3}
  {1:1, 2:2} & {2:2, 3:3} == {2:2}
  {1:1, 2:2} ^ {2:2, 3:3} == {1:1, 3:3}
  {1:1, 2:2} - {2:2, 3:3} == {1:1}

If the values differ, we have to decide what happens. For ^ and -, we
only need to take the keys into account. For | I propose that the RHS
wins, matching dict.update(); this makes sense since set.update() is
equivalent to |= for sets, so |= should match dict.update() for dict,
and then | follows. For & I'm on the fence, but I think it's easier to
say that the RHS wins in all cases. So we get:

  {1:1, 2:2} | {2:0, 3:0} = {1:1, 2:0, 3:0}
  {1:1, 2:2} & {2:0, 3:0} = {2:0}
  {1:1, 2:2} ^ {2:0, 3:0} = {1:1, 3:0}
  {1:1, 2:2} - {2:0, 3:0} = {1:1}

(The |=, &=, ^= and -= operators don't pose new problems, they update
the LHS in place.)

I'm not sure where I stand on this proposal -- I guess a +0, if
someone else does the work. (The abc.py module needs to be updated
too.)

-- 
--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] Bug day preparations: tagging bugs?

[A.M. Kuchling]

On Fri, Jan 11, 2008 at 03:58:35PM -0800, Guido van Rossum wrote:
> Let me know if more is needed, Andrew.

Thanks!

I've run searches for a few different components and marked a few bugs
with the 'easy' keyword; I see that Tiran is doing this, too.

> (I have no idea if anyone can add keywords or if I have magical
> powers. On the left side bar there's a section "Administration" which
> contains a link "Edit Keywords".)

I have that link, too.

--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] PySequence_Concat for dicts

[Raymond Hettinger]

> I'd like to take an "all or nothing" approach to this: either we
> implement the same 4 operations as for sets (|, &, ^ and -) or we
> implement none of them. .
 . . .
> I'm not sure where I stand on this proposal -- I guess a +0, if
> someone else does the work. (The abc.py module needs to be updated
> too.)

I think this would end-up being clutter, something added
just because it could be done, not because we have compelling
use cases that can't be met with existing dicts, sets, and lists.


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