Re: [Python-Dev] PyPI comments and ratings, *really*?

> >> That is an (apparently widespread) myth. The Cheesecake rating is not >> considered in ranking search results; it's just the relevance of the >> search term that is. > > Thanks for clarifying this! > > What about the other points? They are really off-topic for python-dev; PyPI discussion s

Re: [Python-Dev] PyPI comments and ratings, *really*?

>> > I don't want to create a PyPI account (more account details I'll >> > rarely use to remember) just to vote. I can see why anonymous votes >> > are bad, but the sample's going to be self-selecting - people like me >> > who don't want to create an account will be excluded. >> >> This is indeed i

Re: [Python-Dev] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)

> Why? I already have python tracker account and a python wiki account > which is already 2 too many. The latter was a pain because the site lost > my registration and as of a year ago, the registration process was > broken. I would much prefer just one python site registration. Then I recommend t

Re: [Python-Dev] Too many Python accounts

> And that registration should be using any OpenID, so that I don't need > any new identities to participate on the Python sites: I can re-use > existing identities. PyPI actually does support OpenID. Regards, Martin ___ Python-Dev mailing list Python-D

Re: [Python-Dev] buildtime vs runtime in Distutils

> http://bugs.python.org/issue4359 reminds me that Distutils reads build > files like Makefile or pyconfig.h to get some environment > variables through the sysconfig module at *runtime*. > > This cannot work on all platforms, when our Makefile is not shipped > with python but python-devel. (like

Re: [Python-Dev] buildtime vs runtime in Distutils

> The problem is that the main python distribution ("python") is not > working as advertised since > it contains distutils, which requires "python-devel" to work. > > This implies that "python" has a dependency on "python-devel", which > does not make sense > anymore for linux distros to have two

Re: [Python-Dev] Too many Python accounts

> Fred can use his own OpenID ‘fred.example.org’, initially set up behind > the scenes to delegate to ‘bigcorp.example.com’ as the provider. Any > time he likes, Fred can *change* which provider is actually used for > authentication, without changing his OpenID. PyPI gets to find out which > provid

Re: [Python-Dev] Too many Python accounts

>> So the only thing users gain with delegation is that they don't need >> to remember the tedious URL that their provider assigns them. When they >> switch providers, their claimed ID will still change, and they'll have >> to reregister in all services they use. >> >> > No, the whole point of d

Re: [Python-Dev] Too many Python accounts

> Well, when I login my registered ID is www.voidspace.org.uk and *not* > fuzzyman.myopenid.com - so I believe you are incorrect (and in fact this > very point was touted as one of the advantages of openid - that your > account is independent of your provider and that you *can* change > provider wh

Re: [Python-Dev] Too many Python accounts

>> Can't you then produce hundreds of IDs, all delegating to the same >> identity? > > Yes. But then, users can easily create as many fake accounts as they want to. This is not something I want to happen (it's still possible to setup fake accounts, but it should be more difficult for the average

Re: [Python-Dev] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)

> I've never found OpenID at all intuitive to use. Are there instructions on > pypi.python.org which detail the steps necessary to use OpenID to login? I > saw the "Claim OpenID" link on my PyPI profile page. So now I have an > OpenID URL. What am I supposed to do with that? If I visit that UR

Re: [Python-Dev] Too many Python accounts

> This doesn't seem to be a problem for all the other sites I use my > openid with. Perhaps they don't care about fake accounts at all? That would, in particular, be the case if they accept arbitrary OpenID providers (which means that essentially no real authentication happens). > Why not allow u

Re: [Python-Dev] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)

s...@pobox.com wrote: > Martin> That's indeed what PyPI attempts to do. At the "claim openid" > Martin> place, follow the Launchpad link. It should guide you through > Martin> the procedure. > > Well, since I use Google a lot more I'd prefer to use that. If I click the > Google OpenID

Re: [Python-Dev] Too many Python accounts

> Even not having provider changes supported would still allow me to use > my openid with PyPI which would be great. The only problem with changing > provider that I can see is when the provider a user changes to would > then be a duplicate - in which case I think just refusing to allow the > login

Re: [Python-Dev] Too many Python accounts

> Would it be possible to detect a change of provider and then offer the > option to migrate the account to the new provider (so long as it does > not conflict with another account)? That would be possible - but again complicate the UI. Regards, Martin

Re: [Python-Dev] Too many Python accounts

Michael Foord wrote: > Martin v. Löwis wrote: >>> Would it be possible to detect a change of provider and then offer the >>> option to migrate the account to the new provider (so long as it does >>> not conflict with another account)? >>> >> >

Re: [Python-Dev] Removal of intobject.h in 3.1

> IMHO, that's not really a good way to encourage people to try to provide > a smooth upgrade to the 3.x branch. Much to the contrary. 3.x should make > it easier for developers by providing more standard helpers like > the removed intobject.h header file. I think it's better than it sounds. The m

Re: [Python-Dev] Removal of intobject.h in 3.1

> In an ideal world, developers would add that code to their > extensions right away. In the real world, where developers only > have limited resources available, you'll get more 3.x ports > by making such ports as painless as possible while at the > same time not forcing them to alienate their 2.x

Re: [Python-Dev] Removal of intobject.h in 3.1

> I'm not sure concealing the differences between 2.x and 3.x behind such a > wrapper is a good idea. It would be better if people became aware of / learnt > about the new semantics. +1. When porting a larger code base, I always came up with a custom set of macros, specific to the way the modules

Re: [Python-Dev] Buildslave gets intermittent errors in the svn step

> Does anyone have any suggestions? I guess that's a buildbot bug. At 2009-11-23 22:14:23, your buildslave disconnected. The master recognized it it as offline. For some reason, it then still decided to start a build, at 22:14:24. With the slave disconnected, all master-side information gets disca

Re: [Python-Dev] Building a Windows MSI for Python /trunk

> First, the script that finds & builds the external dependencies has two > minor problems. > > * it puts Tcl in tcl-8.*, and Tk in tk-8.*, but msi.py looks for them in >tcl8.* and tk8.* to grab the license text. I changed the glob strings >appropriately and that seemed to work. Not sur

Re: [Python-Dev] Building a Windows MSI for Python /trunk

>> You'll need to build release versions of Tcl/Tk/Tix. > > Yes, I saw a reference to that online, but I wasn't sure if that was the > problem -- is the naming convention really that 'tcl85g.lib' is the debug > lib!? Yes; Tcl apparently follows Unix conventions here rather than Windows convention

Re: [Python-Dev] /trunk test_distutils failing on Mac OS X 10.5

> I went to double-check this on the buildbots and noticed that there > aren't any Mac OS X buildbots. That's not true, see http://www.python.org/dev/buildbot/builders/x86 osx.5 trunk Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org h

Re: [Python-Dev] Drop support for ones' complement machines?

Mark Dickinson wrote: > Question: should the CPython source compile cleanly and work > correctly on (mostly ancient or hypothetical) machines that use > ones' complement or sign-and-magnitude to represent signed integers? I think that's the wrong question to ask. What you really meant to ask (IIU

Re: [Python-Dev] Drop support for ones' complement machines?

> No, the original question really was the question that I meant to ask. :) Ok. Then the reference to issue 7406 is really confusing, as this is about undefined behavior - why does the answer to your question affect the resolution of this issue? > I absolutely agree that CPython shouldn't invoke

Re: [Python-Dev] Drop support for ones' complement machines?

>> I'd rather prefer to explicitly list what CPython assumes about the >> outcome of specific operations. If this is just about &, |, ^, and ~, >> then its fine with me. > > I'm not even interested in going this far: I still am: with your list of assumptions, it is unclear (to me, at least) what

Re: [Python-Dev] Drop support for ones' complement machines?

I'd rather prefer to explicitly list what CPython assumes about the outcome of specific operations. If this is just about &, |, ^, and ~, then its fine with me. >>> I'm not even interested in going this far: >> I still am: with your list of assumptions, it is unclear (to me, at >> le

Re: [Python-Dev] possible bug in python importing pyc files

> The code that shows this problem is owned by my company, I'm not sure > if I would be able to produce it to create a bug report. But I do have some > time > to help debug the problem. > > What steps should I take to try to isolate the problem? Try isolating the precise instruction that behaves

Re: [Python-Dev] Unicode locale values in 2.7

> But in trunk, the value is just used as-is. So when formating a decimal, > for example, '\xc2\xa0' is just inserted into the result, such as: format(Decimal('1000'), 'n') > '1\xc2\xa' > This doesn't make much sense I agree with Antoine: it makes sense, and is the correct answer, given t

Re: [Python-Dev] Troubled by changes to PyPI usage agreement

Ben Finney wrote: > On 03-Dec-2009, Benjamin Peterson wrote: >> Hi Ben, >> Could I ask why you cced this to python-dev, too? I thought the last >> string of pypi related emails, we agreed the correct place for this >> was the catalog-sig. > > I did consider that. But it seems this change is being

Re: [Python-Dev] recursive closures - reference cycle

> Yes, and a number of different workarounds. That's not really the > issue. The issue is that what looks like a perfectly safe idiom > (calling a function recursively) happens to create a reference cycle > if that function is a closure. This is a non-obvious "gotcha" that I > must now educate my

Re: [Python-Dev] [issue1644818] Allow importing built-in submodules

Julien Danjou wrote: > At 1261178549 time_t, Martin v. Löwis wrote: >>> Is there to chance to see this *bug* fixed someday? >> Please ask on python-dev. I may be willing to revive my five-for-one offer. > > Not sure I really understand, but I can ask gain here: > w

Re: [Python-Dev] [issue1644818] Allow importing built-in submodules

> But in my current position and with "I-do-software-developement-too", > you are just pissing me off for not fixing a bug in your program with a 10 > lines long patch written by someone else 3 years ago. Unfortunately, it is not obvious to me that the patch is correct, so I couldn't check it in a

Re: [Python-Dev] Providing support files to assist 3.x extension authors

> Several questions come to mind: > > 1) Is it reasonable to provide backward compatibility files (either as > .h or .c) to provide support to new API calls to extension authors? I'm skeptical. In my experience, each extension has different needs, and will also use different strategies to provide

Re: [Python-Dev] x86 osx 5 buildbot slave

Thomas Heller wrote: > I have to shutdown the x86 osx 5 buildbot slave permanently, because > the machine is getting a new role. Martin, please remove it from > the configuration. Thanks for the notice; I have now removed it from the list. Regards, Martin

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> The deprecation of the existing Requires/Provides/Obsoletes fields > should be more prominent - tucked away below the examples, I missed > these notices on the first read through (I only noticed that they > actually had been formally deprecated when I got to the summary of > differences at the en

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> I think we want something stronger than that since they were not really used > by > the community and removed and replaced by something better. Using them > should raise a warning so developers abandon them, so it would be > "don't use 1.1 anymore" I think you are mixing the distutils implement

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> So that will happen in the code of course, but we need the PEP to state > clearly > wether metadata 1.0 and 1.1 should be dropped by implementations or not. Ok. We should recommend that implementations support these versions indefinitely. I see no point in dropping them. But then, this is real

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> As an application developer, I really stand with Tarek here. Not sure what specific point of Tarek you are supporting, though. I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them >>

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

David Lyon wrote: > On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" > wrote: > >> Martin's point is that the PEP process doesn't *have* "reference" >> implementations. It has *sample* implementations. It may be useful >> to refer to a sample implementation as an example.. > > Fair en

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> I'll remove it and push it in Distutils documentation, then might just > provide a link in the PEP References. That sounds fine to me. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> No application developer will quickly figure out what a tilde means. Maybe > it means 'roughly', but it requires too much thought and is ambiguous. 2.5 > is not roughly 2.5.2. It is the same exactly. > > Before we had : Requires-Python: 2.5, 2.6 > > That made much more sense. It was simple and

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

Tarek Ziadé wrote: > On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou wrote: >> Tarek Ziadé gmail.com> writes: >>> This was ambiguous because it was unclear, as MvL stated, if "2.5" >>> was just "2.5.0" or included >>> versions like "2.5.1" or "2.5.2". >> How about having "2.5" match all 2.5.x ve

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

david.l...@preisshare.net wrote: >>> No application developer will quickly figure out what a tilde means. >>> Maybe >>> it means 'roughly', but it requires too much thought and is ambiguous. >>> 2.5 >>> is not roughly 2.5.2. It is the same exactly. >>> >>> Before we had : Requires-Python: 2.5, 2.6

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> Does that mean we should add "or"? > > Requires-Python: 2.5 or 2.6 It would be redundant to have it, since you can also write Requires-Python: >=2.5, <2.7 > Should we also use "and" instead of ","? > > Requires-Python: >= 2.5 and < 2.6 Perhaps. I think the Linux packaging formats u

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> It seems to me that all this version range talk relates pretty > directly to PEP 386. > > The Python version numbers themselves are the simplest type of > "Normalized Version"s, and since comparisons of "NormalizedVersion"s > are defined in PEP 386, and that's really all we're talking about > he

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> And IMO the choice of "~=" or "=~" for the range match should be > avoided, since that looks like the regexp search operator in Perl, and > there "~= 3" would match "3", "3.0.4", and "2.3.5". The next obvious > interpretation is "fuzzy match", but that doesn't have an obvious, > more specific me

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> Point of order: what is the point of sending the discussion off to the > distutils SIG if we are just going to bikeshed it (again!) here. Bike-shedding it here is indeed inappropriate. If the PEP had listed all possible arguments that can come up in this discussion, and the corresponding counte

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> I think Antoine's proposal is good (using the range when "2.5" is > used, and using 2.5.0 when explicitely > needed), and fixes Martin's concerns. > > So I would be in favor of removing ~= and using Antoine's rule; So specifying 2.5 would be a short-hand for *what*? Regards, Martin ___

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

>> So specifying 2.5 would be a short-hand for *what*? > > 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0 Ok, so it's not a shorthand for a single operator anymore, but for a more complex term. Fine with me. > 2.5.0 would be the notation required to describe this specif

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

> Another penny dropped when it comes to version specs. > > Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need > to specify 2.5.0 only. That's a nonsense specification. > > "My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!? > Well, then fix it, goofball. :)

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

>> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' > > Requires-Dist: [Windows] pywin32 1.0+ > > That's simpler, shorter, and less ambiguous. Easier to > parse for package managers. Don't you want the PEP to complete? Why this bike-shedding? I can agree it's shorter. I can't agree that

Re: [Python-Dev] Suggestion: new 3 release with backwards compatibility

> It's not even that easy -- libraries can't apply patches for Python 3 > compatibility as they usually break Python 2 compatibility. Potentially > libraries could apply patches that make a codebase 2to3 ready, but from > what I've seen that's more black magic than straight forward updating, > as

Re: [Python-Dev] Suggestion: new 3 release with backwards compatibility

> No-op constructions like 'bytes("")' could help for older versions of > Python, though. A very, very small runtime shim could provide > support for these, if 2to3 could be told about it somehow. You actually don't *need* 2to3 support for that - bytes("") can work in either version: 2.x: def by

Re: [Python-Dev] Suggestion: new 3 release with backwards compatibility

> Just to clarify, the black magic I'm referring to is things like: > > try: > unicode_ = unicode > except NameError: > unicode_ = str > > and some other aliases like this that are unambiguous and which 2to3 > won't touch (if you write them correctly). If the porting guide noted > all th

Re: [Python-Dev] --enabled-shared broken on freebsd5?

> b) Does this fix seem like the sensible thing to do? No. Linking in setup.py should use the same options as if the module was built as *shared* through Modules/Setup, which, IIUC, should use BLDLIBRARY. Regards, Martin ___ Python-Dev mailing list Pyth

Re: [Python-Dev] GIL required for _all_ Python calls?

>> A better rule would be "you may access the memory buffer in a PyString >> or PyUnicode object with the GIL released as long as you own a >> reference to the string object." Everything else is out of bounds (or >> not worth the bother). > > Is that a "yes" regarding the OP's original question ab

Re: [Python-Dev] GIL required for _all_ Python calls?

> I've been wondering whether it's possible to release the GIL in the > regex engine during matching. I don't think that's possible. The regex engine can also operate on objects whose representation may move in memory when you don't hold the GIL (e.g. buffers that get mutated). Even if they stay i

Re: [Python-Dev] relation between Python.asdl and Tools/compiler/ast.txt

> I would like to use astgen.py to generate python classes corresponding to the > AST of something I have defined in a .asdl file, along the line of what is > apparently done for the python AST itself. I thought astgen.py would > take as an argument a .asdl file, but apparently it instead process

Re: [Python-Dev] GIL required for _all_ Python calls?

>>> I've been wondering whether it's possible to release the GIL in the >>> regex engine during matching. >> >> I don't think that's possible. The regex engine can also operate on >> objects whose representation may move in memory when you don't hold >> the GIL (e.g. buffers that get mutated). Even

Re: [Python-Dev] GIL required for _all_ Python calls?

> I've been wondering whether it's possible to release the GIL in the > regex engine during matching. Ok, here is another problem: SRE_OP_REPEAT uses PyObject_MALLOC, which requires the GIL (it then also may call PyErr_NoMemory, which also requires the GIL). Regards, Martin __

Re: [Python-Dev] GIL required for _all_ Python calls?

>> I don't think that's possible. The regex engine can also operate on >> objects whose representation may move in memory when you don't hold >> the GIL (e.g. buffers that get mutated). > > Why is it a problem? If we get a buffer through the new buffer API, the object > should ensure that the repr

Re: [Python-Dev] relation between Python.asdl and Tools/compiler/ast.txt

>> astgen.py is not used to process asdl files; ast.txt lives right >> next to astgen.py. Instead, the asdl file is processed by >> Parser/asdl_c.py. > > Yes, I know that. That's why I asked about the relation between > ast.txt and Python.adsl. If internally the parser uses the .adsl, but > expose

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

>> It *is* crazy, but unfortunately rather common. Wikipedia has a good >> description of the issues: >> . Basically, some >> Windows text APIs will emit a UTF-8 "BOM" in order to identify the file as >> being UTF-8, so it's become a convention

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

> But it should do something sane when reading such files. I can't > really see any harm in throwing it away, especially since use of > ZERO-WIDTH NO-BREAK SPACE as a joining character has been deprecated > IIRC. And indeed it does, when you open the file in the utf-8-sig encoding. Regards, Mart

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

> Builtin open() function is unable to open an UTF-16/32 file starting with a > BOM if the encoding is not specified (raise an unicode error). For an UTF-8 > file starting with a BOM, read()/readline() returns also the BOM whereas the > BOM should be "ignored". It depends. If you use the utf-8-

Re: [Python-Dev] --enabled-shared broken on freebsd5?

Nicholas Bastin wrote: > I think this problem probably needs to move over to distutils-sig, as > it doesn't seem to be specific to the way that Python itself uses > distutils. I'm fairly skeptical that anybody on distutils SIG is interested in details of the Python build process... Regards, Marti

Re: [Python-Dev] relation between Python.asdl and Tools/compiler/ast.txt

> I see. So if people want to analyze python code they have to use > other tools (like rope?) ? or use reflection ? Correct. One such tool might be the true Python compiler, along with the _ast module. Regards, Martin ___ Python-Dev mailing list Python-

Re: [Python-Dev] Quick sum up about open() + BOM

>>> Antoine would like to check BOM by default, because both options >>> (system locale vs checking for BOM) is the same thing. >>> >> To be clear, I am not saying it is the same thing. What I think is >> that it would be a mistake to use a mildly unreliable heuristic by >> default (the locale +

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

Antoine Pitrou wrote: > Walter Dörwald livinglogic.de> writes: >> On the surface this looks like there's an encoding named "BOM", but >> looking at your patch I found that the check is still done in >> TextIOWrapper. IMHO the best approach would to the implement a *real* >> codec named "BOM" (o

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

>> How does the requirement that it be implemented as a codec miss the >> point? > > If we want it to be the default, it must be able to fallback on the current > locale-based algorithm if no BOM is found. I don't think it would be easy for > a > codec to do that. Yes - however, Victor currently

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> I propose that the 2.x branch be treated like 2.x.y branches: as > long as there is sufficient volunteer labour, it should continue to > live. In order to avoid wasted development effort, it would be > prudent to announce that unless a 2.8 release manager steps up, > whatever is committed to the

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> The announcement is precisely to avoid the situation where people commit > new features to the 2.x main line of development (after the 2.7 > maintenance branch is created) in the expectation that they will be > released as part of a hypothetical 2.8 release. > > Whether that info needs to be in

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

Neil Schemenauer wrote: > On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote: >> [...] would it still be ok if I closed a 2.x feature request as >> "won't fix", or only committed the new feature to the 3.x branch? > > Yes. Non-bugfix d

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> I would guess over 99% of all Python code written doesn't run on > Python 3. Given that, I think it is premature to close the door on > new major versions of Python 2.x. Also, we as a project should be > careful not to present the image that Python 2.x will not be > supported in the future. Why

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> I guess I have more confidence in Python 3 than you do. I don't see > why Python 2.x needs to be artificially limited so that Python 3 can > benefit. Because it takes too much time. Too much of my time, but apparently also too much of other people's time. Of course, the less active fraction of

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> "Python 2.7 is scheduled to be the last major version in the 2.x > series released by the Python Software Foundation before it moves into > 5 years of bugfix-only mode. " > > That doesn't exclude *others* making a Python 2.8 that could include > all sorts of crazy features. :) > > This is mainl

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

> But an autodetect feature is not a codec. Sure it should be reusable, > but making it a codec seems to be a weird hack to me. Well, the existing UTF-16 codec also is an autodetect feature (to detect the endianness), and I don't consider it a weird hack. Regards, Martin

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

> I must say that I find this whole thing pretty obvious. 'BOM' is not > an encoding. That I certainly agree with. > That covers all usecases, is easy and obvious. Either open(file=foo, > encoding=None) or open(file, encoding=encoding_from_bom(file)) > > I can't see that open(file, encoding='BOM

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> So the question we should be asking is: what's missing from Python > 2.7 to help with this transition? Wrt. the distribute feature you've noticed: Python 3.0 already supports that in distutils. So from day one of Python 3.x, you could have used that approach for porting Python code. I had been p

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> So, it should say "Guido wants 2.7 to be the last main version of > Python 2, so it probably will be. We promise to release bugfixes it > for, like, ages". > > No need to be needlessly formal. :-D That summarizes my understanding of what Guido said fairly well :-) +1 for putting it into the an

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

Guido van Rossum wrote: > +1 from me. (With the caveat that "time will tell" is definitely the > ultimate answer. Plans may change unexpectedly, even though we don't > expect them to.) > > PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not > helpful. That's really because I have

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

>> a) telling people that they have to move to 2.6 first actually >> hurts migration, instead of helping, because it implies to them >> that they have to drop old versions (e.g. 2.3.) - just because >> they had *always* dropped old versions before supporting new ones. > > Is it just an impli

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> Maybe not, but the Distribute feature is there because IMO the > distutils feature by itself isn't particularily useful. You need to > write your own distutils extensions, in practice, and they are not > trivial. I wouldn't say that. My Django port works with bare distutils (as does Django itsel

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> [...] >> I've done a fair bit of 3.x porting, and I'm firmly convinced that >> 2.x can do nothing: > [...] >> Inherently, 2.8 can't improve on that. > > I agree that there are limitations like the ones you've listed, but I > disagree with your conclusion. Maybe you assume that it's just as hard

Re: [Python-Dev] topics I plan to discuss at the language summit

> I think it would be interesting to see how people are using the tracker, > or how they want to be using it. For example, there are currently over > 1500 open issues with no stage set, some of which seemingly haven't been > read by anyone at all. Would a properly set stage field save issues from >

Re: [Python-Dev] Fwd: Download Page - AMD64

> I presume the email below is about the Windows binary. Does the AMD64 > release work on intel 64bit and can we make the wording clearer on the > download page? "intel 64bit" is as clear as mud. It could mean the "Intel 64" architecture, or it could mean the "IA-64" architecture, both are 64-bit

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> I'm not talking about Twisted moving to 3.x (FWIW, I think the only > movement there so far is some patches for some -3 warnings). The > situation I'm describing is a project X that: > > (a) has 2.x-only dependencies, and > (b) would like to be as close as possible to 3.x (because they like

Re: [Python-Dev] Fwd: Download Page - AMD64

> How about: > > * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / > X86-64 binary -- does not include source) > > instead of: > > * Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does > not include source) -1. AMD doesn't want us to use the term x86-64 anymor

Re: [Python-Dev] Fwd: Download Page - AMD64

>>> * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / >>> X86-64 binary -- does not include source) >>> >>> instead of: >>> >>> * Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does >>> not include source) >>> >> -1. AMD doesn't want us to use the term x86

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

> Note that increased 3.x compatibility in the most recent 2.x release > will always help in two scenarios: > > 1. New projects that want to use 2.x only libraries but want to be ready > for the Py3k transition in their own code (e.g. new 2.7 features like > set literals, dict and set comprehensio

Re: [Python-Dev] Fwd: Download Page - AMD64

> As Windows doesn't run on non-x86 architectures, their naming is > generally just Windows (32 bit) and Windows (64 bit). Windows actually does - it runs on IA-64 (which is a non-x86 architecture). However, end users are unlikely to use such hardware, so distinguishing between 32-bit and 64-bi

Re: [Python-Dev] Fwd: Download Page - AMD64

> So to echo what Michael said, the Microsoft nomenclature is "x64" > regardless of yours and Martin's objections to that name. Nobody who > uses Windows would be confused by "x64" since that is *the* Microsoft > naming scheme. That's actually not entirely true. There are several places in the API

Re: [Python-Dev] PYTHON3PATH

Lennart Regebro wrote: > On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt wrote: >> The first thing I got while trying to run a python3 prompt few days ago, >> was an error. python3 tried to read my $PYTHONSTARTUP file, which used >> print statements. people will have to run both python 2 and python 3

[Python-Dev] [ANN] Python 2.5.5 Release Candidate 1.

On behalf of the Python development team and the Python community, I'm happy to announce the release candidate 1 of Python 2.5.5. This is a source-only release that only includes security fixes. The last full bug-fix release of Python 2.5 was Python 2.5.4. Users are encouraged to upgrade to the la

Re: [Python-Dev] 3.1.2 / 2.6.5 maintenance releases?

Ned Deily wrote: > I've recently seen a couple of references to 3.1.2 go by in checkins > which made me wonder whether dates have been proposed yet for updates to > either 3.1 or 2.6. I don't recall seeing any and I didn't see any > references in the PEPs. Some advance warning would be nice.

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

> Hope this is helpful; can anyone see any potential problems with this > change? As Marc-Andre says: such a change is unsupported, and *will* break Python. It's not true that the only supported encoding in 2.x is 'ascii', 'iso-8859-1' is also supported. 'utf-8' is not, neither is anything else.

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

> Why only set an encoding on these streams when they're directly > connected to a tty? If you are sending data to the terminal, you can be fairly certain that the locale's encoding should be used. It's a convenience feature for the interactive mode, so that Unicode strings print correctly. When

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

>> The only supported default encodings in Python are: >> >> Python 2.x: ASCII >> Python 3.x: UTF-8 >> > > Is this true? For 3.x: yes. However, the default encoding is much less relevant in 3.x, since Python will never implicitly use the default encoding, except when some C module asks fo

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

> We're looking forward to discussing this with everyone. I think the PEP is asking too much (although I can understand how marketing may have influenced that), and also asks for permission where none is needed. It is too broad: it asks (in its title) for the integration of Unladen Swallow, when

<    4   5   6   7   8   9   10   11   12   13   >