Re: [Python-Dev] PEP 408 -- Standard library __preview__ package

Eli Bendersky wrote: try: from __preview__ import thing except ImportError: import thing So no need to target a very specific version of Python. Yep, this is what I had in mind. And it appeared too trivial to place it in the PEP. Trivial and wrong. Since thing and __preview__.thing

Re: [Python-Dev] PEP for allowing 'raise NewException from None'

Terry Reedy wrote: On 1/27/2012 2:54 PM, Guido van Rossum wrote: On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman wrote: Guido van Rossum wrote: Did you consider to just change the words so users can ignore it more easily? Yes, that has also been discussed. Speaking for myself, it would be

Re: [Python-Dev] plugging the hash attack

Benjamin Peterson wrote: Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actual

Re: [Python-Dev] PEP 408 -- Standard library __preview__ package

Michael Foord wrote: On 27/01/2012 20:48, Steven D'Aprano wrote: Eli Bendersky wrote: try: from __preview__ import thing except ImportError: import thing So no need to target a very specific version of Python. Yep, this is what I had in mind. And it appeared too trivial to pla

Re: [Python-Dev] A new dictionary implementation

Mark Shannon wrote: Antoine Pitrou wrote: On Sun, 29 Jan 2012 09:56:11 -0500 Benjamin Peterson wrote: 2012/1/29 Mark Shannon : Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. If you're se

Re: [Python-Dev] PEP 408 -- Standard library __preview__ package

Chris Withers wrote: Every time I see things like the following I cry a little inside: try: try: from py2stdliblocation import FooBar as Foo except ImportError: from py3stdliblocation import foo as Foo except ImportError: from pypilocation import Foo The syntax is inelegant, bu

Re: [Python-Dev] PEP 408 -- Standard library __preview__ package

Terry Reedy wrote: On 2/3/2012 6:18 PM, Steven D'Aprano wrote: Now we're talking about having to add __preview__ into that mix too? As I understand it, Guido nixed that idea. (Or did I imagine that?) No, you are right, discussion should cease. It is already marked 'rejec

Re: [Python-Dev] PEP 408 -- Standard library __preview__ package

Paul Moore wrote: On 4 February 2012 11:25, Steven D'Aprano wrote: It strikes me that it would be helpful sometimes to programmatically recognise "preview" modules in the std lib. Could we have a recommendation in PEP 8 that such modules should have a global variable called P

Re: [Python-Dev] Add a new "locale" codec?

Simon Cross wrote: I think I'm -1 on a "locale" encoding because it refers to different actual encodings depending on where and when it's run, which seems surprising Why is it surprising? Surely that's the whole point of a locale encoding: to use the locale encoding, whatever that happens to b

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Paul Moore wrote: I would suggest that, assuming python-dev want to take ownership of the module, one last-ditch attempt be made to contact Fredrik. We should email him, I wouldn't call email to be "last-ditch". I call email "first-ditch". I would expect that a last-ditch attempt would includ

Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library

Jim J. Jewett wrote: Eli Bendersky wrote (in http://mail.python.org/pipermail/python-dev/2012-February/116393.html ): A package will be marked provisional by including the following paragraph as a note at the top of its documentation page: I really would like some marker available from withi

Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library

Eric Snow wrote: On Fri, Feb 10, 2012 at 8:10 PM, Eli Bendersky wrote: On Fri, Feb 10, 2012 at 22:13, Jim J. Jewett wrote: Eli Bendersky wrote (in http://mail.python.org/pipermail/python-dev/2012-February/116393.html ): A package will be marked provisional by including the following paragra

Re: [Python-Dev] best place for an atomic file API

Charles-François Natali wrote: Hi, Issue #8604 aims at adding an atomic file API to make it easier to create/update files atomically, using rename() on POSIX systems and MoveFileEx() on Windows (which are now available through os.replace()). It would also use fsync() on POSIX to make sure data i

Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

Georg Brandl wrote: Am 16.02.2012 11:14, schrieb "Martin v. Löwis": Am 16.02.2012 10:51, schrieb Victor Stinner: 2012/2/16 "Martin v. Löwis" : Maybe an alternative PEP could be written that supports the filesystem copying use case only, using some specialized ns APIs? I really think that all y

Re: [Python-Dev] PEP 410, 3rd revision, Decimal timestamp

Martin v. Löwis wrote: * Ruby (1.9.3), the `Time class `_ supports picosecond (10\ :sup:`-12`) We must do better than Ruby: support arbritrary precision! :-D Seriously, I do consider that a necessary requirement for the PEP (which the Decimal type a

Re: [Python-Dev] PEP czar for PEP 3144?

Nick Coghlan wrote: On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou wrote: On Mon, 20 Feb 2012 23:23:13 +1000 Nick Coghlan wrote: Does anyone object to me naming myself PEP czar for PEP 3144? “Tsar is a title used to designate certain European Slavic monarchs or supreme rulers.” Is this ou

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

Tshepang Lekhonkhobe wrote: On Sat, Feb 25, 2012 at 05:10, Ned Batchelder wrote: Has Python *ever* removed a feature except in X.0 releases? I thought this happens all the time, but with deprecations first. Is that not the case? Hardly "all the time". Only when absolutely necessary, the ex

Re: [Python-Dev] PEP 414

Vinay Sajip wrote: Serhiy Storchaka gmail.com> writes: n = str Well, n to indicate that native string is required. str indicates the native string type, because it *is* the native string type. By definition, str = str in both Python 2.x and Python 3.x. There's no point in aliasing it to

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

Armin Ronacher wrote: Hi, On 2/27/12 4:44 PM, mar...@v.loewis.de wrote: Maybe I'm missing something, but there doesn't seem to be a benchmark that measures the 2to3 performance, supporting the claim that it runs "two orders of magnitude" slower (which I'd interpret as a factor of 100). My Jinj

Re: [Python-Dev] Marking packaging-related PEPs as Finished after fixing some bugs in them

Terry Reedy wrote: On 2/27/2012 6:50 AM, Antoine Pitrou wrote: 'rc' makes sense to most people while 'c' is generally unheard of. 'rc' following 'a' and 'b' only makes sense to people who are used to it and know what it means. 'c' for 'candidate' makes more sense to me both a decade ago and

Re: [Python-Dev] Add a frozendict builtin type

M.-A. Lemburg wrote: Victor Stinner wrote: See also the PEP 351. I read the PEP and the email explaining why it was rejected. Just to be clear: the PEP 351 tries to freeze an object, try to convert a mutable or immutable object to an immutable object. Whereas my frozendict proposition doesn't

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

Vinay Sajip wrote: Serhiy Storchaka gmail.com> writes: Another pertinent question: "What are disadvantages of PEP 414 is adopted?" It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single codebase across 2.x and 3.x. However, it only does this if your 3.x interest is 3.3+

Re: [Python-Dev] Add a frozendict builtin type

Raymond Hettinger wrote: On Feb 29, 2012, at 3:52 PM, Victor Stinner wrote: I don't know if hardening Python is a compelling argument to add a new builtin type. It isn't. Builtins are for general purpose use. It is not something most people should use; however, if it is a builtin, people

Re: [Python-Dev] Add a frozendict builtin type

Raymond Hettinger wrote: On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote: A frozendict type is a common request from users and there are various implementations. ISTM, this request is never from someone who has a use case. Instead, it almost always comes from "completers", people who see

Re: [Python-Dev] Sandboxing Python

Armin Rigo wrote: Hi Mark, On Sun, Mar 4, 2012 at 18:34, Mark Shannon wrote: You can't solve the too much time, without solving the halting problem, Not sure what you mean by that. It seems to me that it's particularly easy to do in a roughly portable way, with alarm() for example on all UN

Re: [Python-Dev] Non-string keys in type dict

On Thu, Mar 08, 2012 at 12:20:21PM +1000, Nick Coghlan wrote: > On Thu, Mar 8, 2012 at 11:42 AM, Benjamin Peterson > wrote: > > 2012/3/7 Victor Stinner : > >> Can't we simply raise an error if the dict contains > >> non-string keys? > > > > Sounds okay to me. > > For 3.3, the most we can do is t

Re: [Python-Dev] [Python-checkins] cpython: Close #14205: dict lookup raises a RuntimeError if the dict is modified during

On Fri, Mar 09, 2012 at 05:38:05PM -0500, Yury Selivanov wrote: > Actually, I too noticed that you've dropped few crasher tests. I think > we need to keep them, to make sure that future development will not > introduce the same vulnerabilities. That's a common practice with > unit-testing. The

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

Brian Curtin wrote: On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz wrote: I think the cheesehop trove classifiers would be the ideal way to agnostically link to a page of packages related to the standard package in question. No need for sort order. Randomize the order for all I care. We still n

Re: [Python-Dev] Drop the new time.wallclock() function?

Terry Reedy wrote: On 3/15/2012 5:27 PM, Alexander Belopolsky wrote: On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner wrote: +1. I now prefer time.monotonic(), no flags. Am I alone thinking that an adjective is an odd choice for a function name? I would normally agree, but in this case, it is

Re: [Python-Dev] PEP czar for PEP 3144?

On Mon, Mar 19, 2012 at 02:50:22PM -0700, Ethan Furman wrote: > Guido van Rossum wrote: [...] > >And remember that consistency is good in moderation, but if it becomes > >a goal in itself you may have a problem. > > While I agree that consistency as a goal in and of itself is not good, I > consi

Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default

On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote: > Said differently: time.steady(strict=True) is always monotonic (*), > whereas time.steady() may or may not be monotonic, depending on what > is avaiable. > > time.steady() is a best-effort steady clock. > > (*) time.steady(strict=

Re: [Python-Dev] Playing with a new theme for the docs

Fred Drake wrote: On Wed, Mar 21, 2012 at 3:13 PM, Ned Batchelder wrote: There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are bad, or that "design" is bad. Don't throw out

Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?

Victor Stinner wrote: [...] So we will have: - time.time(): realtime, can be adjusted by the system administrator (manually) or automatically by NTP - time.clock(): monotonic clock on Windows, CPU time on UNIX - time.monotonic(): monotonic clock, its speed may or may not be adjusted by NTP but i

Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?

Victor Stinner wrote: - time.clock(): monotonic clock on Windows, CPU time on UNIX Actually, I think that is not correct. Or at least *was* not correct in 2006. http://bytes.com/topic/python/answers/527849-time-clock-going-backwards -- Steven _

Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?

Victor Stinner wrote: Is steady() merely a convenience function to avoid the user having to write something like this? steady() remembers if the last call to monotonic failed or not. The real implementation is closer to something like: def steady(): if not steady.has_monotonic: return t

Re: [Python-Dev] Rename time.steady(strict=True) to time.monotonic()?

Victor Stinner wrote: - time.clock(): monotonic clock on Windows, CPU time on UNIX Actually, I think that is not correct. Or at least *was* not correct in 2006. http://bytes.com/topic/python/answers/527849-time-clock-going-backwards Oh, I was not aware of this issue. Do you suggest to not us

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

Georg Brandl wrote: Thanks everyone for the overwhelmingly positive feedback. I've committed the new design to 3.2 and 3.3 for now, and it will be live for the 3.3 docs momentarily (3.2 isn't rebuilt at the moment until 3.2.3 final goes out). I'll transplant to 2.7 too, probably after the final

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

Terry Reedy wrote: On 3/25/2012 12:32 PM, Georg Brandl wrote: On 25.03.2012 17:54, Terry Reedy wrote: On 3/25/2012 2:34 AM, Georg Brandl wrote: Here's another try, mainly with default browser font size, more contrast Untrue. You still changed the high contrast dark blue to the same low contr

Re: [Python-Dev] PEP 418: Add monotonic clock

Georg Brandl wrote: On 28.03.2012 06:45, Nick Coghlan wrote: On Wed, Mar 28, 2012 at 10:36 AM, Victor Stinner wrote: If QueryPerformanceCounter() is monotonic, the API can be simplified to: * time.time() = system clock * time.monotonic() = monotonic clock * time.hires() = monotonic clock o

Re: [Python-Dev] PEP 418: Add monotonic clock

Matt Joiner wrote: time.timeout_clock? Everyone knows what that will be for and we won't have to make silly theoretical claims about its properties and expected uses. I don't. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] PEP 418: Add monotonic clock

Nick Coghlan wrote: Completely unintuitive and unnecessary. With the GIL taking care of synchronisation issues, we can easily coerce time.time() into being a monotonic clock by the simple expedient of saving the last returned value: [snip] Here's a version that doesn't suffer from the flaw of

Re: [Python-Dev] PEP 418: Add monotonic clock

Guido van Rossum wrote: But for the other, I'm still at a loss, and that name is the most important one. We can't call it steady because it isn't always. highres or hires sounds awkward; try_monotonic or try_steady are even more awkward. I looked in an online thesaurus and here's a list of what

Re: [Python-Dev] an alternative to embedding policy in PEP 418

Lennart Regebro wrote: On Tue, Apr 3, 2012 at 08:03, Cameron Simpson wrote: clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) If the symbol names are not the horribleness, can you qualify what API you would like more? Well, get_clock(monotonic=True, highres=True) would be a vast im

[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

Judging by the hundreds of emails regarding PEP 418, the disagreements about APIs, namings, and even what characteristics clocks should have, I believe that the suggestion is too divisive (and confusing!) to be accepted or rejected at this time. Everyone has a different opinion, everyone belie

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

On Wed, Apr 04, 2012 at 03:28:34AM +0200, Victor Stinner wrote: > Le 04/04/2012 02:33, Steven D'Aprano a écrit : > >Judging by the hundreds of emails regarding PEP 418, the disagreements > >about APIs, namings, and even what characteristics clocks should have, I > >beli

Re: [Python-Dev] an alternative to embedding policy in PEP 418

Oleg Broytman wrote: On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote: Oleg Broytman wrote: . Pythonic equivalent of "get_clock(THIS) or get_clok(THAT)" is for flag in (THIS, THAT): try: clock = get_clock(flag) except: pass else: break else: raise

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

Greg Ewing wrote: Cameron Simpson wrote: A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent polls of the clock. On its own it says nothing about steadiness or correlation with real world time. No, no, no. This is the strict mathematical meaning of the word "monotonic", but

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Cameron Simpson wrote: | The main reason to use the word "monotonic clock" to refer to the | second concept is that POSIX does so, but since Mac OS X, Solaris, | Windows, and C++ have all avoided following POSIX's mistake, I think | Python should too. No. If it is not monotonic, DO NOT CALL IT

Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Glyph Lefkowitz wrote: On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote: 2. Those who think that "monotonic clock" means a clock that never jumps, and that runs at a rate approximating the rate of real time. This is a very useful kind of clock to have! It is what C++ now calls a "steady

Re: [Python-Dev] an alternative to embedding policy in PEP 418

Cameron Simpson wrote: On 05Apr2012 08:50, Steven D'Aprano wrote: | Although I don't like the get_clock() API, I don't think this argument against | it is a good one. Just to divert briefly; you said in another post you didn't like the API and (also/because?) it didn&#x

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

Victor Stinner wrote: 2012/4/7 Janzert : On 4/5/2012 6:32 AM, Victor Stinner wrote: I prefer to use CLOCK_MONOTONIC, not because it is also available for older Linux kernels, but because it is more reliable. Even if the underlying clock source is unstable (unstable frequency), a delta of two re

Re: [Python-Dev] Suggested addition to PEP 8 for context managers

Hrvoje Niksic wrote: The same oddity occurs with expressions in kwargs calls: func(pos1, pos2, keyword=foo + bar) I find myself wanting to add parentheses arround the + to make the code clearer. Then why don't you? In the above example, spaces around the + are not only optional but discou

Re: [Python-Dev] (time) PEP 418 glossary V2

Stephen J. Turnbull wrote: On Wed, Apr 25, 2012 at 1:19 AM, Jim Jewett wrote: I'm still a little fuzzy on *why* it shouldn't count as a monotonic clock. So are the people who say it shouldn't count (unless you're speaking of the specific implementation on Unix systems, which can go backward

Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

Some issues with the PEP 418: 1) time.clock is deprecated, but also supported by get_clock_info. Why bother supporting it if you don't want people to use it? 2) get_clock_info returns a dict. Why not a namedtuple? 3) The dict returned by get_clock_info includes an optional key, "is_adjust

Re: [Python-Dev] package imports, sys.path and os.chdir()

Brett Cannon wrote: On Sat, Apr 28, 2012 at 04:08, Nick Coghlan wrote: On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon wrote: I'm personally in favour of changing the insertion of '' to sys.path to inserting the cwd when the interpreter is launched. I'm not, because it breaks importing from t

Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

Larry Hastings wrote: On 04/29/2012 02:01 AM, Eric V. Smith wrote: On 4/29/2012 4:41 AM, Larry Hastings wrote: I'd prefer an object to a dict, but not a tuple / structseq. There's no need for the members to be iterable. I agree with you, but there's already plenty of precedent for this. [...

Re: [Python-Dev] Adding types.build_class for 3.3

On Wed, May 09, 2012 at 08:57:55AM +0100, Mark Shannon wrote: > As a consequence of this, making build_class either a class method or a > static method will cause a direct call to type.build_class() to fail as > neither class method nor static method are callable. This might be a good reason to

Re: [Python-Dev] sys.implementation

Nick Coghlan wrote: On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou wrote: On Thu, 10 May 2012 11:33:14 +1000 Nick Coghlan wrote: The original concern (that sys.implementation may differ in length across implementations) has been eliminated by moving all implementation specific values into sy

Re: [Python-Dev] sys.implementation

Scott Dial wrote: On 5/10/2012 1:40 AM, Nick Coghlan wrote: Unordered types can be a PITA for testing, for display and for generic serialisation, so I definitely want to see a PEP before we add a new one that basically has its sole reason for existence being "you can iterate over and index the f

Re: [Python-Dev] sys.implementation

Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/12/2012 08:04 AM, Nick Coghlan wrote: On Sat, May 12, 2012 at 12:40 PM, Eric Snow wrote: If anyone has strong feelings for item-access over attribute-access, please elaborate. I'm just not seeing it as that important and

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

On Mon, May 21, 2012 at 01:47:50AM -0400, Terry Reedy wrote: > What might be useful is to have the 'Other versions' links on the left > margin of *every* page, not just the front page, but have them link to > the corresponding page of the other docs (if there is one, and > non-trivial I expect)

Re: [Python-Dev] doc change for weakref

Ethan Furman wrote: I'd like to make a slight doc change for weakref to state (more or less): What specific part of the docs are you planning to change? My guess is that you want to change this start of the third paragraph: http://docs.python.org/py3k/library/weakref.html [quote] A weak refe

Re: [Python-Dev] What should we do with cProfile?

Alexandre Vassalotti wrote: Hello, As per PEP 3108, we were supposed to merge profile/cProfile into one unified module. I initially championed the change, but other things got in the way and I have never got to the point of a useful patch. I posted some code and outlined an approach how the merg

Re: [Python-Dev] a new type for sys.implementation

On Thu, May 31, 2012 at 01:21:36AM -0600, Eric Snow wrote: > 1. should we make the new type un-instantiable (null out tp_new and tp_init)? Please don't. "Consenting adults" and all that. There's little things more frustrating that having a working type that does exactly what you want, except th

Re: [Python-Dev] what is happening with the regex module going into Python 3.3?

Gregory P. Smith wrote: Per the language summit, I think we need to just do it. Put it in as re and rename the existing re module to sre. I thought that the plan was to put the regex module in as regex, leaving re unchanged for backwards compatibility, with any backwards-incompatible renami

Re: [Python-Dev] what is happening with the regex module going into Python 3.3?

MRAB wrote: I personally am no longer that bothered about whether the regex module makes it into stdlib, but I am still be maintaining it on PyPI. If someone else wants to integrate it I would, of course, be willing to help out. Are you withdrawing your offer to maintain regex in the stdlib?

Re: [Python-Dev] Language reference updated for metaclasses

On Tue, Jun 05, 2012 at 10:20:58AM +0300, Eli Bendersky wrote: > Still, instance of type()" is a bit too cryptic for mere mortals, IMHO. I think that if somebody finds "instance of type" too cryptic, they won't have any chance at all to understand metaclasses. Personally, I think there is a lot

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Brett Cannon wrote: PEP: 362 Title: Function Signature Object Version: $Revision$ Last-Modified: $Date$ Author: Brett Cannon , Jiwon Seo , Yury Selivanov , Larry Hastings < la...@hastings.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 21-Aug-2006 Python-Versio

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Larry Hastings wrote: [...] "Changes to the Signature object, or to any of its data members, do not affect the function itself." which leaves the possibility that __signature__ may no longer match the actual argument spec, for some reason. If you remove getfullargspec, people will have to rei

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Yury Selivanov wrote: I like the idea of 'foo(a)' and 'bar(a)' having the identical signatures, however, I don't think it's possible. I.e. we can't make it that the 'signature(foo) is signature(bar)'. We can implement the __eq__ operator though. +1 to __eq__. I don't think we should care ab

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Larry Hastings wrote: inspect.getfullargspec is currently unable to introspect builtin functions and methods. Should builtins gain a __signature__ so they can be introspected? If function signatures are useful, then they're useful, and the implementation language for the function is irreleva

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Brett Cannon wrote: On Wed, Jun 6, 2012 at 12:16 PM, Steven D'Aprano wrote: Larry Hastings wrote: [...] "Changes to the Signature object, or to any of its data members, do not affect the function itself." which leaves the possibility that __signature__ may no longer m

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Nick Coghlan wrote: On Thu, Jun 7, 2012 at 8:38 AM, Steven D'Aprano wrote: Brett Cannon wrote: This is also Python, the language that assumes everyone is an consenting adult. Exactly, which is why I'm not asking for __signature__ to be immutable. Who knows, despite Larry's

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Nick Coghlan wrote: On Fri, Jun 8, 2012 at 4:34 AM, Larry Hastings wrote: In other words: this is possible but extremely unlikely, and will only be done knowingly and with deliberate intent by a skilled practitioner. I think it's reasonable to declare that, if you're monkeying around with dund

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote: > So, is there any reason to not use the .pyo file (if that's all that is > around) when -O is not specified? .pyo and .pyc files have potentially different semantics. Right now, .pyo files don't include asserts, so that's one diff

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

On Wed, Jun 13, 2012 at 03:13:54PM -0400, R. David Murray wrote: > Again, a program that depends on asserts is buggy. > > As Ethan pointed out we are asking about the case where someone is > *deliberately* setting the .pyo file up to be run as the "normal" > case. You can't be sure that the .pyo

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

On Wed, Jun 13, 2012 at 04:06:22PM -0400, Terry Reedy wrote: > On 6/13/2012 2:46 PM, Antoine Pitrou wrote: > > >Not only docstrings, but also asserts. I think running a pyo without -O > >would be a bug. > > That cat is already out of the bag ;-) > People are doing that now by renaming x.pyo to x.

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

On Wed, Jun 13, 2012 at 09:54:30PM -0400, Terry Reedy wrote: > >So, no, we > > You mean the interpreter? Yes. > >should never use > > Do you mean import or execute? > Current, the interpreter executes any bytecode that gets imported. Both. > >.pyo files unless explicitly told to do so, > >

Re: [Python-Dev] deprecating .pyo and -O

Floris Bruynooghe wrote: On 14 June 2012 11:25, Antoine Pitrou wrote: Honestly, I think the best option would be to deprecate .pyo files as well as the useless -O option. They only cause confusion without providing any significant benefits. +1 But what happens to __debug__ and assert stateme

Re: [Python-Dev] deprecating .pyo and -O

Antoine Pitrou wrote: Do other high-level languages have similar functionality? Parrot (does anyone actually use Parrot?) has a byte-code optimizer. javac -O is supposed to emit optimized byte-code, but allegedly it is a no-op. On the other hand, the Java ecosystem includes third-party Java

Re: [Python-Dev] PEP 362 Third Revision

R. David Murray wrote: We know that a string cannot be both all-upper and all-lower at the same time; We know that because it's common wisdom for everyone (although who knows what oddities the unicode consortium may come up with in the future). Indeed, there is at least one letter that is use

Re: [Python-Dev] PEP 362 Third Revision

Yury Selivanov wrote: On 2012-06-14, at 4:53 PM, Antoine Pitrou wrote: On Wed, 13 Jun 2012 22:52:43 -0400 Yury Selivanov wrote: * bind(\*args, \*\*kwargs) -> BoundArguments Creates a mapping from positional and keyword arguments to parameters. Raises a ``BindError`` (subclass of ``Type

Re: [Python-Dev] PEP 362: 4th edition

Yury Selivanov wrote: Hello, The new revision of PEP 362 has been posted: http://www.python.org/dev/peps/pep-0362/ Open questions: 1. Should we keep 'Parameter.implemented' or not. *Please vote* -0.5 It is easier to add it later if it is needed, then to take it away if not needed. 2

Re: [Python-Dev] Tunable parameters in dictobject.c (was dictnotes.txt out of date?)

Raymond Hettinger wrote: Sorry I can make a more detailed post right now. I'll make time in the next couple of weeks to post some code and timings that document the collision counts, total memory size, and its affect on various dict use cases. Is there some way to instrument dictionary spars

Re: [Python-Dev] PEP 362: 4th edition

On Mon, Jun 18, 2012 at 07:10:33PM -0400, Yury Selivanov wrote: > It seems that we have the following options for 'signature(obj)': > > 1. If 'obj' has a '__signature__' attribute - return a copy of it, > if not - create a new one. > > 2. If 'obj' has a '__signature__' attribute - return it, > i

Re: [Python-Dev] PEP 362: 4th edition

On Mon, Jun 18, 2012 at 02:09:17PM -0400, Yury Selivanov wrote: > That's an excerpt from Signature.__deepcopy__: > > cls = type(self) > sig = cls.__new__(cls) > sig.parameters = OrderedDict((name, param.__copy__()) \ >for name, param in self.parameters.i

Re: [Python-Dev] pep 362 - 5th edition

On Tue, Jun 19, 2012 at 12:38:38PM -0400, Yury Selivanov wrote: > > class Signature: > > . . . > > def equivalent(self, other): > > "compares two Signatures for equality (ignores parameter names)" > > . . . > > I don't think that comparing signatures will be a common operation, > so

Re: [Python-Dev] PEP 362 minor nits

On Tue, Jun 19, 2012 at 08:11:26PM -0400, Yury Selivanov wrote: > So using the signature will be OK for 'Foo.bar' and 'Foo().bar', but > not for 'Foo.__dict__['bar']' - which I think is fine (since > staticmethod & classmethod instances are not callable) There has been some talk on Python-ideas a

Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)

anatoly techtonik wrote: On Wed, Jul 4, 2012 at 9:31 PM, Terry Reedy wrote: A sliding window for a generic iterable requires a deque or ring buffer approach that is quite different from the zip-longest -- grouper approach. That's why I'd like to drastically reduce the scope of proposal. ite

Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)

anatoly techtonik wrote: Which is the 33th most voted Python question on SO - http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks-in-python/312464 I am curious how you get that number. I do note that there are about 15 other Python SO questions that seem t

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Nick Coghlan wrote: On Sun, Jul 15, 2012 at 9:18 AM, Benjamin Peterson wrote: Open questions == There are two open questions for this PEP: * Should ``list`` expose a kwarg in it's constructor for supplying a length hint. * Should a function be added either to ``builtins`` or som

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Antoine Pitrou wrote: The point is that 0 is a legitimate value for a length hint. Simple implementations of __length_hint__ will start returning 0 as a legitimate value and you will wrongly interpret that as "don't know", which kinds of defeat the purpose of __length-hint__ ;) That said, I

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Mark Shannon wrote: So how does an iterator express infinite length? The suggestion was it should return -1. What should happen if I am silly enough to do this: >>> list(itertools.count()) This will fail; it should fail quickly. That depends on your OS. I've just tested it now on Linux

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Antoine Pitrou wrote: First, you can't implement __length_hint__ for a generator, which is the preferred (the most practical) way of writing iterators in pure Python. Limitations of generators are no reason for not improving iterators which are not generators. __length_hint__ already exists;

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Steven D'Aprano wrote: With a length hint, we could strengthen that promise: "if __length_hint__ returns a negative number, list, tuple and set will fail immediately with MemoryError" which I think is a good safety feature for some things which cannot possibly succeed, but r

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Stephen J. Turnbull wrote: The point is that I don't really see the value in returning a precise estimate that cannot be relied on to be accurate. OK, Python is a "consenting adults" language, but returning an integer here seems like invitation to abuse. Since __length_hint__ already exists a

Re: [Python-Dev] A new JIT compiler for a faster CPython?

Victor Stinner wrote: == Other Python VM and compilers == As far as I know, these are all still active, although possibly experimental: Pynie (Python for the Parrot VM) WPython (16-bit word-codes instead of byte-codes) HotPy (high-performance optimizing

Re: [Python-Dev] Use function names instead of functions for os.supports_dir_fd?

Victor Stinner wrote: Hi, Python 3.3 introduced os.supports_dir_fd to check if some os functions do accept a file descriptor instead of a path. The problem is that os.supports_dir_fd is a list of functions, not a list of function names. If os functions are monkey patched, you cannot test anymore

Re: [Python-Dev] [compatibility-sig] do all VMs implement the ast module? (was: Re: AST optimizer implemented in Python)

On 14/08/12 06:46, Guido van Rossum wrote: On Mon, Aug 13, 2012 at 1:05 PM, fwierzbi...@gmail.com wrote: On Mon, Aug 13, 2012 at 12:06 PM, Brett Cannon wrote: I see nothing about ast possibly being CPython only. Should there be? Time to ask the other VMs what they are currently doing (the

Re: [Python-Dev] 3.3 str timings

On 21/08/12 23:04, Victor Stinner wrote: I don't like the timeit module for micro benchmarks, it is really unstable (default settings are not written for micro benchmarks). [...] I wrote my own benchmark tool, based on timeit, to have more stable results on micro benchmarks: https://bitbucket.

<    10   11   12   13   14   15   16   >