Greetings,
I'm writing a module for current Python 2.6 and I would like to
reference documentation for Python 2.6, because I am not sure if
behavior won't be changed in further series. So far I can link only
to:
http://docs.python.org/ (stable, 2.6)
http://docs.python.org/dev/ (2.7)
On Feb 03, 2010, at 09:55 AM, Guido van Rossum wrote:
On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw ba...@python.org wrote:
-snip snip-
from __future__ import unicode_literals
def func(foo, bar):
print foo, bar
kw = {'foo': 7, 'bar': 9}
func(**kw)
-snip snip-
That
Brett Cannon wrote:
But what does expected location mean? If I am importing foo.bar
where foo.__path__ has multiple path entries, which one is supposed to
be used to set the hypothetical location of source for __file__? I
guess going with the first one would be somewhat reasonable, but it's
Matt Knox a écrit :
Jesse Noller jnoller at gmail.com writes:
We already have an implementation that spawns a
subprocess and then pushes the required state to the child. The
fundamental need for things to be pickleable *all the time* kinda
makes it annoying to work with.
just a
On Feb 03, 2010, at 11:50 PM, Ronald Oussoren wrote:
Barry's answer was yes back in October.
I will backport the patch if Barry says it's fine. Feel free to ping me if
that doesn't happen before the end of next week.
I still think this should go in 2.6.5. The patch does not apply to the
On Feb 03, 2010, at 08:52 PM, Martin v. Löwis wrote:
As an aside, I think this should be documented *somewhere* other than
just in import.c! I'd totally forgotten about it until I read the
source and almost missed it. Either it should be documented or it
should be ripped out.
The -U
Pascal Chambon writes:
I don't really get it there... it seems to me that multiprocessing only
requires picklability for the objects it needs to transfer, i.e those
given as arguments to the called function, and thsoe put into
multiprocessing queues/pipes. Global program data needn't be
On 04:58 pm, jaeda...@gmail.com wrote:
Jesse Noller jnoller at gmail.com writes:
We already have an implementation that spawns a
subprocess and then pushes the required state to the child. The
fundamental need for things to be pickleable *all the time* kinda
makes it annoying to work with.
All,
I've reviewed PEP 345 and PEP 386 and am satisfied that after some
small improvements they will be accepted. Most of the discussion has
already taken place.
I have one comment on PEP 345: Why is author-email mandatory? I'm sure
there are plenty of cases where either the author doesn't want
On Wed, Feb 3, 2010 at 13:33, Martin v. Löwis mar...@v.loewis.de wrote:
Guido van Rossum wrote:
On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan ncogh...@gmail.com
wrote:
On the issue of __file__, I'd suggesting not being too hasty in
deprecating that in favour of __source__. While I can see
On Thu, Feb 4, 2010 at 00:57, anatoly techtonik techto...@gmail.com wrote:
Greetings,
I'm writing a module for current Python 2.6 and I would like to
reference documentation for Python 2.6, because I am not sure if
behavior won't be changed in further series. So far I can link only
to:
On approximately 1/30/2010 4:00 PM, came the following characters from
the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
variable `$PYTHONPYR` is set, then Python will create a `foo.pyr`
directory and write a `pyc` file to that directory with the
On Feb 4, 2010, at 4:59 AM, Barry Warsaw wrote:
I still think this should go in 2.6.5. The patch does not apply to the
current 2.6 branch because of changes in setup.py. If the patch is ported,
reviewed and works with no regressions (when libreadline is both installed on
OS X 10.5 and
Brett Cannon wrote:
My thinking is we deprecate get_filename() and introduce some new method
that returns a two-item tuple (get_paths?). First item is where the
source should be, and the second is where the bytecode is if it exists
(else it's None). Putting both calculations into a single
Glenn Linderman wrote:
Alt. C... source-file-dir/__pyr_version__, each Python version with
different bytecode would have some sort of version string or magic
number that identifies it, and would look only in that directory for its
.pyc/.pyo files. I prefer C for 4 reasons: 1) easier to blow
On Thu, Feb 4, 2010 at 13:51, Nick Coghlan ncogh...@gmail.com wrote:
Brett Cannon wrote:
My thinking is we deprecate get_filename() and introduce some new method
that returns a two-item tuple (get_paths?). First item is where the
source should be, and the second is where the bytecode is if
Glenn Linderman wrote:
On approximately 1/30/2010 4:00 PM, came the following characters from
the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
variable `$PYTHONPYR` is set, then Python will create a `foo.pyr`
directory and write a `pyc` file to
On Thu, Feb 4, 2010 at 8:20 PM, Guido van Rossum gu...@python.org wrote:
[..]
I have one comment on PEP 345: Why is author-email mandatory? I'm sure
there are plenty of cases where either the author doesn't want their
email address published, or their last know email address is no longer
On approximately 2/4/2010 2:28 PM, came the following characters from
the keyboard of Eric Smith:
Glenn Linderman wrote:
On approximately 1/30/2010 4:00 PM, came the following characters
from the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
Am 04.02.2010 08:57, schrieb anatoly techtonik:
Greetings,
I'm writing a module for current Python 2.6 and I would like to
reference documentation for Python 2.6, because I am not sure if
behavior won't be changed in further series. So far I can link only
to:
http://docs.python.org/
20 matches
Mail list logo
