On 10/26/2010 05:35 PM, Raymond Hettinger wrote:
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
I wonder what you may think. Keep it in pydoc or move it to the
HTTP package? Document it or not?
I still would like to know what your thoughts are concerning where to put,
and/or how to pack
On Oct 26, 2010, at 09:54 PM, Antoine Pitrou wrote:
>I think it comes down to the preference of whoever works the most
>actively on it. Michael is the most active contributor to unittest by
>far, and I suppose he prefers it to be split into several submodules.
And that seems perfectly reasonable
On Tue, 26 Oct 2010 16:46:15 -0400, Michael Foord wrote:
> On 26/10/2010 15:05, R. David Murray wrote:
> > On Tue, 26 Oct 2010 10:39:19 -0700, Raymond
> > Hettinger wrote:
> >> If someone wants to reorganize code for clarity, I would prefer keeping
> >> it within one file, bringing related functi
On Oct 26, 2010, at 04:46 PM, Michael Foord wrote:
>I find the big-ball-of-mud style development, where everything lives inside
>huge monolithic modules, very painful. I also think that it is an extremely
>bad example for new developers. There is something to be said for consistency
>within the st
Not forgetggin the StringI object in cStringIO.
IMHO, not accepting buffers by these objects can be consided a bug, that needs
fixing.
K
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Kristján Valur Jónsson
Sen
Although 2.7 has the new buffer interface and memoryview objects, these are
widely not accepted in the built in modules.
Examples are the structmodule, some of the socketmodule apis, structmodule, etc.
IMHO this is unfortunate. For example when doign network io, you would want
code like this:
B
On Tue, Oct 26, 2010 at 5:37 PM, Fred Drake wrote:
> On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord
> wrote:
>> I find the big-ball-of-mud style development, where everything lives inside
>> huge monolithic modules, very painful. I also think that it is an extremely
>> bad example for new develop
On 10/26/2010 05:35 PM, Raymond Hettinger wrote:
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
I've worked on pydoc to make it much nicer to use in a browser.
While you're at it. Can you please modernize the html
and create a style sheet? Right now, all of formatting
is deeply intertwined
Robert Kern wrote:
This thread is off-topic for python-dev, which is intended for the
development *of* the Python interpreter, not development *in* Python.
I got the impression that he was asking for a new feature --
i.e. to be allowed to write a call on the left of an assignment,
with a corre
--- On Tue, 10/26/10, P.J. Eby wrote:
> If all you really want this for is reloading, it would
> probably make more sense to simply modify the existing class
> and function objects using the reloaded values as a
> template, then save the modified classes and functions back
> to the module.
>
> Ha
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
> I've worked on pydoc to make it much nicer to use in a browser.
While you're at it. Can you please modernize the html
and create a style sheet? Right now, all of formatting
is deeply intertwined with content generation.
Fixing that would be a *
On 10/26/10 5:05 PM, Bj Raz wrote:
I'll look into SAGE, I am still curious if there is, a way, to write this in
native python, cause I'm currently plotting in Autodesk Maya, and using Python.
This thread is off-topic for python-dev, which is intended for the development
*of* the Python interp
--- On Tue, 10/26/10, Neil Schemenauer wrote:
> > I am happy to write up a PEP for this feature.
> > I'll start that process now, though if anyone
> > feels that this idea has no chance of
> > acceptance please let me know.
>
> I think a feature that allows modules to be more
> reliability rel
At 10:24 AM 10/26/2010 -0700, Peter Ingebretson wrote:
I have a relatively large application written in Python, and a
specific use case where it will significantly increase our speed
of iteration to be able to change and test modules without needing
to restart the application.
If all you really
I'll look into SAGE, I am still curious if there is, a way, to write this in
native python, cause I'm currently plotting in Autodesk Maya, and using Python.
Sent from my iPhone
On Oct 24, 2010, at 12:51 PM, Benjamin Peterson wrote:
> 2010/10/24 Bj Raz :
>> I was looking for a way to set a fun
On 10/26/2010 02:34 PM, Raymond Hettinger wrote:
FWIW, it wasn't that big (approx 2500 lines).
The argparse, difflib, doctest, pickletools, pydoc, tarfile modules
are about the same size and the decimal module is even larger.
Please don't split those.
Sense you mention this...
I've worked on
On 08:28 pm, pinge...@yahoo.com wrote:
--- On Tue, 10/26/10, "Martin v. L�wis" wrote:
I think this then mandates a PEP; I'm -1 on the feature also.
I am happy to write up a PEP for this feature. I'll start that
process now, though if anyone feels that this idea has no chance of
acceptance pl
Peter Ingebretson wrote:
> I am happy to write up a PEP for this feature. I'll start that
> process now, though if anyone feels that this idea has no chance of
> acceptance please let me know.
I think a feature that allows modules to be more reliability
reloaded could be accepted. Martin's su
--- On Tue, 10/26/10, "Martin v. Löwis" wrote:
>>> I think this then mandates a PEP; I'm -1 on the feature also.
>>
>> I am happy to write up a PEP for this feature. I'll start that
>> process now, though if anyone feels that this idea has no chance of
>> acceptance please let me know.
>
> I
On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord
wrote:
> I find the big-ball-of-mud style development, where everything lives inside
> huge monolithic modules, very painful. I also think that it is an extremely
> bad example for new developers.
Gadzooks, Michael! Something else we agree on. 2000
Le mardi 26 octobre 2010 09:31:11, Georg Brandl a écrit :
> Am 25.10.2010 19:37, schrieb victor.stinner:
> > Author: victor.stinner
> > Date: Mon Oct 25 19:37:18 2010
> > New Revision: 85838
> >
> > Log:
> > update gitignore
> >
> > Added:
> >python/branches/py3k/.gitignore
>
> This looks mo
Am 26.10.2010 22:28, schrieb Peter Ingebretson:
> --- On Tue, 10/26/10, "Martin v. Löwis" wrote:
>> I think this then mandates a PEP; I'm -1 on the feature also.
>
> I am happy to write up a PEP for this feature. I'll start that
> process now, though if anyone feels that this idea has no chanc
On 26/10/2010 15:05, R. David Murray wrote:
On Tue, 26 Oct 2010 10:39:19 -0700, Raymond
Hettinger wrote:
If someone wants to reorganize code for clarity, I would prefer keeping
it within one file, bringing related functions together and using
comment lines to mark the major sections. ISTM, th
--- On Tue, 10/26/10, "Martin v. Löwis" wrote:
> I think this then mandates a PEP; I'm -1 on the feature also.
I am happy to write up a PEP for this feature. I'll start that
process now, though if anyone feels that this idea has no chance of
acceptance please let me know.
Thanks,
Peter
Am 26.10.2010 19:53, schrieb Brett Cannon:
> Can whomever has edit access to the Python Google Calendar add this?
Done.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall
On Tue, 26 Oct 2010 12:34:30 -0700
Raymond Hettinger wrote:
>
> FWIW, it wasn't that big (approx 2500 lines).
> The argparse, difflib, doctest, pickletools, pydoc, tarfile modules
> are about the same size and the decimal module is even larger.
> Please don't split those.
I think it comes down
On Oct 26, 2010, at 12:18 PM, Benjamin Peterson wrote:
> 2010/10/26 Alexander Belopolsky :
>> On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
>> wrote:
>> ..
>>> Packaging is not always wrong. Maybe it was the right thing to do for
>>> unittest, maybe not.
>>
>> This is an example that I pe
In article <20101026200234.5f8e8...@pitrou.net>,
Antoine Pitrou wrote:
> You could use own of the "official" mirrors at
> http://code.python.org/hg/
The "official" hg mirrors work great: in my experience, faster than svn
and simpler with all the useful history information retained from the
ori
2010/10/26 Alexander Belopolsky :
> On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
> wrote:
> ..
>> Packaging is not always wrong. Maybe it was the right thing to do for
>> unittest, maybe not.
>
> This is an example that I personally find ill-justified. Particularly
> annoying is the fact t
On Tue, 26 Oct 2010 10:39:19 -0700, Raymond Hettinger
wrote:
> If someone wants to reorganize code for clarity, I would prefer keeping
> it within one file, bringing related functions together and using
> comment lines to mark the major sections. ISTM, this is cleaner than
> introducing a new di
On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
wrote:
..
> Packaging is not always wrong. Maybe it was the right thing to do for
> unittest, maybe not.
This is an example that I personally find ill-justified. Particularly
annoying is the fact that opening __init__.py gives you a list of
rel
On Tue, 26 Oct 2010 10:42:27 -0700
Ned Deily wrote:
> In article <20101026085124.4c684...@mission>,
> Barry Warsaw wrote:
> > On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
> > >On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote:
> > >> This looks more like "Add gitignore". Do we really w
Am 26.10.2010 19:24, schrieb Peter Ingebretson:
> --- On Tue, 10/26/10, Benjamin Peterson wrote:
>> Is there any reason that you'd want to do this?
>>> http://doublestar.org/python-hot-loading-prototype/
>
> I have a relatively large application written in Python, and a
> specific use case where
Can whomever has edit access to the Python Google Calendar add this?
On Mon, Oct 25, 2010 at 14:03, Antoine Pitrou wrote:
>
> Hello,
>
> The development team of the Python interpreter (a.k.a python-dev) is
> organizing a bug week-end on Saturday 20th and Sunday 21st of November.
>
> We would like
In article <20101026085124.4c684...@mission>,
Barry Warsaw wrote:
> On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
> >On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote:
> >> This looks more like "Add gitignore". Do we really want to check in
> >> ignore files for every possible DVCS?
> >
On Oct 26, 2010, at 9:31 AM, Guido van Rossum wrote:
> I would like Gregor Lingl's approval of turning turtle.py into a package. It
> might make some things harder for novices, e.g. trackebacks and just browsing
> the source code.
>
> Also many people don't expect to find any code in a file na
--- On Tue, 10/26/10, Benjamin Peterson wrote:
> Is there any reason that you'd want to do this?
> > http://doublestar.org/python-hot-loading-prototype/
I have a relatively large application written in Python, and a
specific use case where it will significantly increase our speed
of iteration t
--- On Tue, 10/26/10, Hrvoje Niksic wrote:
> What about objects that don't implement tp_traverse because
> they cannot take part in cycles?
A significant majority of objects that can hold references to other
objects can take part in cycles and do implement tp_traverse. My
original thought was
2010/10/26 Peter Ingebretson :
> I have a patch that adds a new function to the gc module. The gc.remap()
> function uses the tp_traverse mechanism to find all references to any keys
> in a provided mapping, and remaps these references in-place to instead point
> to the value corresponding to each
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
>On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote:
>> This looks more like "Add gitignore". Do we really want to check in
>> ignore files for every possible DVCS?
>
>No, but supporting the current big four open source ones (svn, hg,
>bzr, git)
Nick Coghlan gmail.com> writes:
> Looking at your checkin though, I wonder if it might be worth
> implementing some little formatting style classes to get rid of the
> if/elif chains from the Formatter code. Something like:
Fair comment: I did think about the messiness of that if/elif, but consid
Line 31 (in Pastebin): _STYLE_CODES = tuple("% { $".split())
Is this really necessary? Why not
_STYLE_CODES = ('%', '{', '$')
On Tue, Oct 26, 2010 at 1:15 PM, Nick Coghlan wrote:
> On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan wrote:
> > On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip
> wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl wrote:
> This looks more like "Add gitignore". Do we really want to check in
> ignore files for every possible DVCS?
No, but supporting the current big four open source ones (svn, hg,
bzr, git) seems reasonable enough.
Cheers,
Nick.
--
Nick Coghla
On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan wrote:
> On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip wrote:
>> Comments welcome. Assuming there are no strong objections asking for
>> reversion
>> of this change, I'll publicise to the wider community in a few days.
>
> It strikes me as a solid, p
On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip wrote:
> Comments welcome. Assuming there are no strong objections asking for reversion
> of this change, I'll publicise to the wider community in a few days.
It strikes me as a solid, pragmatic solution to a thorny problem.
Looking at your checkin t
On 10/26/2010 07:04 AM, Peter Ingebretson wrote:
I have a patch that adds a new function to the gc module. The gc.remap()
function uses the tp_traverse mechanism to find all references to any keys
in a provided mapping, and remaps these references in-place to instead point
to the value correspon
Am 25.10.2010 19:37, schrieb victor.stinner:
> Author: victor.stinner
> Date: Mon Oct 25 19:37:18 2010
> New Revision: 85838
>
> Log:
> update gitignore
>
> Added:
>python/branches/py3k/.gitignore
This looks more like "Add gitignore". Do we really want to check in
ignore files for every pos
47 matches
Mail list logo
