On 04/26/2013 09:27 AM, Serhiy Storchaka wrote:
26.04.13 18:50, Larry Hastings написав(ла):
The standard Java documentation on enums:
http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
This example requires more than features discussed here. It requires
an enum constructor
On 04/26/2013 12:34 AM, Greg Ewing wrote:
Or if, as Guido says, the only sensible things to use
as enum values are ints and strings, just leave anything
alone that isn't one of those.
The standard Java documentation on enums:
http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
has
On 04/15/2013 09:31 AM, Eli Bendersky wrote:
Would it make sense to think about adding this in the scope of the
argument clinic work, or is it too unrelated? This seems like a
commonly needed thing for large parts of the stdlib (where the C
accelerator overrides Python code).
From my perspect
On 04/12/2013 10:05 AM, Guido van Rossum wrote:
On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou wrote:
I think we want glob("*.py") to find
"SETUP.PY" under Windows. Anything else will probably be surprising to
users of that platform.
Yeah, I suppose so. But there are more crazy details. E.g.
On 04/03/2013 09:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
It's analogous to all
the other built-in types-as-functions, so int() calls __int__() which
must
return a concrete integer.
Why must it? I think that's the claim which must be justified, not
just taken
as
On 03/20/2013 11:34 PM, Georg Brandl wrote:
I don't really understand what Antoine's "quiescently torpid" means,
"quiescent" = "peaceful, quiet, still"
"torpid" = "lethargic, not moving"
"antoine" = "thesaurus owner"
//arry/
___
Python-Dev mailing l
Mark Shannon, Dmitry Jemerov (from PyCharm) and I sat down to talk about
rearchitecting the Argument Clinic prototype to make it easily to
interact with. We came up with the following.
The DSL will now produce an intermediate representation. The output
will consume this intermediate repres
On 03/19/2013 12:23 AM, Nick Coghlan wrote:
On Mon, Mar 18, 2013 at 11:08 PM, Stefan Behnel wrote:
My first idea for implementation: add a "def x" to the front and ": pass"
to the end
Why not require it to be there already? Maybe more like
def foo(arg, b=3, *, kwonly='a'):
..
On 03/19/2013 12:37 AM, Serhiy Storchaka wrote:
On 19.03.13 06:45, Larry Hastings wrote:
4. Store a string that looks like the Python declaration of the
signature, and parse it (Nick's suggestion). For foo above, this would
be "(arg,b=3,*,kwonly='a')". Length: 23 b
The original impetus for Argument Clinic was adding introspection
information for builtins--it seemed like any manual approach I came up
with would push the builtins maintenance burden beyond the pale.
Assuming that we have Argument Clinic or something like it, we don't
need to optimize for
On 03/18/2013 02:29 AM, Ronald Oussoren wrote:
On 18 Mar, 2013, at 8:16, Larry Hastings wrote:
This has some consequences. For example, inspect.getfullargspec,
inspect.Signature, and indeed types.FunctionObject and types.CodeObject have no
currently defined mechanism for communicating that
On 03/18/2013 12:16 AM, Larry Hastings wrote:
I'll amend my PEP soonish to reflect this. Specifically the semantics
of the /, [, and ] lines in the parameter section.
I've just posted this revision.
I'd like to draw everyone's attention to the top entry in the Notes
On 03/17/2013 03:26 PM, Stefan Krah wrote:
While I like the syntax better and appreciate the option to condense the
function declaration I still fear that the amount of implicitness will
distract from what is important: programming in C.
This applies especially if people start declaring conver
On 03/16/2013 02:17 AM, Stefan Krah wrote:
Both PEPs were discussed at PyCon. The state of affairs is that a
compromise is being worked upon and will be published by Larry in
a revised PEP.
I've pushed an update to PEP 436, the Argument Clinic PEP. It's now
live on python.org.
//arry/
___
On 02/26/2013 06:30 PM, Terry Reedy wrote:
On 2/26/2013 1:47 PM, Larry Hastings wrote:
I think positional-only functions should be discouraged, but we don't
If I were writing something like Clinic, I would be tempted to not
have that option. But I was actually thinking about something i
On 02/26/2013 08:11 AM, Terry Reedy wrote:
The PEP gives an internal, developer-focused rationale. I think there
is also an external, user-focused rationale. As much as possible (with
obvious caveats about type introspection), I think it should be
transparent to users (other than speed) whether
Following up on a conversation on python-dev from last December:
http://mail.python.org/pipermail/python-dev/2012-December/122920.html
I'm pleased to announced PEP 436, proposing Argument Clinic for adoption
into the CPython source tree.
http://www.python.org/dev/peps/pep-0436/
Argum
On 02/12/2013 05:25 PM, Christian Tismer wrote:
Ropes have been implemented by Carl-Friedrich Bolz in 2007 as I remember.
No idea what the impact was, if any at all.
Would ropes be an answer (and a simple way to cope with string mutation
patterns) as an alternative implementation, and therefore s
On 01/29/2013 09:00 AM, Victor Stinner wrote:
Hi,
Here is a new version of my PEP 433.
[...]
* ``os.get_cloexec(fd)``
* ``os.set_cloexec(fd, cloexec=True)``
* ``sys.getdefaultcloexec()``
* ``sys.setdefaultcloexec(cloexec=True)``
Passing no judgment on the PEP otherwise, just a single o
On 01/14/2013 01:44 PM, Greg Ewing wrote:
I think "protect" is *far* too vague. We don't want something
so neutral that it gives no clue at all about its meaning.
My shoot-from-the-hip name suggestion: "sterile". (Does not produce
offspring.)
When a process and a file descriptor love each o
On 12/13/2012 05:21 PM, Trent Nelson wrote:
Thoughts?
% hg help rebase
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/
On 12/04/2012 02:10 PM, Brian Curtin wrote:
I think an issue on roundup could work just fine.
http://bugs.python.org/issue16612
Cheers,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
On 12/04/2012 01:49 PM, Chris Angelico wrote:
One thing I'm not entirely clear on. Do you run Clinic on a source
file and it edits that file, or is it a step in the build process?
Your description of a preprocessor makes me think the latter, but the
style of code (eg the checksum) suggests the fo
On 12/04/2012 01:08 AM, Antoine Pitrou wrote:
Le Mon, 03 Dec 2012 14:29:35 -0800,
Larry Hastings a écrit :
/*[clinic]
dbm.open -> mapping
basename=dbmopen
const char *filename;
The filename to open.
So how does it handle the fact that filename can either
On 12/04/2012 04:10 AM, Ulrich Eckhardt wrote:
This also brings me to a single question I have for your proposal: Why
did you create another DSL instead of using Python, i.e. instead of
using cog directly? Looking at the above, I could imagine this being
written like this instead:
Actually my
On 12/03/2012 02:37 PM, Barry Warsaw wrote:
The biggest question with generated code is always the effect on debugging.
How horrible will it be when I have to step through argument parsing to figure
out what's going wrong?
Right now, it's exactly like the existing solution. The generated
fun
On 12/03/2012 03:42 PM, Gregory P. Smith wrote:
On Mon, Dec 3, 2012 at 2:29 PM, Larry Hastings <mailto:la...@hastings.org>> wrote:
Default
values for arguments are represented in C as strings; the conversion
process attempts eval() on the string, and if that works it
Say there, the Python core development community! Have I got
a question for you!
*ahem*
Which of the following four options do you dislike least? ;-)
1) CPython continues to provide no "function signature"
objects (PEP 362) or inspect.getfullargspec() information
for any function imple
On 11/09/2012 09:54 AM, Ronald Oussoren wrote:
On 9 Nov, 2012, at 11:57, Chris Withers wrote:
Hah! Should http://docs.python.org/devguide/ be updated to reflect this or does
this only affect Mac OS? (or should we correct the build so it doesn't spit out
a .exe?)
How else should it be named,
On 10/24/2012 03:15 PM, Nick Coghlan wrote:
Breaking such files up into separately compiled modules serves two
purposes:
1. It proves that the code *isn't* a tangled monolithic mess;
2. It enlists the compilation toolchain's assistance in ensuring that
remains the case in the future.
Eith
On 10/23/2012 09:29 AM, Georg Brandl wrote:
Especially since you're suggesting a huge number of new files, I question the
argument of better navigability.
FWIW I'm -1 on it too. I don't see what the big deal is with "large"
source files. If you have difficulty finding your way around
unicod
On 10/21/2012 09:35 PM, Steven D'Aprano wrote:
so as far as I can tell, the only way you could accidentally get a
complex number without expecting one is by exponentiation, either by **
or the builtin pow. This includes square roots. Exponentiation isn't as
common as the basic four arithmetic ope
On 10/18/2012 08:02 PM, Nick Coghlan wrote:
With the 3.4 release PEP published using a traditional schedule,
perhaps MvL would care to do the honours as BDFL-Delegate in rejecting
the two "faster release cycle for the standard library" PEPs?
(I know I asked to hold off on that when MvL last brou
Should have posted a link, sorry. Here you go:
http://www.python.org/dev/peps/pep-0429/
//arry/
On 10/17/2012 04:12 PM, Larry Hastings wrote:
It's essentially identical to the draft I posted last week--nothing
new there. Looking forward to February 2014!
And, to quote Barry W
It's essentially identical to the draft I posted last week--nothing new
there. Looking forward to February 2014!
And, to quote Barry Warsaw, let the wild rumpus begin!,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
On 10/16/2012 11:23 AM, Hynek Schlawack wrote:
Am 16.10.2012 um 12:15 schrieb andrew.svetlov :
+ For easy to use interface to system randomness please see
+ :class:`random.SystemRandom`.
Is it just my non-native speaker ears, or should there be an “an” before “easy”?
There should. And "
On 10/05/2012 01:59 PM, Devin Jeanpierre wrote:
I've never understood why locals() returned a mutable dictionary
either, except that Python has no immutable dictionary type.
Ah, but these days it has types.MappingProxyType which provides a
read-only wrapper around another mapping type. Perhap
On 10/03/2012 05:27 PM, Nick Coghlan wrote:
That's your prerogative as RM of course, but you haven't given any
reason beyond the circular "I don't care about enabling feedback from
people that can't or won't build from source, because people that
can't or won't build from source don't provide us
On 10/03/2012 04:55 PM, Nick Coghlan wrote:
Regardless of when the first alpha happens, I'll be promoting the hell
out of it, begging for feedback on any of these changes that are
available by then (which should be quite a few, given the preceding
PyCon US sprints).
If you can show me people wh
On 10/03/2012 01:45 PM, Skip Montanaro wrote:
Is there a rough list of changes for 3.4 written down somewhere, or is
that only to be inferred based on PEPs whose Python-Version header
reads "3.4"? How confident are you that the schedule you've proposed
gives enough time for proposed changes to
On 10/03/2012 01:40 PM, Nick Coghlan wrote:
On Wed, Oct 3, 2012 at 4:57 PM, Larry Hastings wrote:
- 3.4.0 alpha 1: August 3, 2013
Looks pretty good to me, but I'd still like to experiment with
bringing this one up a few months (say to April, a few weeks after
PyCon US 2013). I'm s
Howdy howdy. Unless someone has a better idea, I'm the release manager
for Python 3.4. I've roughed out a release schedule, assuming a
16-month period between 3.3 and 3.4. It works out to having 3.4 ship
about seven weeks before the PyCon 2014 core dev sprint, so even if we
slip some we sh
On 10/01/2012 04:29 PM, Barry Warsaw wrote:
Using the script I mentioned in an different response, if someone installed
the database to some location (TBD), then there would probably be a config
file sitting next to it. A simple .ini file with an 'enable' flag would be
needed to turn on the over
On 10/01/2012 12:07 AM, Chris Angelico wrote:
There's no guarantee that an individual sysadmin will have OS updates
up-to-date.
Is there a way of asking the database its revision / date? If so we
could simply use the freshest data we can lay our hands on.
//arry/
__
On 09/04/2012 03:15 PM, mar...@v.loewis.de wrote:
The world wouldn't end if the test broke on Tru64, though.
FWIW, HP drops support for Tru64 at the end of this year:
http://h30097.www3.hp.com/tru64roadmap.pdf
Of course, this doesn't directly imply Python should stop supporting
it--IIRC
On 07/17/2012 04:34 PM, Steven D'Aprano wrote:
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)
[...]
WPython in particular seems to be very promising, and q
On 07/17/2012 10:34 AM, Victor Stinner wrote:
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
I only got one more RSVP and zero topics for the docket. So let's
sprint instead.
See you at the PyCon 2013 Language Summit,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
So far I've had exactly four reservations for the Language Summit at
EuroPython 2012. One of them is Guido--but he's threatening to skip it
if we don't get more people and just go to the sprints.
Also, honestly I have next-to-nothing on the docket. At this point
we've just hit feature fre
On 06/26/2012 11:10 PM, Georg Brandl wrote:
On behalf of the Python development team, I'm happy to announce the
first beta release of Python 3.3.0.
I <3 <3.<3
Thanks Georg! And everybody who contributed.
Stoked,
//arry/
___
Python-Dev mailing lis
On 06/24/2012 07:21 PM, Nick Coghlan wrote:
Larry, I think this commit accidentally reverted a couple of entries
in Misc/NEWS.
It did; I restored them in the subsequent commit.
It's been a hectic couple of days,
//arry/
___
Python-Dev mailing list
On 06/23/2012 04:44 PM, Chris Angelico wrote:
On Sun, Jun 24, 2012 at 9:40 AM, Christian Heimes wrote:
+1 for the general idea and for using Py_LIMITED_API. I still like my
idea of a simple macro based on Include/patchlevel.h, for example:
#define Py_API_VERSION(major, minor, micro) \
(((m
On 06/23/2012 03:08 PM, "Martin v. Löwis" wrote:
On 23.06.2012 23:41, Antoine Pitrou wrote:
Perhaps something more user-friendly than the hexversion?
Please propose something. I think the hexversion *is* user-friendly,
+1 to the idea, and specifically to using hexversion here. (Though what
On 06/22/2012 03:48 PM, MRAB wrote:
On 22/06/2012 21:45, Larry Hastings wrote:
On 06/22/2012 01:29 PM, Terry Reedy wrote:
Of course. And character 32 is also not usable and perhaps not
worth testing.
Au contraire! I grant you, it's hard to imagine how using it would be a
good idea.
On 06/22/2012 01:29 PM, Terry Reedy wrote:
Of course. And character 32 is also not usable and perhaps not
worth testing.
Au contraire! I grant you, it's hard to imagine how using it would be a
good idea. But strictly speaking it is *usable*. (And what is this
thread about if not wanton pe
On 06/22/2012 11:21 AM, MRAB wrote:
On 22/06/2012 17:39, Terry Reedy wrote:
You sensibly only test printable ascii chars, which are in the
contiguous range 32 to 127 inclusive. So it makes no sense to claim
otherwise and then deny the wrong claim, or to enlarge the range and
then shrink it again
On 06/22/2012 12:21 PM, Christian Heimes wrote:
The PEP is already complex enough and went to several incarnations. It
was a wise decision to focus on the features that could be implemented
before the first beta is released. Kudos for pulling it off, Larry!
Guys, guys! I have done next-to-not
Here's PEP 362:
http://www.python.org/dev/peps/pep-0362/
It adds easy introspection abilities to Python callables. After a
whirlwind of activity over the past several weeks we think it's ready.
All it needs now is an official pronouncement from some seasoned veteran
of the Python commu
On 06/18/2012 07:35 PM, Yury Selivanov wrote:
BTW, http://bugs.python.org/issue15008 has the latest implementation
attached (if anybody wants to play with it)
I've also posted the latest minor tweaks to the PEP, on behalf of Yury.
The new version is already live:
http://www.python.org/de
On 05/31/2012 09:47 AM, "Martin v. Löwis" wrote:
I hereby predict that Microsoft will revert this decision, and that
VS Express 11 will be able to build CPython.
But will it be able to target Windows XP?
I have now tried, and it seems that the chances are really low (unless
you use th
On 06/15/2012 02:13 PM, Antoine Pitrou wrote:
I'm not sure I understand. The PEP already says signatures are computed
lazily. Is there an exception for built-in functions?
Right now we have no way to automatically generate signatures for
built-in functions. So, as of current trunk, any such
One wrinkle of PEP 362 in CPython is callables implemented directly in
C. Right now there's no good way to generate such signatures
automatically. That's why we kept __signature__ in the spec, to allow
implementors to generate signatures by hand for these callables.
But the wrinkle gets w
On 06/15/2012 12:50 PM, Yury Selivanov wrote:
Open questions:
1. Should we keep 'Parameter.implemented' or not. *Please vote*
+1 to keeping Parameter.implemented.
Let's get this over with,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
On 06/15/2012 12:34 PM, Yury Selivanov wrote:
On 2012-06-15, at 3:31 PM, Larry Hastings wrote:
(Perhaps the right thing would be to take this discussion to issue 14626.)
Let's keep it in this thread while it's related to Signature.
I can assure you, however Benjamin might spell it
On 06/15/2012 12:06 PM, Benjamin Peterson wrote:
2012/6/15 Larry Hastings:
On 06/15/2012 11:46 AM, R. David Murray wrote:
Adding a os.have_openat seems more reasonable than adding is_implemented
to every __signature__ object. And more useful, as well; it provides
a much more specific piece
On 06/15/2012 11:46 AM, R. David Murray wrote:
Adding a os.have_openat seems more reasonable than adding is_implemented
to every __signature__ object. And more useful, as well; it provides
a much more specific piece of information.
We already have "os.have_openat"; it's spelled
sysconfig.get_
On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Peterson wrote:
2012/6/15 Larry Hastings:
If I understand you correctly, you seem to be trying to apply
"is_implemented" to the problem of predicting which specific inputs to a
parameter would be valid. I don't think that problem is
On 06/15/2012 04:32 AM, Nick Coghlan wrote:
Since I don't believe your proposed flag will answer any question that
actually matters in practice, I consider it useless noise that should
be dropped from the proposal.
I can cite a situation where it matters in practice: the implementation
of os.
On 06/15/2012 12:18 AM, Nick Coghlan wrote:
Perhaps you meant "ill-concieved"?
No, I mean ill-defined. The criteria for when a particular platform
should flip that bit for an arbitrary parameter is highly unclear, as
whether or not a particular parameter is "implemented" or not depends
on the o
On 06/14/2012 11:37 PM, Victor Stinner wrote:
os.chown.__signature__.parameters['fd'].is_implemented =
sysconfig.get_config_var('HAVE_FCHOWN')
(Do you mean "fd" or "dirfd"?)
I meant "fd". "dir_fd" is contingent on fchownat(). But it was only an
example anyway.
I don't like such functio
On 06/14/2012 08:41 PM, Nick Coghlan wrote:
On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson wrote:
2012/6/14 Larry Hastings:
Also, it's more granular than that. For example, Python now understands
symbolic links on Windows--but only haphazardly at best. The
"follow_symlinks
On 06/14/2012 08:20 PM, Benjamin Peterson wrote:
2012/6/14 Larry Hastings:
Also, it's more granular than that. For example, Python now understands
symbolic links on Windows--but only haphazardly at best. The
"follow_symlinks" argument works on Windows for os.stat() but n
On 06/14/2012 07:49 PM, Benjamin Peterson wrote:
In that case wouldn't be nicer to have os level attribute ala
os.path.supports_unicode_filenames?
os.supports_atfunctions
is gobs nicer than
os.chown.__signature__.parameters['fd'].is_implemented
Not "implementing" all parameters (whatever exac
On 06/14/2012 01:53 PM, Antoine Pitrou wrote:
* is_implemented : bool
True if the parameter is implemented for use. Some platforms
implement functions but can't support specific parameters
(e.g. "mode" for ``os.mkdir``). Passing in an unimplemented
parameter may result in t
On 06/14/2012 05:06 AM, Victor Stinner wrote:
* is_implemented : bool
True if the parameter is implemented for use. Some platforms
implement functions but can't support specific parameters
(e.g. "mode" for ``os.mkdir``). Passing in an unimplemented
parameter may result in the pa
On 06/10/2012 10:59 AM, Benjamin Peterson wrote:
2012/6/5 Brett Cannon:
* is_keyword_only : bool
True if the parameter is keyword-only, else False.
* is_args : bool
True if the parameter accepts variable number of arguments
(``\*args``-like), else False.
How about "vararg" as i
On 06/07/2012 07:08 PM, Steven D'Aprano wrote:
Perhaps func.__signature__ should be a computed the first time it is
accessed?
The PEP already declares that signatures are lazily generated.
signature() checks to see if __signature__ is set, and if it is returns
it. (Or, rather, a deepcopy of
On 06/07/2012 10:08 AM, Eric Snow wrote:
I'm missing something here. Can you give me an example of modifying an
existing function object such that its Signature would change? Decorators
implementing a closure with a different signature don't count--they return a
new function object.
I doubt t
On 06/06/2012 06:00 PM, Nick Coghlan wrote:
On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow wrote:
Furthermore, using __signature__ as a cache may even cause problems.
If the Signature object is cached then any changes to the function
will not be reflected in the Signature object. Certainly that's
On 06/06/2012 11:56 PM, Nick Coghlan wrote:
I'd say return a copy in the first case to be safe against accidental
modification. If someone actually wants in-place modification, they
can access __signature__ directly.
I really don't understand this anxiety about mutable Signature objects.
Can
Sorry I missed answering these on my first pass.
On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
What to do about parameters which are partly implemented? E.g.
mode='spam' is implemented but mode='ham' is not.
Parameter objects aren't sophisticated enough to represent such a
situation. If y
On 06/06/2012 09:16 AM, Steven D'Aprano wrote:
Nevertheless, the world is full of doorknobs, and people will have to
deal with their code.
I'm having a hard time seeing it. Can you propose a credible situation
where
* some programmer would have a reason (even a bad reason) to modify
th
On 06/06/2012 09:05 AM, Larry Hastings wrote:
Is there a use-case for is_implemented?
Yes, see issue 14626.
I should add, there are already some places in the standard library
where is_implemented would be relevant. The "mode" argument to os.mkdir
comes immediately to mind; on
On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
What's the fully qualified name of the function, and why is it needed?
Please see PEP 3155.
"args" is just a common name for the parameter, not for the kind of
parameter. *args (or *data, *whatever) is a varargs parameter, and so
the attribut
On 06/03/2012 08:32 AM, "Martin v. Löwis" wrote:
So I propose to just remove the claim from the PEP that 3.3 would
still be supported, and not go through any notification period.
Did you mean
s/3.3/Windows 2000/
?
//arry/
___
Python-Dev mailing
On 05/30/2012 05:06 AM, Larry Hastings wrote:
Like Python? Like Italy? Like meetings? Then I've got a treat for you!
I'll be chairing a Python Language Summit this July in historic
Florence, Italy. It'll be on July 1st (the day before EuroPython
starts) at the Grand Hot
On 05/30/2012 12:43 PM, "Martin v. Löwis" wrote:
Please understand that Visual Studio never had the notion of
"targetting" an operating system. The Windows SDK has that notion, and
it appears that targetting XP continues to be supported.
I may be misremembering, but--the C API of necessity cal
Like Python? Like Italy? Like meetings? Then I've got a treat for you!
I'll be chairing a Python Language Summit this July in historic
Florence, Italy. It'll be on July 1st (the day before EuroPython
starts) at the Grand Hotel Mediterraneo conference center. Language
Summits are when th
On 05/25/2012 10:14 AM, Antoine Pitrou wrote:
On Fri, 25 May 2012 18:57:57 +0200
Georg Brandl wrote:
This is probably minor, but wouldn't it make more sense to have those
constants uppercased? At least that's the general style we have in
the codebase for enum values.
+1, this surprised me to
On 05/09/2012 09:53 AM, Barry Warsaw wrote:
On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
Sure, but couldn't we define this "empty" class in C code so that you can
use the C API with it as well and just provide a C function to get a new
instance?
+1
ISTM to be a companion to collections.n
On 05/05/2012 06:17 PM, Stefan Krah wrote:
larry.hastings wrote:
Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.)
+ * De-vararg'd PyArg_ParseTupleAndKeywords()
This looks like an accidental commit. Is there an issue number for the
varargs changes (just out of int
On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
+if (times&& ns) {
+PyErr_Format(PyExc_RuntimeError,
Why not a ValueError or TypeError?
Well it's certainly not a TypeError. The 3.2 documentation defines
TypeError as:
Raised when an operation or function is applied to an o
Right now the CPython trunk religiously declares all variables at the
tops of scopes, before any code, because this is all C89 permits. Back
in the 90s all the C compilers took a page out of the C++ playbook and
independently, but nearly without exception, extended the language to
allow you
On 05/01/2012 01:12 PM, Brett Cannon wrote:
That would be great! First thing is addressing Guido's concerns from
http://mail.python.org/pipermail/python-dev/2012-March/117515.html and
then handling any issues you found. Not sure if Larry was asking about
this out of curiosity or because he too
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.
[...] Iter
On 04/28/2012 04:20 PM, Eric V. Smith wrote:
But we generally use a namedtuple (or structseq) for things like
get_clock_info. For example, for sys.float_info there's no need for it
to be a tuple, and it can be extended in the future, yet it's a structseq.
I'd prefer an object to a dict, but not
On 04/25/2012 10:31 PM, Eric Snow wrote:
The patch adds a struct sequence that holds ("name" => "CPython",
"version" => sys.version_info). If later needs dictate more fields,
we can cross that bridge then.
My one bit of bike-shedding: I don't think it's desirable that this
object be iterabl
On 03/31/2012 12:47 AM, Victor Stinner wrote:
Can you go into more detail about QPC()'s issues?
Yes, see the PEP:
http://www.python.org/dev/peps/pep-0418/#windows-queryperformancecounter
FYI, Victor, the PEP is slightly incomplete. Not that this is your
fault--you've done your homework. Bu
On 03/28/2012 01:56 PM, R. David Murray wrote:
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano wrote:
+1 on Nick's suggestion of try_monotonic. It is clear and obvious and doesn't
mislead.
How about "monotonicest".
(No, this is not really a serious suggestion.)
"monotonish".
Thus honor
On 02/26/2012 03:33 PM, Guido van Rossum wrote:
One thing I'd like to see happening regardless is support for
new-style formatting in the logging module. It's a little tricky to
think how that would work, alas -- should this be a property of the
logger or of the call?
There already is some supp
701 - 800 of 882 matches
Mail list logo
