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)
http://docs.p
On Feb 03, 2010, at 09:55 AM, Guido van Rossum wrote:
>On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw wrote:
>> -snip snip-
>> from __future__ import unicode_literals
>>
>> def func(foo, bar):
>> print foo, bar
>>
>> kw = {'foo': 7, 'bar': 9}
>> func(**kw)
>> -snip snip-
>>
>> T
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
Matt Knox a écrit :
Jesse Noller 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 lurker here...
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 th
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.
>>
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 pic
On 04:58 pm, jaeda...@gmail.com wrote:
Jesse Noller 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.
This require
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 t
On Wed, Feb 3, 2010 at 13:33, "Martin v. Löwis" wrote:
> Guido van Rossum wrote:
> > On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan
> wrote:
> >> On the issue of __file__, I'd suggesting not being too hasty in
> >> deprecating that in favour of __source__. While I can see a lot of value
> >> in h
On Thu, Feb 4, 2010 at 00:57, anatoly techtonik 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:
>
> http://docs.py
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 he
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 m
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 blo
On Thu, Feb 4, 2010 at 13:51, Nick Coghlan 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 it exists
>
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 th
On Thu, Feb 4, 2010 at 8:20 PM, Guido van Rossum 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
> valid. (Tarek resp
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
varia
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.or
20 matches
Mail list logo
