Nick writes:
M.-A. Lemburg wrote:
> I don't think that an administrative problem such as forward-
> porting patches to 3.x warrants breakage in the 2.x branch.
>
> After all, the renaming was approached for Python 3.0 and not
> 2.6 *because* it introduces major breakage.
>
> AFAIR, the discussion
This thread has diverged a bit from the original topic.
I suggest going ahead and adding pyprocessing to the library.
IMO, its functionality is going to be an essential capability as
more and more computers ship with multiple processors.
At this point, the basic API for pyprocessing seems well
t
* The 2.6-backported Mapping ABC has the 3.0 dict API,
that is, it uses keys() that returns a view etc.
Curious to hear what Guido thinks about this one.
A nice use of the Mapping ABC is to be able to
get 3.0 behaviors. I thought that was the whole
point of all these backports. If the ABC get
If you want to use the 3.0 mixins in 2.6, perhaps an alternate set of
APIs could be imported from the future? E.g. from future_collections
import Mapping. IIRC a similar mechanism was proposed for some
built-in functions, even though I see no traces of an implementation
yet.
Any know what happen
[Armin Ronacher]
Basically *the* problematic situation with iterable strings is something like
a `flatten` function that flattens out every iterable object except of strings.
Stated more generally: The problematic situation is that flatten()
implementations typically need some way to decide wh
"Jim Jewett"
It isn't really stringiness that matters, it is that you have to
terminate even though you still have an iterable container.
Well said.
Guido had at least a start in Searchable, back when ABC
were still in the sandbox:
Have to disagree here. An object cannot know in general
w
Steven D'Aprano" <[EMAIL PROTECTED]>
If built-in objects grew an __atomic__ attribute, you could
simplify the atomic() function greatly:
I may not have been clear enough in my previous post.
Atomicity is not an intrinsic property of an object or class.
How could you know in advance what various
I'm not against this, but so far I've not been able to come up with a
good set of methods to endow the String ABC with.
If we stay minimalistic we could consider that the three basic operations that
define a string are:
- testing for substring containment
- splitting on a substring into a list o
I would like to renew the discussion now that "there is a PEP" to see
if there are any outstanding things people would like to get resolved.
I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback
both here and elsewhere that people would rather see this in sooner in
some form, rath
ISTM, the whole reason people are asking for a String ABC is so you can write isinstance(obj, String) and allow registered
string-like objects to be accepted.
The downside is that everytime you want this for a concrete class or type, it is necessary to write a whole new ABC listing all of
the r
From: "Guido van Rossum" <[EMAIL PROTECTED]>
I'm willing to meet you halfway. I really don't want isinstance(x,
str) to return True for something that doesn't inherit from the
concrete str type; this is bound to lead to too much confusion and
breakage.
Probably true. It was an attractive id
[Raymond]
I propose the following empty abstract classes: String, Datetime, Deque,
and Socket.
[GvR]
Sounds like a mini-PEP is in place. It should focus on the code to
actually define these and the intended ways to use them.
Okay, will run a Google code search to see if real code exists
Target: Py2.6 and Py3.0
Author: Raymond Hettinger
Date: May 31, 2008
Motivation
--
The principal purpose of an abstract base class is to support multiple
implementations of an API; thereby allowing one concrete class to be
substitutable for another. This purpose is defeated when useful
Mini-Pep: An Empty String ABC
Target: Py2.6 and Py3.0
Author: Raymond Hettinger
Proposal
Add a new collections ABC specified as:
class String(Sequence):
pass
Motivation
--
Having an ABC for strings allows string look-alike classes to declare
themselves as
From: "Guido van Rossum" <[EMAIL PROTECTED]>
All this makes me lean towards a rejection of this proposal -- it
seems worse than no proposal at all. It could perhaps be rescued by
adding some small set of defined operations.
By subclassing Sequence, we get index() and count() mixins for free.
W
From: "Antoine Pitrou" <[EMAIL PROTECTED]>
It seems to me that Sequence.index()/count() and String.index()/count()
shouldn't have the same semantics.
In the former case they search for items in the Sequence, in the latter case
they search for substrings of the String.
And the same applies to _
* The API will become PEP 8 compliant
Doesn't that kill the intent that it's a drop-in replacement for
threading?
IMO, it is essential that the API match the theading module, PEP 8 be damned.
Raymond
___
Python-Dev mailing list
Python-Dev@python
I think its a small disaster to have the APIs be almost
the same but with trivial differences in spelling.
PEP 8 is a nice guideline but it seems to have become
an end in an of itself. The point of the PEP is to use
consistency as a memory cue, but having two sets of
method names that are almost
From: "Mike Klaas" <[EMAIL PROTECTED]>
A cleaner way to effectuate the transition would be to leave
the camelCase API in 2.6 (for both modules), switch to PEP 8
in py3k (for both modules)
+1
That makes good sense.
, and provide threading3k and multiprocessing3k modules in 2.6 that façade t
The only comment so far was to keep the __index__ method.
Other than that, is this good to go?
Raymond
- Original Message -
Target: Py2.6 and Py3.0
Author: Raymond Hettinger
Date: May 31, 2008
Motivation
--
The principal purpose of an abstract base class is to support
From: "Guido van Rossum" <[EMAIL PROTECTED]>
Unless more folks actually say they agree I don't want to go forward
with this. There was quite a bit of discussion about PEP 3141 and it
was accepted; striking this much from it with virtually no discussion
seems wrong to me.
Not sure how to generat
From: "Antoine" <[EMAIL PROTECTED]
For me the problem is not about ditching the % operator for an
intuitively-named method like format(). It's the format syntax which has
become much more complicated and error-prone without any clear advantage.
It's seems that way to me too. But, it may be on
[Terry Reedy]
On reading PEP3141 some months ago and again today, I thought and still do
that all the methods that depend on a 2s-complement representation and
implementation really belong to an implentation-defined subclass of
Integral. But I am not sure of the purpose of the class and of inc
numbers.py:
@property
def imag(self):
"""Real numbers have no imaginary component."""
return 0
@property
def denominator(self):
"""Integers have a denominator of 1."""
return 1
Raymond
-
From: "Guido van Rossum" <[EMAIL PROTECTED]>
Make that int() instead of long() and I'm okay with it.
Does anyone know why Integral says that __long__ is a required abstract method,
but not __int__?
Likewise, why is index() defined as long(self) instead of int(self)?
There may be some design
Still, I don't think this should be done. Flat is better than nested,
and adding hierarchy will make it *more* difficult to find anything
(except perhaps for the one person who did the rearrangement).
Yes. Grep is your friend.
Raymond
___
Python-Dev
What do you think about this code:
class A:
locals()[42] = 98
Seems people rely on it working. Do we consider it part of python
language? (Note that you cannot do the same with getattr/setattr which
checks if argument is a string)
Seems like a bug to me, but I don't think there is much we ca
"Function names should be lowercase, with words separated by underscores as
necessary to improve readability." -- PEP 8
If I'm reading this correctly, then underscores are not required everywhere.
Can some of these be shortened?
function:: active_count()
method:: Thread.get_name()
m
Nick> def getName(self):
Nick> assert self.__initialized, "Thread.__init__() not called"
Nick> return self.__name
Why is __name private to begin with? Any reason for the getters and setters?
Why isn't this just an attribute?
Raymond
__
PEP-3141 outlines an approach to writing binary operators to allow the
right operand to override the operation if the left operand inherits
the operation from the ABC.
Here is my first approximation at how to write them for the Integral mixins:
class Integral(Rational):
def __and__(self, oth
From: "Talin" <[EMAIL PROTECTED]>
There's been a lot of controversy/confusion about ordered dicts.
I think that is why all earlier proposals all died.
One of
the sources of confusion is that people mean different things when they
use the term "ordered dict": In some cases, the term is used
From: "Cesare Di Mauro" <[EMAIL PROTECTED]>
The same problem happens with dictionary updates:
d = {}
d[k1] = v1
d[k2] = v2
d[k1] = v3
The last instruction just replaces the existing entry, so I'm +0 for the first
result.
There's a difference. With dicts, the third insertion *replaces* the v
From: "Armin Ronacher" <[EMAIL PROTECTED]>
There are far more responses for that topic than I imagined so I would love
to write a PEP about that topic, incorporating the ideas/questions and
suggestions discussed here.
Instead of going straight to a PEP, I recommend opening a new wiki page
on th
Maciej Fijalkowski did an opcode analysis for PyPy,
it also shows the relative frequency of opcodes following a
specifc one:
http://codespeak.net/svn/user/fijal/opcodes.txt
Might it make sense to add more PREDICT()ions based
on this, e.g. for BUILD_SLICE -> BINARY_SUBSCR?
This particular one m
We're still working on the implementation details for math.sum().
When it's finished, the cmath equilvalent will be added.
Raymond
- Original Message -
From: "A.M. Kuchling" <[EMAIL PROTECTED]>
To:
Sent: Thursday, June 19, 2008 7:16 PM
Subject: [Python-Dev] sum() in math module not du
From: "Nick Coghlan" <[EMAIL PROTECTED]>
The 3.0 approach means that non-float floating point types still can't be displayed properly by bin()/oct()/hex(). The current 2.6
approach means every such class has to implement its own equivalent of PyNumber_ToBase.
Feel free to change the implementat
Issue 3008 has been re-opened for more commentary.
Raymond
- Original Message -
From: "Guido van Rossum" <[EMAIL PROTECTED]>
Since it's (potentially) a pretty small feature I might be convinced
to accept it in beta2, but I don't want the fact that it was committed
to force our hand. Ra
From: "Guido van Rossum" <[EMAIL PROTECTED]>
I don't care about the details of the patch until we have agreement
about which form the feature should take. We don't have that agreement
yet.
Updated to the patch to address everyone's review comments:
http://bugs.python.org/file10742/float8.
Just as a contrary point, I'm not particularly keen on the output
format (which takes the form '0b1 * 2.0 ** 0' as far as I can see),
That format was requested by everyone else on the tracker
discussion. What I originally wanted was something like 0b11.0101.
But that didn't round-trip through e
Would you mind reading the rest of *this* thread on python-dev and
respond to the discussion about the design of the feature?
The last four entries were from this thread. I don't know what else you want me to do. I can update the patch as people make
suggestions. That's pretty much it.
I reca
From: "Guido van Rossum" <[EMAIL PROTECTED]>
So as far as the feature design goes, I offer some suggestions: a new
module; or a new function in math; or a new method on float. Since
Raymond is the champion for the feature let him choose the API from
those alternatives.
I choose bin/hex/oct meth
From: "Guido van Rossum" <[EMAIL PROTECTED]>
Let's step back and discuss the API some more.
- Do we need all three?
I think so -- see the the reasons below. Of course, my first
choice was not on your list. To me, the one obvious way to
convert a number to a eval-able string in a different
[Mark Dickinson]
I have to admit that I can't see much use for octal floats.
Neither do I. They look weird to me.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
[MvL]
Then I'd argue that the feature should be symmetric:
If there is support for printing floating point numbers
as hex, there should also be support for hex floating
point literals.
[Mark]
I agree with this. Or at least support for hex floating point
strings, if not literals.
ISTM, tha
From: "Mark Dickinson" <[EMAIL PROTECTED]>
There's one other major difference between the C99 notation and the
current patch: the C99 notation includes a (hexa)decimal point. The
advantages of this include:
- the exponent gives a rough idea of the magnitude of the number, and
- the exponent do
From: "Barry Warsaw" <[EMAIL PROTECTED]>
There are two options. I could shift everything forward 2 weeks and
do the next betas on July 16th. Or we could wait until August 6th.
That would mean 6 weeks between betas. It's fine with me either way.
+1 for six weeks to allow the code to be mo
From: "Mark Dickinson" <[EMAIL PROTECTED]>
Does anyone have time to review the patch
http://bugs.python.org/file10876/hex_float5.patch
for issue 3008 (float <-> hexadecimal string conversion):
I'll look at it today and tomorrow.
Raymond
___
Python
Some effort needs to be made to clear the standard library of -3 warnings. Running -3 on production code usually involves
exercising library code so the useful result is obscured by Python complaining about itself. Since that use case involves the users
own tests, I don't think the effort needs
Michael Foord <[EMAIL PROTECTED]> writes:
The full list of changes proposed (feel free to start - but ping me or
the list) and not shot down was something like:
[…]
Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.
Given all of the language changes in
From: "Ben Finney" <[EMAIL PROTECTED]>
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpler test module
using the py.test syntax. That i
From: "Michael Foord" <[EMAIL PROTECTED]>
However, to provide readable output for errors in even simple tests
(like a == b) py.test does magic with stack frames and code objects - in
order to discover the objects being compared.
Don't have to go that route. Can use plain python assert failure
``set_up(…)``
Replaces ``setUp(…)``
. .
``tear_down(…)``
Replaces ``tearDown(…)``
Am I the only one who finds this sort of excessive pep-8 underscoring to be
horrorific?
Nobody I know spells setup and teardown as two words. I dread using the module with these new names. Underscores are not
It looks like Benjamin Peterson is right, in Python 2.5 TestCase already
appears to be a new style class:
Yep. I stand corrected. It looks like that changed five years ago (rev 28064). Not sure how that slipped through but it doesn't
seem to have caused any problems.
Raymond
_
From: "Michael Foord" <[EMAIL PROTECTED]>
Maybe Python needs a good mocking module in the standard library. There
are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
-1
This comes up occassionally and gets shot down.
http://bugs.python.org/issue708125
Mock objects mean
From: "Michael Foord" <[EMAIL PROTECTED]>
Maybe Python needs a good mocking module in the standard library. There
are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
-1
This comes up occassionally and gets shot down.
http://bugs.python.org/issue708125
And: http://bug
From: "Michael Foord" <[EMAIL PROTECTED]>
I assume this doesn't rule out the addition of [some of..] the new
convenience test methods?
In Kent Beck's book on Test Driven Development, he complains that most
unittest implementations spawned from his original work have grown far
too complicated
If some people want to proceed down the path of "useful additions",
I challenge them to think bigger. Give me some test methods that
improve my life. Don't give me thirty ways to spell something I can
already do.
From: "Michael Foord" <[EMAIL PROTECTED]>
I assert that... the following changes
I'd quote “Practicality beats purity”, but I'm not even sure if it
is purity that you have in mind.
From: "Ben Finney" <[EMAIL PROTECTED]>
Close: I'm interested in keeping camel's noses out of tents.
I have no idea what you mean or are trying to accomplish
(unless the camel's nose refers to c
From: "Eric Smith" <[EMAIL PROTECTED]>
I have this ready for checkin (with docs and tests). I'd like to get it
in for this beta, since it does involved changed behavior, no matter how
small ('1e+100' becomes '1E+100' with '%F'). But it relies on the
platform's vsnprintf to do the right thing wi
From: Karen Tracey
I noticed when trying out Python's 2.6b2 release that the repr of Decimal has
changed since 2.5. On 2.5:
...
quotes were used whereas on 2.6b2:
...
single quotes are used. Searching around I see this was done in r60773 with
the log message:
Fix decimal repr which shoul
The new float.hex() is really nice. Would like to augment it with a matching float.bin() method using the same notation and
normalization and leaving all the rightmost bits as Guido suggested. I think this would help demystify floats and make it
straightforward to show exactly what is happening
Further, while A**B is not so common, A**n is quite common (for
integral n, in the sense of repeated matrix multiplication). So a
matrix multiplication operator really should come with a power
operator cousin.
Which obviously should be @@ :-)
I think much of this thread is a repeat of conversa
[Michele Simionato]
Recently I have opened a blog on Artima and I am publishing a
few Python-related essays I had in store. In particular a trilogy
of papers about "super". From the foreword:
"""
In 2004 I decided to write a comprehensive paper documenting
``super`` pitfalls and traps, ...
Th
[Raymond]
Cooperative multiple inheritance is *not* about mixing two unrelated
parents that just happen to use the same method name but have
different semantics and were not designed to cooperate with each other.
The A-B-C-D diagrams and foo/bar methods in the examples are
deceptive because they
From: "Armin Ronacher" <[EMAIL PROTECTED]>
len(ri)
4
ri.next()
4
len(ri)
3
This is the only reverse iterator with that sort of behavior.
Use the bug tracker please and assign to me.
At one time, some iterators had the ability to know
their own length and that would change as the
iterato
From: <[EMAIL PROTECTED]>
I think it would benefit everyone if this discussion would end up with
some patches to the library documentation that documented the semantics
of super() more completely in the reference documentation and the
"multiple inheritance" area of the tutorial, so that when pe
I think this should be deferred to Py3.1.
This decision was not widely discussed and
I think it likely that some users will
be surprised and dismayed. The release
candidate seems to be the wrong time to
yank this out (in part because of the surprise
factor) and in part because I think the chan
[Barry]
I'm not going to release rc1 tonight.
Can I go ahead with some bug fixes and doc improvements
or should I wait until after Friday?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
[C. Titus Brown]
I'm happy to be told that bsddb is too much of a maintenance burden for
Python 2.6/3.0 to have -- especially since it's gone from 3.0 now ;) --
but I don't think the arguments that *it won't matter that it's not
there* have been very credible.
Not credible, not widely discuss
[Guido van Rossum]
Well, from the number of release blockers it sounds like another 3.0
beta is the right thing. For 2.6 however I believe we're much closer
to the finish line -- there aren't all those bytes/str issues to clean
up, for example! And apparently the benefit of releasing on schedule
[Steve Holden"]
Of course there is also the option of treating Python 3 as a different
language, and having a Py3Pi website as well. This might not be as
wasteful as it at first seems.
It would be nice if we had a way of marking Py2.6 recipes that still
work when run through 2-to-3 and then au
[Neal Norwitz]
Should we plan to put out a final 2.5 release? If so, should we
continue to backport fixes (like Martin's removal of Alpha in
setup.py)? My preference is that we do put out a final 2.5 that has
all accumulated bug fixes. Then close the branch. That way if we put
out a security
[A.M. Kuchling]
Can you please clarify your meaning? Do you mean that
* we haven't been backporting fixes to 2.5?
Unsure. I surely have given zero attention to 2.5.
* we should wait to see if any horrible problems are reported in 2.6?
Yes. That would be a great idea.
* we need to look
[Barry Warsaw]
So, we need to come up with a new release schedule for Python 3.0. My
suggestion:
15-Oct-2008 3.0 beta 4
05-Nov-2008 3.0 rc 2
19-Nov-2008 3.0 rc 3
03-Dec-2008 3.0 final
Given what still needs to be done, is this a reasonable schedule? Do
we need two more betas?
Yes to bot
Background
--
In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those
equivalents are only approximate but they seem to have greatly enhanced the docs. Something similar is in the builtin docs for
any() and all(). The ne
[Christian Heimes]
The idea sounds great!
Are you planing to embed the pure python code in C code?
Am experimenting with a descriptor that fetches the attribute string from a separate text file. This keeps the C build from getting
fat. More importantly, it let's us write the execable string
Yes, I'm looking a couple of different approaches to loading the strings.
For now though, I want to focus on the idea itself, not the implementation.
The important thing is to gather widespread support before getting into
the details of how the strings get loaded.
Raymond
- Original Messa
Raymond Hettinger wrote:
* It will assist pypy style projects and other python implementations
when they have to build equivalents to CPython.
* Will eliminate confusion about what functions were exactly intended to
do.
* Will confer benefits similar to test driven development where the
From: "Doug Hellmann" <[EMAIL PROTECTED]
This seems like a large undertaking.
Not necessarily. It can be done incrementally, starting with things like str.split() that almost no one understands completely. It
should be put here and there where it adds some clarity.
I'm sure you're not un
I think this should be taken off of python-dev until
you have some quality measurements,
know what's going on, and have an actionable idea.
Aside from list specialization versus a general iterator
protocol, there is no fat in the min/max implementation.
It loops, it compares, it returns.
If we w
From: "Guido van Rossum" <[EMAIL PROTECTED]>
The right thing to do with XXX comments is to read them when you're in
their vicinity, and to act when the urge becomes too strong to deal
with any one in particular. Dealing with them en masse is just asking
for a migraine.
I concur.
Raymond
_
In concur that it is not a regression (esp for Py2.6).
OTOH, it would be nice to have -m run as expected.
It seems reasonable to me to get this working for 3.0.
Raymond
- Original Message -
From: "Guido van Rossum" <[EMAIL PROTECTED]>
To: "Lisandro Dalcin" <[EMAIL PROTECTED]>
Cc: "Nic
From: "A.M. Kuchling" <[EMAIL PROTECTED]>
I think we should also have a statement upon on python.org about
future plans: e.g.
* that there will be a Python 2.7 that will incorporate what we learn from
people trying to port,
* that 3.1 will rearrange the standard library in mostly-known ways, an
From: "A.M. Kuchling" <[EMAIL PROTECTED]>
Perhaps the statement could say something like "we do not expect
most Python packages will be ported to the 3.x series until
around the time 3.1 is released in X months." (where X=12? 6?)
I would leave out any discussion of 3.1. Its content and rele
2008/12/4 Raymond Hettinger <[EMAIL PROTECTED]>:
Also, we don't know the timing of the third-party updates.
Some may never get converted. Some may convert quickly
and easily. Someone (perhaps me) may organize a series of
funded sprints to get many of the major packages converted.
BTW, 3.0 went out the door with test_binascii failing on windows.
Was surprised that some buildbot wasn't complaining.
- Original Message -
From: "Antoine Pitrou" <[EMAIL PROTECTED]>
To:
Sent: Saturday, December 06, 2008 3:15 PM
Subject: [Python-Dev] Buildbots for 2.6 and 3.0
Hello
Strong +1
Are the RMs on board?
- Original Message -
From: "Benjamin Peterson" <[EMAIL PROTECTED]>
To:
Sent: Saturday, December 06, 2008 3:18 PM
Subject: [Python-Dev] 3.0.1 possibilities
Since the release of 3.0, several critical issues have come to our
attention. Namely, the built
From: "Victor Stinner"
Why an svn account instead of just using the amazing bug tracker? Just because
there are not enough people to review/commit patches on the tracker and so
there are more and more open issues (and so more and more lost patches) :-( I
will be able to work faster using the
Does anyone here have access to Mathematica?
I would like to know what it returns for:
In[1]:= Permutations({a, b, c}, {5})
Knowing this will help resolve a feature request
for itertools.permutations() and friends.
Thanks,
Raymond
___
Python-Dev ma
From: "M.-A. Lemburg"
The question to put up against this is: How often do you get
irritated by lines not being correctly indented ?
Basically never.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
_PyObject_LengthHint() is specified to never fail.
If any exception occurs along the way, it returns a
default value. In the context of checking for length
hints from an iterator, this seems reasonable to me.
If you want this changed, I can use a negative return
value for other than an attribute
If you want this changed, I can use a negative return
value for other than an attribute error, and modify
the calling code to handle the exception.
To me this isn't worth making the code slower and
more complex. But I can also see wanting to catch
a SystemError at any possible step.
It has the
Martin closed a patch http://bugs.python.org/issue4933 for adding support so
that Python runs on Haiku.
The theory is that we don't want to support minority operation systems. My view is that we should support those systems to the
extent that someone like the OP is willing to maintain the hand
Why does numbers.py say:
# Copyright 2007 Google, Inc. All Rights Reserved.
# Licensed to PSF under a Contributor Agreement.
Weren't there multiple contributors including non-google people?
Does Google want to be associated with code that
was submitted with no tests?
Do we want this sort
From: "Brett Cannon"
1. Why is three space indents the preferred indentation level?
I've also wondered about this. It is somewhat incovenient
when bringing in code samples from files with four space indents.
Raymond
___
Python-Dev mailing list
Py
I have another question about doc formatting.
What controls whether section headers get urls with a custom named jump target instead of
a default name like "id1"?
In particular, look at the urls for:
http://docs.python.org/dev/library/collections.html#id1
versus
http://docs.python.org/de
In particular, look at the urls for:
http://docs.python.org/dev/library/collections.html#id1 versus
http://docs.python.org/dev/library/collections.html#abcs-abstract-base-classes
I would like all of the targets to have meaningful names.
[Brett]
Not sure from a sphinx perspective, but Docutil
[Terry Reedy]
Bottom line to me. The current notion of copyright does not work too
well with evolving, loosely collective works (which eventually become
'folklore').
I'm at a loss of why the notice needs to be there at all. AFAICT, we've
had tons of contributions from googlers and only one h
[Raymond Hettinger]
I'm at a loss of why the notice needs to be there at all.
[GvR]
There's a difference between contributing a whole file and
contributing a patch. Patches do not require copyright notices. Whole
files do. This is not affected by later edits to the file.
That m
the post, but I consider it
to be a good practice to introduce oneself when posting the first
time, so: Hello, my name is Konrad, I'm an IT student and I'm
following python-dev for some time, but never posted before.
Hello Konrad. Welcome to python-dev.
Raymond Hettinger
___
801 - 900 of 1487 matches
Mail list logo
