| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Comments:
<0> Yhg1s: that all beeing the case, why does python 3.0 have to be 3.0, couldn't we have it already with 2.6?
<1> __doc__: because it will break backward compatibility in pretty big ways (for Python.)
<2> because of the new unified version naming
<3> because 3 is a bigger number than 2
<4> Yhg1s: Why weren't they intended that way? It's OK for me to make them, but not call them??
<3> >.>
<2> first number difference means its incompatabile. all 2.x versions are compatible, all 3.x versions are compatible. 2.x is not compatible with 3.x
<1> Pythy: that's the choice Guido made. they are called through the implementation, by syntax or builtin functions, not as methodcalls. If they are expected to be run as normal methodcalls, they lack the double underscore, like 'iter.next'
<0> dougn: python 2.x used the right way is backwards compatible to 1.x
<2> I think removing things like map and reduce will be the biggest hickup
<1> dougn: except 2.x is compatible with 1.5 and 1.4 and even 1.1 to an extreme amount.
<2> really... so cl*** foo(object): p*** is backwards compatible?
<4> Yhg1s: Does this strike you as another bad design decision?
<1> dougn: that's forward compatibility.
<5> __doc__, well 2.X used the wrong way is compatible with 2.X :)
<1> Pythy: which part? Chosing to do it that way, or allowing them to be called directly?
<4> either
<2> *sigh* true, there is a m***ive forward compatability set for ALL of 2.x which means that all of 2.x is a migration path to 3.x
<2> granted I LIKE using decorators, meta cl***es, descriptors, etc...
<1> dougn: much of it, yes, because it's already perfect :)
<1> dougn: don't confuse 'new features' with '3.0 forward compatibility', though :)
<2> ok, so is 2.x about its new features? or is it about being compatible with 1.x?
<1> Pythy: no, not really. about the only thing I'd have done different is place more emphasis on the meaning of double-double underscores.
<2> 3.0 will also be largely backwards compatible to 1.x by your definition
<2> just dont use any of the stuff which wont work in 1.x or 3.x
<2> which is the bulk of the language
<1> dougn: it's about new features while remaining as backward compatible as it can. As it is, it's always -- barring bugfixes -- 100% backward compatible with the last minor release.
<1> and barring new keywords and subtle changes in edgecases (not stuff that would affect a group of programs of any size), backward compatible to 0.9.
<4> Yhg1s: What else would you have done differently (top three on your hit-list)?
<2> Im just nitpicking the isses of 2.x being backwards compatible to 1.x.. .by that standard mentioned, 3.0 will also be backwards compatible to 1.x
<1> dougn: no. Constructs that are valid in 1.x (other than certain valid identifiers becoming keywords and hence invalid identifiers) are valid in 2.x, but they might not be in 3.x.
<1> dougn: and, more importantly, they may behave differently (something 2.x tries to avoid at great cost.)
<2> true
<1> such as strings being unicode strings, instead of bytestrings.
<1> file-io not relying on platform C stdio behaviour.
<1> complex numbers going away as builtin type
<1> I forget what else :)
<4> What have you got against complex-numbers?
<1> Pythy: not much. At least not much that Guido doesn't agree on; he just didn't have the benefit of hindsight when he stated :)
<1> Pythy: nothing. I don't care if they're in or out. they'll be moved to a module in 3.0 though. They're way too little used to warrant a builtin type (or rather, a type with syntactic support)
<1> s/stated/started/
<2> there are also platform support issues.. that code is some of the hardest to port to a new platform
<4> well, limited syntactic support: 2**1+2j
<1> yeah, complex numbers and unicode are both optional parts of the build, for that reason (although the opting-out part is sometimes broken)
<2> that and some of the signal stuff (which might also be spun off after the exceptions are turned into new style cl***es)
<1> Pythy: '2j' is what makes the complex number, not '1+2j' :)
<1> dougn: which is done, in the trunk.
<1> dougn: (the exceptions, that is)
<0> ah is there a python trac btw?
<6> Hi guys, I'm trying to p*** a 'None' to a method that's expecting a string or a unicode string. Is there a quick way to translate a 'None' to a empty string?
<2> wow, didnt know that made it in already.. the branch was made only 8 weeks ago
<7> def str_coerce(object):
<7> if object is not None:
<7> return str(object)
<7> else:
<7> return ''
<1> __doc__: trac as in bug/patchmananger? or wiki? or something else?
<0> Gambit-: if not arg: arg = ''
<1> dougn: Brett finished it at the sprints.
<4> Gambit-: [s,''][s is None]
<0> Yhg1s: trac the software for python development, since now it lives on svn it would make sense, wouldn't it?
<6> noahslater, __doc__, Pythy, mm.
<2> I soo whish I could have stayed for the sprints
<1> __doc__: somewhat, and nope.
<6> Pythy, cute.
<1> __doc__: roundup seems to be slightly more favoured, and python.org has been running a roundup instance for years; there's a problem with getting all data from SourceForge, though.
<2> that trick is evil.. I always cringe when I see that
<1> dougn: there's also stuff in that hasn't even lived in a branch, ever ;)
<7> dougn: which one? Pythy's?
<2> yea ^_^ I used to use it everywhere, then people started asking me questions almost daily on what that code was doing
<2> went back and removed all uses
<4> "Gambit-|cute." > Gambit-: Tell that to those who are getting ready to flame me. ;-)
<0> Yhg1s: sorry first time I hear from roundup the "screenshots" look clunky, and when I look around these days, everybody & his aunt have a trac, and the plugin base is growing quite fast...
<6> Pythy, I said it was cute, I didn't say it was good ;)
<6> Though how about just doing SetValue(foo or '')?
<4> Gambit-: So, which will you use?
<6> strikes me that will do the same thing but be a helluva lot less ambiguous or difficult to parse.
<1> __doc__: well, roundup started as a Ping baby (meaning it was a slick idea, but unfinished, and I suspect those were the screens you've seen), but Richard Jones picked it up and made it into something real. it's been around longer than trac, and we would've switched to it ages ago if people weren't overworked or SF had been co-operating.
<4> lots of types evaluate to false.
<1> __doc__: there's a PSF committee to look at various issuetrackers, which is currently trying to get reliable data from SF so we can import it into various issuetrackers to try 'em out.
<7> Which is why my str_coerce works better IMHO
<6> Pythy, If it's not a string, I'd rather it went to ''.
<1> Gambit-: why are you p***ing it things that aren't strings at all?
<6> It's coming right out of the DB, so there's not a whole lot of space involve.
<4> "but be a helluva lot less ambiguous or difficult to parse." > not to me. I don't know what types it is intending to cover.
<6> Yhg1s, just 'None', which is what the db kicks back for Null it looks like.
<1> Gambit-: I'd probably suggest changing your query.
<7> And you want to *coerce* that to be ''? Hmm... :)
<4> "just 'None'," > Exactly. And my code says just that.
<6> Yhg1s, and why's that?
<1> Gambit-: so you won't be guessing at what the database intended.
<6> Yhg1s, how is Null guessing?
<0> Yhg1s: there already is a script for Trac that does an import of sf.net data into tracs http://projects.edgewall.com/trac/browser/trunk/contrib/sourceforge2trac.py
<7> For display purposes Null may as well be "" to the user
<1> Gambit-: if you want all non-string objects to become '', and the database starts returning non-strings to represent other things (like date/times, or string-like things with specific semantics, etc), your code will silently turn them into empty strings.
<8> What is a way to test and see if a module has been imported already?
<0> Yhg1s: it's been around for ages (9months)
<6> Yhg1s, who said anything about all non-string objects?
<1> vbgunz: check sys.modules
<4> vbgunz: Why do you need to worry about it?
<6> you're jumping way ahead of me here, I'm just talking about one particular value getting tossed into a text control :)
<1> Gambit-: you did:
<1> 18:26 <6> Pythy, If it's not a string, I'd rather it went to ''.
<6> That sentence was taken out of context, at the least out of the context of my brain :) I ***ure you I am not applying this globaly :)
<7> Heh
<8> Pythy: since I cannot find a good up to date design pattern guide or book that targets Python, I plan on using __init__ files for something special... But I can not reload them if they never get imported...
<1> SQL is a data selection tool. you choose which data to get. You don't want NULL, apparently (you want an empty string, which is not the same thing,) so my suggestion would be to change the query not to return NULL.
<9> what should i use for storing 3d models as files?
<6> Yhg1s, Duly noted :)
<7> SELECT IF(col IS NULL, '', col)
<0> vbgunz: __init__.py files get reloaded if you reload the directory they're in
<1> vbgunz: don't load or reload __init__ directly.
<0> r00723r0: probably a well known 3d format like 3ds
<8> __doc__: let me check!
<9> __doc__, it wont be parsable easily though
<1> vbgunz: 'dir/__init__.py' holds the code for module 'dir' (which is also a package)
<8> Yhg1s: ok, if __doc__ suggestion work I'll roll with that
<9> and i dont believe .3ds files allow lighting
<0> r00723r0: then pick your favorite plaintext variant like dfx or vrml or invent your own
<9> i need textures, vertices and lighting
<8> __doc__: thanks bro, that is right!
<0> r00723r0: probably if I'd do that I'd do some xml structure that's a little nicer to read then vrml and do it in proper xml read and written by elementtree
<9> an xml thing?
<9> arent they slow as hell?
<0> r00723r0: cElementTree is pretty fast actually
<0> r00723r0: of course it's slower then binary or fixed field formats
<9> i doubt that xml is an answer
<0> r00723r0: but then you're going to need nested tree like data
<9> i think line-by-line would be best
<0> r00723r0: if you're only going to dump vertices xml is not the answer
<9> vertices, lighting, textures
<9> textures will be in different files
<9> probably
<10> ok, so this is weird, but -- a couple hours ago we were talking about list.__str__ calling repr() on its elements to print them... but my power went out in the middle of that discussion :) did anything interesting come of it?
<11> what would there be to talk about?
<10> well, i was baffled/confused why str(someList) prints out the repr of its contents, and opposed to the str of them
<10> even when an appropriate __str__ method is defined for the elements
<4> dumping an entire structure isn't likely to be done for a user,
<11> mcmillen: it would be annoying if, say, you had ["abc, def"] the string representation would be indistinguishable from ["abc", "def"]
<4> it's a move you'd make when debugging, so, repr() is appropriate.
<10> Pythy: but if i'm debugging something, i'd call repr() if i wanted to, not str()
<10> the doc for str() just says "a nice string representation of the object", and to me it doesn't make sense to make the "niceness" non-recursive
<4> McMillen: if you're not debugging, you'd do a `print mylist'?
<10> pythy: possibly, yes. it's more likely that i want to show a user str(list) than repr(list).
<10> especially for, say, a command-line app.
<10> and what i end up doing instead is defining a __repr__ method for the object that is concise, which is non-optimal
<0> mcmillen: it's even much more likely you're showing a user '%s'%somelist then str(somelist)
<4> There's no difference.
<0> Pythy: on the outline, no, in the praxis, yes. because you'll probably do '%20s' % somelist for instance
<4> so?
Return to
#python
or
Go to some related
logs:
garcon ubuntu 999
mvangel8
#web
KOBJECT_UEVENT menuconfig
sha1sum salt
#perl
#debian
#asm
#perl
pvremove fedora
|
|