Re: [Python-Dev] Python sprint mechanics
Greg Ewing wrote: > Tim Peters wrote: >> Instead it would make best sense for each >> sprint project to work in its own branch, something SVN makes very >> easy, but only for those who _can_ commit. > > There's no way of restricting commit privileges to > a particular branch? In the current setup, not easily. However, sprinters would certainly restrain themselves to the branches they are told to use. IOW, technical mechanisms for fine-tuned write access are often besides the point: you first need to give these people any kind of write access at all, and then you find that further restricting that can readily be done without any technical enforcement. Or, to put it yet in a different way: whether or not commit privileges are restricted, you need to add the sprinters to the committers list first, unless you want to allow anonymous commits to these branches. Just to not be mistaken: it is technically fairly easy to add somebody to the committers list. So technical, there is no problem to add all sprinters. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] total ordering.
On Sat, May 06, 2006 at 03:12:11AM -0700, Josiah Carlson wrote: > > "Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > > This problem has nothing to do with dictionaries and hashing, it has to > > > do with the fact that there may not be a total ordering on the elements > > > of a sequence. > > > > It is sad. I did not know it. Therefore and have not understood. > > > > I have looked in Google on "python dev total ordering". On intentions to > > correct this problem I have not found anything. It already earlier was > > discussed ? > > Not really. It has to do with how non-comparable instances compare to > each other. Generally speaking, when instances aren't comparable, > Python compares their type, which is actually comparing the names of > types. This wouldn't be a big deal, except that: > > >>> str < tuple < unicode > True > > And you can actually compare str and unicode, so, if you have a str that > is greater than the unicode, you run into this issue. With unicode > becoming str in Py3k, we may not run into this issue much then, unless > bytes are comparable to str, in which case we end up witht the same > problems. > > Actually, according to my google of "python dev total ordering", it > gives me... > > http://mail.python.org/pipermail/python-dev/2003-March/034169.html > http://mail.python.org/pipermail/python-list/2003-March/154142.html > > Which were earlier discussions on this topic, which are quite topical. > The ultimate solution is to choose a total ordering on types and > consider the problem solved. Then list.sort() and binary trees will > work properly. > Thanks for so detailed answer. Under these references discussion is conducted is presented in the form of "so is", instead of "as it to correct". Therefore I would like to mention a question "as it to correct". In case of incomparability of types can be it is meaningful compare the identifiers compared to each concrete type. More truly on them to calculate weight which will play a direct role in case of impossibility of comparison of types. Below one of variants of the decision of this problem is resulted. To each type of data in Python to add three fields: .. int tp_id; int tp_qualifier; int tp_weight; .. Rigidly to appoint some built in and external to types identifiers (tp_id). The others receive free identifiers on their initialization. Except for that types should be classified on their basic properties - tp_qualifier. The type can be classified as: 0 = None 1 = integer (bool, int, long, etc..) 2 = float (decimal, float, etc..) 3 = math (complex, matrix may be ?? ) 4 = string (str, unicode, splice, etc..) 5 = sequence (iterators, deque, xrange, enumerate, etc..) 6 = array (tuple, list, bytes, array, etc..) 7 = dictionary (dict, defdict, etc..) 8 = set (set, etc..) 9 = file (file, socket.socket, cStringIO.StringIO) .. 127 = non qualifier (sre.*, datetime.*, ClassType, IntsenceType, etc..) It is the approximate list on which it will be convenient to classify types (in my opinion). The weight can be precisely set in structure or if be equal -1 should is calculated under the formula: ob_type->tp_weight = (ob_type->tp_qualifier<<24) + (ob_type->tp_id<<8) Thus objects with similar properties will follow one after another. A problem can make external types. But if to develop further classification, problems to arise should not. -- SY. Vladimir Stepanov ___ Python-Dev mailing list [email protected] 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 3102: Keyword-only arguments
> > would have thought that the one obvious way to get rid of > > the wanky feeling would have been to write: > > > > def make_person(name, age, phone, location): ... > > > > make_person(name, age, phone, location) > > This doesn't fly in something like PyGUI, where there > are literally dozens of potential arguments to many > of the constructors. The only sane way to deal with > that is for them to be keyword-only, at least > conceptually if not in actual implementation. Probably. I don't know enough about library design in Python to meaningfully criticize the Keyword-only arguments suggestion. However, I do know enough about Python to know that the make_person function is a really bad example. The one obvious way to write make_peson is to use four positional arguments, name, age, phone, location and not complicate the function by throwing in required keyword arguments. It would be nice to instead see some real examples of the usefulness of the required keyword-only arguments. Like from your PyGUI or maybe from the standard library? But IMHO, your design is broken if you need to send dozens of arguments to any function or method. -- mvh Björn ___ Python-Dev mailing list [email protected] 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 3102: Keyword-only arguments
BJörn Lindqvist wrote: > But IMHO, your design is broken if you need > to send dozens of arguments to any function or method. My design allows property values to be specified using keywords in the constructor. You typically only use a few of them in any given call, but there are a large number of potential keywords that you could use. -- Greg ___ Python-Dev mailing list [email protected] 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 3101 Update
Talin wrote:
> Braces can be escaped using a backslash:
>
> "My name is {0} :-\{\}".format('Fred')
>
> Which would produce:
>
> "My name is Fred :-{}"
Do backslashes also need to be backslashed then? If not, then what is
the translation of this:?
r'abc\{%s\}' % 'x'
I guess the only sensible translation if backslashes aren't backslashed
would be:
r'abc\\{{0}\\}'.format('x')
But the parsing of that format string seems fairly unintuitive to me.
If backslashes do need to be backslashed, then that fact needs to be
mentioned.
-Edward
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] total ordering.
On 5/6/06, Vladimir Yu. Stepanov <[EMAIL PROTECTED]> wrote: [proposing a total ordering between types] It Ain't Gonna Happen. (From now on, I'll write this as IAGH.) In Python 3000, we'll actually *remove* ordering between arbitrary types as a feature; only types that explicitly care to be ordered with respect to one another will be ordered. Equality tests are unaffected, x==y will simply return False if x and y are of incomparable types; but xhttp://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] possible use of __decorates__ in functools.decorator
In a previous post related to the functools.decorator function, I think Nick was wondering if the __decorator__ and __decorates__ attributes were useful and Guido was tempted to call YAGNI on them. Coincidentally, I've run into a situation where I had to use the __decorates__ attribute, which I'd like to show to you because it might be a good example of why __decorates__ is useful or perhaps there's another way to do what I'm doing without it that some of you could hint at. We have a tracing decorator that automatically logs enter/exits to/from functions and methods but it also figures out by itself the arguments values of the function call and the class or module the function/method is defined on. I thought this was trivial until I ran into methods extended in subclasses, at which point we had to deal with bases and the mro. The part that figures out the name of the class where the wrapped method was defined has to start with the assumption that the first argument is self and then find the defining class from it. This code fragment is in the wrapper function of the decorator and it looks like this: if numargs > 0: # at definition time, class methods are not methods # yet because the class doesn't exist when the # decorators get called and thus, we have to figure # out classname at runtime via self, which is then # an instance of a class. # # assume first arg is self, see if f.__name__ is there # as a method and if so, then grab it's class name # self = args[0] if type(self) == types.InstanceType: # getattr will find the method anywhere in the # class tree so start from the top bases = list(inspect.getmro(self.__class__)) bases.reverse() for c in bases: # f was given to us in the deco_func meth = getattr(c, f.__name__, None) # we found a method with that name, which # it's probably this same wrapper function # we wrapped the original method with. ofunc = getattr(meth, '__decorates__', False) if ofunc and ofunc.func_code == f.func_code: # got it clsname = meth.im_class.__name__ break del c, meth del self This tracing code will correctly show calls to foomethod with the appropriate class name. def testMethodInBothClasses(self): class Base: @tracelevel(1) def foomethod(self, x, y=5, **kwds): return x+y class TClass(Base): @tracelevel(1) def foomethod(self, x, y=1, **kwds): return Base.foomethod(self, x, **kwds) + x + y t = TClass() rc = t.foomethod(4, d=1) self.failUnless(rc == 14) return Is there a way to do this without the __decorates__ attribute? -- Luis P Caamano Atlanta, GA USA ___ Python-Dev mailing list [email protected] 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 3102: Keyword-only arguments
On 5/7/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > I do know enough about Python to know that the make_person function is > a really bad example. Totally agreed. I've been ignoring most of that discussion because it seemed really irrelevant. > would be nice to instead see some real examples of the usefulness of > the required keyword-only arguments. The most obvious one to me is the optparse module, where add_option takes all kinds of different keyword arguments, and there's really no intention of these ever being specified as positional arguments: http://docs.python.org/lib/module-optparse.html STeVe -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] 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 3101 Update
"Edward Loper" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Talin wrote:
>> Braces can be escaped using a backslash:
>>
>> "My name is {0} :-\{\}".format('Fred')
>>
>> Which would produce:
>>
>> "My name is Fred :-{}"
>
> Do backslashes also need to be backslashed then? If not, then what is
> the translation of this:?
>
> r'abc\{%s\}' % 'x'
>
> I guess the only sensible translation if backslashes aren't backslashed
> would be:
>
> .format('x')
>
> But the parsing of that format string seems fairly unintuitive to me.
> If backslashes do need to be backslashed, then that fact needs to be
> mentioned.
AFAICT there would be no way to use raw strings with that method. That
method
would be using the escape sequence "\{" to indicate a bracket. Raw strings
cannot have escape sequences.
Additional backslashes are added to raw strings to remove anything that
resembles an escape sequence.
So either an additional layer of escaping is required (like with regex'es)
or ".format()" would
simply not be usable with raw strings.
The problem of having an additional level of escaping is very shown with
regexes. A simgle slash
as the end value is either "" or r"\\".
___
Python-Dev mailing list
[email protected]
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 3102: Keyword-only arguments
On 5/7/06, Steven Bethard <[EMAIL PROTECTED]> wrote: > The most obvious one to me is the optparse module, where add_option > takes all kinds of different keyword arguments, and there's really no > intention of these ever being specified as positional arguments: > http://docs.python.org/lib/module-optparse.html Or MySQLdb, which specifically recommends keyword arguments for the constructor. Mainly because the underlying library is controlled by a third party, so it's unpredictable when and where new arguments will be added. (Not that I'm in favor of keyword-only arguments, for the reasons Terry Reedy has mentioned.) -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Hello all again! Thanks to Mike's suggestion, I now opened a new wiki page, AlternativePathDiscussion, in http://wiki.python.org/moin/AlternativePathDiscussion The idea is to organize the discussion by dividing it into multiple sections, and seeing what is agreed and what should be further discussed. I now wrote there what I think, and quoted a few opinions from other posts. The posts by others are only a minority - what's written there currently is mostly what I think. I'm sorry for the inconvinience, but please go there and post your opinions (you can copy and paste from your emails, of course). I apologize first for not replying to each post, and second for only writing my opinions in the wiki. I simply write pretty slowly in English, and am already developing a growing sleep-hours deficit. I hope you forgive me. Have a good day, Noam ___ Python-Dev mailing list [email protected] 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 3101 Update
Joe Smith wrote:
> AFAICT there would be no way to use raw strings with that method.
> ...
> Additional backslashes are added to raw strings to remove anything that
> resembles an escape sequence.
You seem to be very confused about the way strings work. If
you look at the repr() of a string containing a backslash,
you will see two backslashes, but they're only in the repr(),
*not* in the string itself.
Some things to ponder:
>>> "\{" == r"\{"
True
>>> len("\{")
2
>>> len(r"\{")
2
--
Greg
___
Python-Dev mailing list
[email protected]
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 3101 Update
On 5/7/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > Braces can be escaped using a backslash:
> >
> > "My name is {0} :-\{\}".format('Fred')
> >
> > Which would produce:
> >
> > "My name is Fred :-{}"
>
> Do backslashes also need to be backslashed then? If not, then what is
> the translation of this:?
>
> r'abc\{%s\}' % 'x'
I believe the proposal is taking advantage of the fact that '\{' is
not interpreted as an escape sequence -- it is interpreted as a
literal backslash followed by an open brace:
>>> '\{'
'\\{'
>>> '\\{'
'\\{'
>>> r'\{'
'\\{'
Thus, for 'abc\{0\}'.format('x'), you should get an error because
there are no replacement fields in the format string.
STeVe
--
Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
[email protected]
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 3101 Update
On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
> I've updated PEP 3101 based on the feedback collected so far.
[snip]
> Compound names are a sequence of simple names seperated by
> periods:
>
> "My name is {0.name} :-\{\}".format(dict(name='Fred'))
>
> Compound names can be used to access specific dictionary entries,
> array elements, or object attributes. In the above example, the
> '{0.name}' field refers to the dictionary entry 'name' within
> positional argument 0.
I'm still not a big fan of mixing together getitem-style access and
getattribute-style access. That makes classes that support both
ambiguous in this context. You either need to specify the order in
which these are checked (e.g. attribute then item or item then
attribute), or, preferably, you need to extend the syntax to allow
getitem-style access too.
Just to be clear, I'm not suggesting that you support anything more
then items and attributes. So this is *not* a request to allow
arbitrary expressions. In fact, the only use-case I see in the PEP
needs only item access, not attribute access, so maybe you could drop
attribute access?
Can't you just extend the syntax for *only* item access? E.g. something like:
"My name is {0[name]} :-\{\}".format(dict(name='Fred'))
STeVe
--
Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
[Martin v. Löwis] > ... > Or, to put it yet in a different way: whether or not commit privileges > are restricted, you need to add the sprinters to the committers list > first, unless you want to allow anonymous commits to these branches. > > Just to not be mistaken: it is technically fairly easy to add somebody > to the committers list. So technical, there is no problem to add all > sprinters. The more realistically ;-) I try to picture the suggested alternatives, the more sensible this one sounds. Some people at the sprint (like me, wrt the Iceland sprint) could volunteer to be responsible for checking checkins for appropriateness, and in any case everyone subscribed to python-checkins would see what's going on. That's a major goodness all by itself, for "more eyeballs" reasons. It should be possible to quickly stop anyone abusing the privilege. However ... speaking as a PSF Director, I wouldn't be comfortable with this unless sprinters signed a PSF contribution form beforehand. Else we get code in the PSF repository with clear-as-mud copyright and licensing issues. Having contribution forms in place would also ease fears that sprint output might be "subverted" to non-open status. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Tim Peters wrote: > The more realistically ;-) I try to picture the suggested > alternatives, the more sensible this one sounds. Some people at the > sprint (like me, wrt the Iceland sprint) could volunteer to be > responsible for checking checkins for appropriateness, and in any case > everyone subscribed to python-checkins would see what's going on. That's > a major goodness all by itself, for "more eyeballs" reasons. It should > be possible to quickly stop anyone abusing the privilege. I completely agree. Just make sure you master the mechanics of adding committers. > However ... speaking as a PSF Director, I wouldn't be comfortable with > this unless sprinters signed a PSF contribution form beforehand. Else > we get code in the PSF repository with clear-as-mud copyright and > licensing issues. Having contribution forms in place would also ease > fears that sprint output might be "subverted" to non-open status. That would be desirable, indeed. It shouldn't be too difficult to collect the forms "on site". Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
