Re: sys.ps1 with formatting (linux)
Hi all, My apologies for resurrecting an old thread, but I couldn't find the answer on the list and others might still have the same problem. On Mon Jul 23 22:33:22 CEST 2007, Jon Dobson wrote (reformatted): I'm trying to set sys.ps1 and sys.ps2 with some formatting using: sys.ps1="\033[1m\033[32mspy>\033[0m" > sys.ps2="\033[1m\033[32m .\033[0m" I get the colored prompt(s) as you might expect, but I'm getting some > strange behavior with wrapping. Once the interactive command gets long > enough to wrap, it wraps back to the same line (overwriting the > beginning). It doesn't break anything - the command gets interpreted > correctly, it's just an ugly way to work. After a couple of hours of having the same problem, I found out that you should surround the unprintable characters with \001 and \002: sys.ps1="\001\033[1m\033[32m\002spy>\001\033[0m\002" sys.ps2="\001\033[1m\033[32m\002 .\001\033[0m\002" Solution found in: http://hg.secdev.org/scapy/raw-file/tip/scapy.py: > ^A and ^B delimit invisible caracters for readline to count right Greetings, Hugo -- http://mail.python.org/mailman/listinfo/python-list
Re: Find class of an instance?
Neal Becker schreef: Sounds simple, but how, given an instance, do I find the class? I always do that with .__class__, not sure whether it is the best way: >>> class A: ... pass ... >>> a = A() >>> a.__class__ >>> a.__class__ == A True -- http://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] How to run multiline shell command within python
On Thu, Jan 10, 2013 at 7:01 AM, Karim wrote:
>
>
> Hello all,
>
> I want to run multiline shell command within python without using a
> command file but directly execute several lines of shell.
> I already use *subprocess.checkoutput("csh -f my_file.csh".split())* but I
> want to know if it is posssible to avoid making file and execute
> shell lines of code directly.
>
>
Yes, this is very possible. Specify shell=True as an argument and you can
do anything you can do in a shell:
>>> commands = """echo hello
... echo hello | wc -l
... ps aux | grep python"""
>>> b = subprocess.check_output(commands, shell=True)
>>> print(b.decode('ascii'))
hello
1
hugo 1255 1.0 0.6 777316 49924 ?Sl 09:14 0:08
/usr/bin/python2 /usr/bi
hugo 6529 0.0 0.0 42408 7196 pts/0S+ 09:23 0:00 python
hugo 6559 0.0 0.0 10656 1128 pts/0S+ 09:28 0:00 grep python
>>>
watch out though, accepting user input into the commands variable will lead
to shell injection, which can be a dangerous security vulnerability.
HTH,
Hugo
--
http://mail.python.org/mailman/listinfo/python-list
[SerialConnection] Help
Hi. I want to connect to a serial port, read and write the port values with multi threading and save them in random variables in python 3.4. Where can I found information to do that? thank you -- https://mail.python.org/mailman/listinfo/python-list
Changing interpolation
Another quick question this morning Does anyone have the syntax to change keyframe interpolation of a curve ? For exemple, I am trying to change the curve of the translate of a camera using this and it does not do much nuke.selectedNode().knobs()['translate'].animations()[0].changeInterpolation( nuke.selectedNode().knobs()['translate'].animations()[0].keys() , nuke.CONSTANT) -- Hugo Léveillé TD Compositing, Vision Globale hu...@fastmail.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Type signature
Which is expecially true when using IDEs with auto-completion.Using VisualStudio/MonoDevelop and C# I rarely need to look at the documentation because I can quickly see what a method accept and returns. And when I need to pass flags or options, enums are much more neat and encapsulated. With Python I'm constantly looking at the documentation when surfing a library. I personally like the terse code and abstraction features of Python which is making me slowly writing more and more tools in it. Still, I have to agree that there are edges (like these) that must be sharpened out...On 7/24/06, paul kölle <[EMAIL PROTECTED]> wrote: Marc 'BlackJack' Rintsch wrote:> In <[EMAIL PROTECTED]>, Yacao Wang> wrote:>>> However, type signatures are not only a kind of information provided for >> the compiler, but also for the programmer, or more important, for the>> programmer. Without it, we have to "infer" the return type or required>> agument types of a function, and this can't be done without seeing the >> implementation of it,>> That's what documentation is meant for. If you are forced to look at the> implementation, the documentation is bad.I think the OP refers to reading the *code*, the documentation might not exist (yet). Sometimes I feel python is easier to write than to read and missing argument type declarations (just for documentation purposes)are IMHO one reason. Another are missing (optional) argument type checks at runtime. Something like WrongArgumentType exceptions insteadof rather unspecific AttributeError from deep inside the code would bevery convenient.Yes docstrings are nice but sometimes a simple: foo(int:param1, string:param2) is way better than:foo(param1, param2): """ @type param1: integer @type parame2: string """cheers Paul-- http://mail.python.org/mailman/listinfo/python-list-- GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85 -- http://mail.python.org/mailman/listinfo/python-list
ELF format reader
Hi, I am looking for an ELF format reader written in python. Does anyone know if it exists?H. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: [... for ... while cond(x)]
I actually like the proposal...If the argument to remove map, lambda and filter can be that list comprehension is more "readable", then why can't this one also use it?Which reminds me this discussion: http://awkly.org/archive/can-python-take-advantage-of-mapreduce/ Cheers!HugoOn 8/6/06, Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote: On Sun, 06 Aug 2006 18:59:39 + (GMT)Duncan Booth < [EMAIL PROTECTED]> wrote:#> >> > I suggest a new extension of the list comprehension syntax:#> >> >#> >> > [x for x in xs while cond(x)]#> >> > #> >> > which would be equivalent to#> >> >#> >> > list(itertools.takewhile(cond, xs))#> >>#> >> What would this syntax offer that:#> >> #> >>[x for x in takewhile(cond, xs)]#> >>#> >> doesn't currently offer?#> >#> > The same thing that [f(x) for x in xs] offers that map(f, xs) doesn't,#> > and the same thing that [x for x in xs if f(x)] offers that filter(f, #> > xs) doesn't. It's more "pythonic". You can use an _expression_ for cond#> > instead of a lambda.#> >#> No, the list comprehension lets you write an _expression_ directly #> avoiding a function call, and it also allows you to add in a#> condition which can be used to filer the sequence.I am not sure if I understand you correctly, but... Does it?>>> a = [0,1,2,3,7,8,9] >>> [x for x in takewhile(lambda x: x in a, range(10))][0, 1, 2, 3]>>> [x for x in takewhile(x in a, range(10))]Traceback (most recent call last): File "", line 1, in ? TypeError: 'bool' object is not callableDid I miss something? Notice that using "if" gives different result:>>> [x for x in range(10) if x in a][0, 1, 2, 3, 7, 8, 9]#> Your proposal adds nothing. Well, I am not sure how useful the proposal really is, but it seems toadd *something* if it would allow for things like:[x for x in range(10) while x in a]-- Best wishes, Slawomir Nowaczyk ( [EMAIL PROTECTED] )Women who seek to be equal to men lack ambition.-- http://mail.python.org/mailman/listinfo/python-list-- GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85 -- http://mail.python.org/mailman/listinfo/python-list
Rendering Vector Graphics
Hi ppl,I need to render high-quality vector graphics with Python. I was thinking of something like 'cairo', though I need to run under win32 and can't find a pycairo package for it. Suggestions?Thanks, Hugo Ferreira-- GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85 -- http://mail.python.org/mailman/listinfo/python-list
PyParsing and Headaches
Hi,
I'm trying to construct a parser, but I'm stuck with some basic stuff... For
example, I want to match the following:
letter = "A"..."Z" | "a"..."z"
literal = letter+
include_bool := "+" | "-"
term = [include_bool] literal
So I defined this as:
literal = Word(alphas)
include_bool = Optional(oneOf("+ -"))
term = include_bool + literal
The problem is that:
term.parseString("+a") -> (['+', 'a'], {}) # OK
term.parseString("+ a") -> (['+', 'a'], {}) # KO. It shouldn't recognize any
token since I didn't said the SPACE was allowed between include_bool and
literal.
Can anyone give me an hand here?
Cheers!
Hugo Ferreira
BTW, the following is the complete grammar I'm trying to implement with
pyparsing:
## L ::= expr | expr L
## expr ::= term | binary_expr
## binary_expr ::= term " " binary_op " " term
## binary_op ::= "*" | "OR" | "AND"
## include_bool ::= "+" | "-"
## term ::= ([include_bool] [modifier ":"] (literal | range)) | ("~"
literal)
## modifier ::= (letter | "_")+
## literal ::= word | quoted_words
## quoted_words ::= '"' word (" " word)* '"'
## word ::= (letter | digit | "_")+
## number ::= digit+
## range ::= number (".." | "...") number
## letter ::= "A"..."Z" | "a"..."z"
## digit ::= "0"..."9"
And this is where I got so far:
word = Word(nums + alphas + "_")
binary_op = oneOf("* and or", caseless=True).setResultsName("operator")
include_bool = oneOf("+ -")
literal = (word | quotedString).setResultsName("literal")
modifier = Word(alphas + "_")
rng = Word(nums) + (Literal("..") | Literal("...")) + Word(nums)
term = ((Optional(include_bool) + Optional(modifier + ":") + (literal |
rng)) | ("~" + literal)).setResultsName("Term")
binary_expr = (term + binary_op + term).setResultsName("binary")
expr = (binary_expr | term).setResultsName("Expr")
L = OneOrMore(expr)
--
GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyParsing and Headaches
Chris,
Thanks for your quick answer. That changes a lot of stuff, and now I'm able
to do my parsing as I intended to.
Paul,
Thanks for your detailed explanation. One of the things I think is missing
from the documentation (or that I couldn't find easy) is the kind of
explanation you give about 'The Way of PyParsing'. For example, It took me a
while to understand that I could easily implement simple recursions using
OneOrMany(Group()). Or maybe things were out there and I didn't searched
enough...
Still, fwiw, congratulations for the library. PyParsing allowed me to do in
just a couple of hours, including learning about it's API (minus this little
inconvenient) what would have taken me a couple of days with, for example,
ANTLR (in fact, I've already put aside ANTLR more than once in the past for
a built-from-scratch parser).
Cheers,
Hugo Ferreira
On 11/22/06, Paul McGuire <[EMAIL PROTECTED]> wrote:
"Bytter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> I'm trying to construct a parser, but I'm stuck with some basic
> stuff... For example, I want to match the following:
>
> letter = "A"..."Z" | "a"..."z"
> literal = letter+
> include_bool := "+" | "-"
> term = [include_bool] literal
>
> So I defined this as:
>
> literal = Word(alphas)
> include_bool = Optional(oneOf("+ -"))
> term = include_bool + literal
>
> The problem is that:
>
> term.parseString("+a") -> (['+', 'a'], {}) # OK
> term.parseString("+ a") -> (['+', 'a'], {}) # KO. It shouldn't
> recognize any token since I didn't said the SPACE was allowed between
> include_bool and literal.
>
As Chris pointed out in his post, the most direct way to fix this is to
use
Combine. Note that Combine does two things: it requires the expressions
to
be adjacent, and it combines the results into a single token. For
instance,
when defining the expression for a real number, something like:
realnum = Optional(oneOf("+ -")) + Word(nums) + "." + Word(nums)
Pyparsing would parse "3.14159" into the separate tokens ['', '3', '.',
'14159']. For this grammar, pyparsing would also accept "2. 23" as ['',
'2', '.', '23'], even though there is a space between the decimal point
and
"23". But by wrapping it inside Combine, as in:
realnum = Combine(Optional(oneOf("+ -")) + Word(nums) + "." + Word(nums))
we accomplish two things: pyparsing only matches if all the elements are
adjacent, with no whitespace or comments; and the matched token is
returned
as ['3.14159']. (Yes, I left off scientific notation, but it is an
extension of the same issue.)
Pyparsing in general does implicit whitespace skipping; it is part of the
zen of pyparsing, and distinguishes it from conventional regexps (although
I
think there is a new '?' switch for re's that puts '\s*'s between re terms
for you). This is to simplify the grammar definition, so that it doesn't
need to be littered with "optional whitespace or comments could go here"
expressions; instead, whitespace and comments (or "ignorables" in
pyparsing
terminology) are parsed over before every grammar expression. I
instituted
this out of recoil from a previous project, in which a co-developer
implemented a boolean parser by first tokenizing by whitespace, then
parsing
out the tokens. Unfortunately, this meant that "color=='blue' &&
size=='medium'" would not parse successfully, instead requiring "color ==
'blue' && size == 'medium'". It doesn't seem like much, but our support
guys got many calls asking why the boolean clauses weren't matching. I
decided that when I wrote a parser, "y=m*x+b" would be just as parseable
as
"y = m * x + b". For that matter, you'd be surprised where whitespace and
comments sneak in to people's source code: spaces after left parentheses
and
comments after semicolons, for example, are easily forgotten when spec'ing
out the syntax for a C "for" statement; whitespace inside HTML tags is
another unanticipated surprise.
So looking at your grammar, you say you don't want to have this be a
successful parse:
term.parseString("+ a") -> (['+', 'a'], {})
because, "It shouldn't recognize any token since I didn't said the SPACE
was
allowed between include_bool and literal." In fact, pyparsing allows
spaces
by default, that's why the given parse succeeds. I would turn this
question
around, and ask you in te
Best way for inter-process communication in Python
Hi everyone! Here's the current scenario: I have a program in Python that computes something very fast (<1s), but it takes a considerable amount of time to read the startup data (>90s). Since the startup data is pretty static, I want this program to be resident and ready in memory all the time. The client-side of this program is a function in PostgreSQL. For the sake of simplicity, let's assume it is another program in Python that will be asking the resident one for results on-demand. Let's also assume that there will be dozens of concurrent requests. My problem is: what is the fastest, easiest way to accomplish this inter-process communication? The data between them will be very small: 1Kb max per request. I've thought about SOAP, sockets and named pipes... But since I have no experience on any of them using Python, I can't decide which way is better... Just a few considerations: Python version is 2.4. PostgreSQL version is 8.2RC1, OS version is Windows Server 2003. Thanks in advance, Hugo Ferreira -- GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85 -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way for inter-process communication in Python
There is another option that I thought while writing this... I can use the database for data communication. Like having a table with both in and out parameters. On the client-side, I fill the in parameters columns. Then I signal the external application which reads the parameters, and write the output. Which raises me the following question... How do I signal a python application under windows? (Is it possible to send something like a SIGHUP?) Cheers! On 12/4/06, Hugo Ferreira <[EMAIL PROTECTED]> wrote: > Hi everyone! > > Here's the current scenario: I have a program in Python that computes > something very fast (<1s), but it takes a considerable amount of time > to read the startup data (>90s). Since the startup data is pretty > static, I want this program to be resident and ready in memory all the > time. > > The client-side of this program is a function in PostgreSQL. For the > sake of simplicity, let's assume it is another program in Python that > will be asking the resident one for results on-demand. Let's also > assume that there will be dozens of concurrent requests. > > My problem is: what is the fastest, easiest way to accomplish this > inter-process communication? The data between them will be very small: > 1Kb max per request. I've thought about SOAP, sockets and named > pipes... But since I have no experience on any of them using Python, I > can't decide which way is better... > > Just a few considerations: Python version is 2.4. PostgreSQL version > is 8.2RC1, OS version is Windows Server 2003. > > Thanks in advance, > > Hugo Ferreira > > -- > GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85 > -- GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85 -- http://mail.python.org/mailman/listinfo/python-list
Best memory analyzer?
Hi! I'm using the BGL bindings, but I think I'm having a giant memory leak. Thing is, I'm not sure if it is the bound C++ variables that are not being trashed, or if the leak is inside my program. What is the best way to debug this? Thanks! Hugo Ferreira -- GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85 -- http://mail.python.org/mailman/listinfo/python-list
SIMD powered Python
Hi! Is there any I&D ongoing about using SIMD [1] instructions, like SSE [2], to speed up Python, especially regarding functional features, like list comprehension, map and reduce, etc.. ? Best regards, Hugo Ferreira -- [1] http://en.wikipedia.org/wiki/SIMD [2] http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions -- http://mail.python.org/mailman/listinfo/python-list
Drawing Text on a Path
Hi everyone, I need to draw some curved text on an image. I've digged both PIL and aggdraw documentation for this kind of feature, but found nothing. However, AGG itself does support rendering text along a path, but I can't seem to figure out how to deal with the API/Wrapper differences... Could someone give me an hand here? Thanks in advance! Hugo Ferreira -- http://mail.python.org/mailman/listinfo/python-list
Python Dijkstra Shortest Path
While trying to optimize this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/119466 ... and still have a fast edge lookup, I've done the following tweaks: class PathFind(object): def __init__(self): self.G = defaultdict(dict) self.E = defaultdict(dict) def addEdge(self, va, vb, cost, edge, way): if way == -1: (vb, va) = (va, vb) self.G[va][vb] = edge if not way: self.G[vb][va] = edge self.E[edge] = cost def findPath(self, start, end): def flatten(L): # Flatten linked list of form [0,[1,[2,[ while len(L) > 0: yield L[0] L = L[1] q = [(0, start, ())] # Heap of (cost, path_head, path_rest). visited = set() # Visited vertices. # Eliminate the dots pattern push, pop, add = heapq.heappush, heapq.heappop, visited.add G, E = self.G, self.E while True: (cost, v1, path) = pop(q) if v1 not in visited: add(v1) path = (v1, path) if v1 == end: return list(flatten(path))[::-1] for (v2, e) in G[v1].iteritems(): if v2 not in visited: push(q, (cost + E[e], v2, path)) def getEdges(self, path): edges = [] for ix in xrange(len(path) - 1): edges.append(self.G[path[ix]][path[ix + 1]]) return edges addEdge() is used to initialize the Graph. It takes a way param: if -1 then the vertex order is reversed; 0 means it is bidir; 1 vertex order is maintained. This version maintains two Dictionaries: one for pair_of_vertexes->edge and another for edge->cost. findPath() will find the path between two vertexes and getEdges(findPath()) will return this list of edges for that path. The "Eliminate the dots" pattern actually improved performance in about 10%. Still, I'm looking for some way to improve even more the performance, while maintaining the dijkstra intact (I don't want an A*). Psyco gave me about 20% of improvement. I wonder if anyone has any idea to make this faster (maybe map? list comprehension? some python trick?)... Profiling blames the heapq (eheh). On a my CoreDuo T2300, it takes 1.6seconds to find a path of 800 vertexes in an half a million mesh. Greetings! Hugo Ferreira -- http://mail.python.org/mailman/listinfo/python-list
Typed named groups in regular expression
Hi!
Is it possible to "automagically" coerce the named groups to python types? e.g.:
>>> type(re.match('(?P\d*)', '123').groupdict()['x'])
But what I'm looking forward is for the type to be 'int'.
Cheers!
Hugo Ferreira
--
http://mail.python.org/mailman/listinfo/python-list
Re: Typed named groups in regular expression
Both Paddy (hackish) and McGuire (right tool for the job) ideas sound
very interesting ;-) I'll definitely research on them further.
Thanks for the support...
On 19 May 2007 04:39:58 -0700, Paul McGuire <[EMAIL PROTECTED]> wrote:
> On May 19, 12:32 am, Paddy <[EMAIL PROTECTED]> wrote:
> > On May 16, 6:58 pm, "Hugo Ferreira" <[EMAIL PROTECTED]> wrote:
> >
> > > Hi!
> >
> > > Is it possible to "automagically" coerce the named groups to python
> > > types? e.g.:
> >
> > > >>> type(re.match('(?P\d*)', '123').groupdict()['x'])
> >
> > >
> >
> > > But what I'm looking forward is for the type to be 'int'.
> >
> > > Cheers!
> >
> > > Hugo Ferreira
> >
> > If you do a ot of that sort of thing in many programs
> > then it might be worth your while to set up a framework
> > that does it. Something like adding an underscore
> > then the name of a type conversion function to all
> > group names, and creating a function to apply the
> > type convertion function to all named groups of a
> > match object.
> > - Paddy.
>
> pyparsing might just be this sort of framework, in that you can attach
> parse actions to elements within a grammar. At parse time, the parse
> action is called with the list of tokens currently matched.
>
> >>> from pyparsing import Regex
> >>> re = Regex( r"(\d*)" ).setResultsName("x")\
> ....setParseAction(lambda t:int(t[0]))
> >>> results = re.parseString("123")
> >>> print results.x
> 123
>
> -- Paul
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
re.sub and empty groups
Hi!
I'm trying to do a search-replace in places where some groups are
optional... Here's an example:
>> re.match(r"Image:([^\|]+)(?:\|(.*))?", "Image:ola").groups()
('ola', None)
>> re.match(r"Image:([^\|]+)(?:\|(.*))?", "Image:ola|").groups()
('ola', '')
>> re.match(r"Image:([^\|]+)(?:\|(.*))?", "Image:ola|ole").groups()
('ola', 'ole')
The second and third results are right, but not the first one, where
it should be equal to the second (i.e., it should be an empty string
instead of None). This is because I want to use re.sub() and when the
group is None, it blows up with a stack trace...
Maybe I'm not getting the essence of groups and non-grouping groups.
Someone care to explain (and, give the correct solution :)) ?
Thanks in advance,
Hugo Ferreira
--
GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85
--
http://mail.python.org/mailman/listinfo/python-list
Synchronous shutil.copyfile()
Hi there, I have a problem. I'm using calling shutil.copyfile() followed by open(). The thing is that most of the times open() is called before the actual file is copied. I don't have this problem when doing a step-by-step debug, since I give enough time for the OS to copy the file, but at run-time, it throws an exception. Is there anyway to force a sync copy of the file (make python wait for the completion)? Thanks in advance! Hugo Ferreira -- http://mail.python.org/mailman/listinfo/python-list
Re: Synchronous shutil.copyfile()
Well.. Thx for the answers. The only way I had to make it work was to use a time.sleep(10) after the shutil.copyfile(). Since this is a night-run script, I can waste 10 seconds, but it still knocks me out "why" it happens... Cheers! Hugo Ferreira On 30 Jan 2007 18:06:15 + (GMT), Matthew Woodcraft < [EMAIL PROTECTED]> wrote: Hugo Ferreira <[EMAIL PROTECTED]> wrote: > I have a problem. I'm using calling shutil.copyfile() followed by > open(). The thing is that most of the times open() is called before > the actual file is copied. I don't have this problem when doing a > step-by-step debug, since I give enough time for the OS to copy the > file, but at run-time, it throws an exception. > > Is there anyway to force a sync copy of the file (make python wait for > the completion)? shutil.copyfile() closes both files before it returns, so I suspect this is an OS-level bug. The most likely culprits are buggy network filesystems and buggy on-access virus scanners. -M- -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Synchronous shutil.copyfile()
I'm banging my head over this one... sometimes it just works... *argh*
Here's a snip of my problem:
import win32com.client
import shutil
import time
engine = win32com.client.Dispatch("DAO.DBEngine.36")
table = 'STUFFTODELETE'
dstFilename = 'in.mdb'
workingfile = 'work.mdb'
shutil.copyfile(dstFilename, workingfile)
print 'Sleeping 5 after copy...'
time.sleep(5)
dstDb = engine.OpenDatabase(workingfile)
print 'Sleeping 5 after open...'
time.sleep(5)
dstDb.Execute('DELETE FROM ' + table)
At at *exactly* this line, I get the error:
C:\Python24\lib\site-packages\win32com\gen_py\00025E01-
--C000-0046x0x5x0.py510
com_error: (-2147352567, 'Exception occurred.', (0, 'DAO.Database', 'Not a
valid bookmark.', 'jeterr40.chm', 5003159, -2146825129), None)
Sometimes... Yes, the database is a %"#$"# MSAccess. This script is running
under windows.
Any ideas?
On 1/31/07, Hugo Ferreira <[EMAIL PROTECTED]> wrote:
Well.. Thx for the answers.
The only way I had to make it work was to use a time.sleep(10) after the
shutil.copyfile(). Since this is a night-run script, I can waste 10
seconds, but it still knocks me out "why" it happens...
Cheers!
Hugo Ferreira
On 30 Jan 2007 18:06:15 + (GMT), Matthew Woodcraft <[EMAIL PROTECTED]>
wrote:
>
> Hugo Ferreira < [EMAIL PROTECTED]> wrote:
> > I have a problem. I'm using calling shutil.copyfile() followed by
> > open(). The thing is that most of the times open() is called before
> > the actual file is copied. I don't have this problem when doing a
> > step-by-step debug, since I give enough time for the OS to copy the
> > file, but at run-time, it throws an exception.
> >
> > Is there anyway to force a sync copy of the file (make python wait for
> > the completion)?
>
> shutil.copyfile() closes both files before it returns, so I suspect
> this is an OS-level bug.
>
> The most likely culprits are buggy network filesystems and buggy
> on-access virus scanners.
>
> -M-
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Knob label justification
By default, a boolean knob has the text label on the right. How can I make it on the left? thx -- http://mail.python.org/mailman/listinfo/python-list
Re: Knob label justification
Sorry, Im using the PythonPanel module of nuke. On 11/11/09 7:20 AM, "Chris Rebert" wrote: > On Wed, Nov 11, 2009 at 3:25 AM, Hugo Léveillé > wrote: >> By default, a boolean knob has the text label on the right. How can I make >> it on the left? > > We're not mind readers. We'll need to know which GUI toolkit you're using. > > Cheers, > Chris > -- > http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Newbie subprocess question
I'm starting various application using subprocess.Popen without any problem. The problem is with application inside "Program Files". It looks like subprocess is stopping the application string after "Program". I tried puting the programe name inside double quote like '"Program File*..."'. No luck. How can I start a app inside this folder ? Thanks -- Hugo Léveillé TD Compositing, Vision Globale hu...@fastmail.net -- http://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] Arguments from the command line
On Mon, Sep 6, 2010 at 5:48 PM, aug dawg wrote: > I've seen Python programs that can be activated from the command line. For > example: > hg > > This displays a list of commands for the Mercurial revision control system. > But another command is this: > hg commit "This is a commit name" > Mercurial is written in Python. I know that commit is a function that > commits to a repo, but what command does the program use in order to get the > commit name, like "This is a commit name" (This would make a commit with > "This is a commit name" as the commit name) > sys.argv is a list of all arguments from the command line. However, you'll rarely deal with it directly, there's various modules that deal with handling arguments. I believe the current one is argparse: http://docs.python.org/library/argparse.html#module-argparse Hugo -- http://mail.python.org/mailman/listinfo/python-list
System idle time under Linux
I have found it for windows and mac, but no luck under linux. Any idea? Thanks -- Hugo Léveillé hu...@fastmail.net -- http://mail.python.org/mailman/listinfo/python-list
Re: System idle time under Linux
Thanks, will take a closer look on that But to get me started, how would you get, via python, the info from that ? Thanks alot On Thu, 30 Sep 2010 02:01 +1300, "Lawrence D'Oliveiro" wrote: > /proc/stat or /proc/uptime, depending. See the proc(5) man page. > -- > http://mail.python.org/mailman/listinfo/python-list > -- Hugo Léveillé hu...@fastmail.net -- http://mail.python.org/mailman/listinfo/python-list
Re: System idle time under Linux
Sorry, I am not a linux guy. Did not know it was a text file On Wed, 29 Sep 2010 14:48 +, "Grant Edwards" wrote: > On 2010-09-29, Hugo L?veill? wrote: > > > > Thanks, will take a closer look on that > > > > But to get me started, how would you get, via python, the info from that? > > Good grief. They're text files. You open them, you read them, > you parse the contents for the stuff you want. > > -- > Grant Edwards grant.b.edwardsYow! Did something bad > at happen or am I in a > gmail.comdrive-in movie?? > -- > http://mail.python.org/mailman/listinfo/python-list > -- Hugo Léveillé hu...@fastmail.net -- http://mail.python.org/mailman/listinfo/python-list
Re: System idle time under Linux
Good point One I am looking for, is time since last user mouse or keyboard action. So I guess I am looking for the exact same thing a screensaver is looking for On Wed, 29 Sep 2010 17:27 +, "Seebs" wrote: > On 2010-09-29, Hugo L?veill? wrote: > > I have found it for windows and mac, but no luck under linux. Any idea? > > I don't think it's semantically well-defined. What makes a system > "idle"? > > Is the machine in my basement idle? I don't think anyone's touched the > keyboard in a week, but it's spent a big chunk of that time with 100% CPU > load across all eight processors, and I was running a bunch of work on > it yesterday, including interactive sessions. > > Windows and Mac systems *typically* have a well-defined "console" on > which > the primary user is active... But as a counterexample, my news reader is > actually running on an OS X box that's about fifty feet from me, which I > connect to via ssh. > > I would be very curious to see whether your test for "system idle time" > would realize that the machine I'm currently working on is actively in > use, > even though I don't think the console is even logged in... > > Basically, I can't help you, but I can tell you that you are quite > possibly > asking the wrong question. > > -s > -- > Copyright 2010, all wrongs reversed. Peter Seebach / > usenet-nos...@seebs.net > http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures > http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! > I am not speaking for my employer, although they do rent some of my > opinions. > -- > http://mail.python.org/mailman/listinfo/python-list > -- Hugo Léveillé hu...@fastmail.net -- http://mail.python.org/mailman/listinfo/python-list
Re: System idle time under Linux
Ok after some testing, what the who -Hu is giving me is the idle time of each running open shell. The first line always return a "?" as the IDLE time. ex: NAME LINE TIME IDLE PID COMMENT vg0619hl :0 2010-09-30 06:10 ? 13091 vg0619hl pts/12010-09-30 06:27 00:11 14084 (:0.0) vg0619hl pts/22010-09-30 06:54 . 14084 (:0.0) On Thu, 30 Sep 2010 02:26 -0700, "John Pinner" wrote: > On Sep 29, 7:36 pm, Hugo Léveillé wrote: > > Good point > > > > One I am looking for, is time since last user mouse or keyboard action. > > So I guess I am looking for the exact same thing a screensaver is > > looking for > > The command > > who -Hu). > > > will give you idle time for each logged-in user > > ( H - print headers; u - list users ) > > and you could run this command via subprocess, then read and parse its > output. > > Alternatively you could parse the same file(s) as who - I think it > reads /var/run/utmp - but that would be a lot more work, as it is a > binary file (run man utmp to see its format, use the struct module to > decode) > > Best wishes, > > John > -- > > > -- > http://mail.python.org/mailman/listinfo/python-list > -- Hugo Léveillé hu...@fastmail.net -- http://mail.python.org/mailman/listinfo/python-list
Random math op
Hi let say I have a simple math apps that randomize number X and number Y. How would you randomize between '/','*','+', and '-' for that math operation -- Hugo Léveillé hu...@fastmail.net -- http://mail.python.org/mailman/listinfo/python-list
[no subject]
hola la vdd lei su documento pero no le entoendo bien mas que nada puedo crear algo con este programa si la respuesta es si mas o menos que si la respuesta en no entoncs pa que sirve a ademas no me pueden pasar oyta guia mas facil mmm soy medio lento de aprendizaje gracias -- http://mail.python.org/mailman/listinfo/python-list
Any Pythonistas in Mexico?
Hola, Leí este mail viejísimo en una lista. Yo uso Python y también quería saber quién pythoneaba en México. Todavía estás por ahí? Saludos, Hugo G. -- http://mail.python.org/mailman/listinfo/python-list
Python 3.14.0 beta 3 is here!
It’s 3.14 beta 3! https://www.python.org/downloads/release/python-3140b3/ This is a beta preview of Python 3.14 Python 3.14 is still in development. This release, 3.14.0b3, is the third of four planned beta releases. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.14 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature-complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2025-07-22). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.14 as possible during the beta phase. This includes creating pre-release wheels for 3.14, as it helps other projects to do their own testing. However, we recommend that your regular production releases wait until 3.14.0rc1, to avoid the risk of ABI breaks. Please keep in mind that this is a preview release and its use is not recommended for production environments. Major new features of the 3.14 series, compared to 3.13 Some of the major new features and changes in Python 3.14 are: New features Note that PEPs 734 and 779 are exceptionally new in beta 3! - PEP 779: Free-threaded Python is officially supported - PEP 649: The evaluation of type annotations is now deferred, improving the semantics of using annotations. - PEP 750: Template string literals (t-strings) for custom string processing, using the familiar syntax of f-strings. - PEP 734: Multiple interpreters in the stdlib. - PEP 784: A new module compression.zstd providing support for the Zstandard compression algorithm. - PEP 758: except and except* expressions may now omit the brackets. - Syntax highlighting in PyREPL, and support for color in unittest, argparse, json and calendar CLIs. - PEP 768: A zero-overhead external debugger interface for CPython. - UUID versions 6-8 are now supported by the uuid module, and generation of versions 3-5 and 8 are up to 40% faster. - PEP 765: Disallow return/break/continue that exit a finally block. - PEP 741: An improved C API for configuring Python. - A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source. - Improved error messages. - Builtin implementation of HMAC with formally verified code from the HACL* project. - A new command-line interface to inspect running Python processes using asynchronous tasks. - The pdb module now supports remote attaching to a running Python process. (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) For more details on the changes to Python 3.14, see What’s new in Python 3.14. The next pre-release of Python 3.14 will be the final beta, 3.14.0b4, scheduled for 2025-07-08. https://docs.python.org/3.14/whatsnew/3.14.html Build changes - PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. - Official macOS and Windows release binaries include an experimental JIT compiler. Incompatible changes, removals and new deprecations - Incompatible changes - Python removals and deprecations - C API removals and deprecations - Overview of all pending deprecations Python install manager The installer we offer for Windows is being replaced by our new install manager, which can be installed from the Windows Store or our FTP page. See our documentation for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. More resources - [Online documentation](https://docs.python.org/3.14/) - [PEP 745](https://peps.python.org/pep-0745/), 3.14 Release Schedule - Report bugs at [ github.com/python/cpython/issues](https://github.com/python/cpython/issues) - [Help fund Python and its community](https://www.python.org/psf/donations/ ) And now for something completely different If you’re heading out to sea, remember the Maritime Approximation: π mph = e knots https://xkcd.com/3023/ Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from sunny Helsinki with 19 hours of daylight, Your release team, Hugo
Python 3.14.0 beta 4 is here!
It’s the final 3.14 beta! https://www.python.org/downloads/release/python-3140b4/ This is a beta preview of Python 3.14 Python 3.14 is still in development. This release, 3.14.0b4, is the last of four planned beta releases. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.14 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature-complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2025-07-22). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.14 as possible during the beta phase. This includes creating pre-release wheels for 3.14, as it helps other projects to do their own testing. However, we recommend that your regular production releases wait until 3.14.0rc1, to avoid the risk of ABI breaks. Please keep in mind that this is a preview release and its use is not recommended for production environments. Major new features of the 3.14 series, compared to 3.13 Some of the major new features and changes in Python 3.14 are: New features - PEP 779: Free-threaded Python is officially supported - PEP 649: The evaluation of type annotations is now deferred, improving the semantics of using annotations. - PEP 750: Template string literals (t-strings) for custom string processing, using the familiar syntax of f-strings. - PEP 734: Multiple interpreters in the stdlib. - PEP 784: A new module compression.zstd providing support for the Zstandard compression algorithm. - PEP 758: except and except* expressions may now omit the brackets. - Syntax highlighting in PyREPL, and support for color in unittest, argparse, json and calendar CLIs. - PEP 768: A zero-overhead external debugger interface for CPython. - UUID versions 6-8 are now supported by the uuid module, and generation of versions 3-5 and 8 are up to 40% faster. - PEP 765: Disallow return/break/continue that exit a finally block. - PEP 741: An improved C API for configuring Python. - A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source. - Improved error messages. - Builtin implementation of HMAC with formally verified code from the HACL* project. - A new command-line interface to inspect running Python processes using asynchronous tasks. - The pdb module now supports remote attaching to a running Python process. (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) For more details on the changes to Python 3.14, see What’s new in Python 3.14. The next pre-release of Python 3.14 will be the first release candidate, 3.14.0rc1, scheduled for 2025-07-22. https://docs.python.org/3.14/whatsnew/3.14.html Build changes - PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. - Official macOS and Windows release binaries include an experimental JIT compiler. Incompatible changes, removals and new deprecations - Incompatible changes - Python removals and deprecations - C API removals and deprecations - Overview of all pending deprecations Python install manager The installer we offer for Windows is being replaced by our new install manager, which can be installed from the Windows Store or from its download page. See our documentation for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. More resources - Online documentation](https://docs.python.org/3.14/) - PEP 745](https://peps.python.org/pep-0745/), 3.14 Release Schedule - Report bugs at https://github.com/python/cpython/issues - Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different All this talk of π and yet some say π is wrong. Tau Day (June 28th, 6/28 in the US) celebrates τ as the “true circle constant”, as the ratio of a circle’s circumference to its radius, C/r = 6.283185… The Tau Manifesto declares π “a confusing and unnatural choice for the circle constant”, in part because “2π occurs with astonishing frequency throughout mathematics”. If you wish to embrace τ the good news is PEP 628 added math.tau to Python 3.6 in 2016: When working with radians, it is trivial to convert any given
[RELEASE] Python 3.14.0 alpha 1 is now available
It's now time for a new alpha of a new version of Python! https://www.python.org/downloads/release/python-3140a1/ **This is an early developer preview of Python 3.14** # Major new features of the 3.14 series, compared to 3.13 Python 3.14 is still in development. This release, 3.14.0a1 is the first of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is **not** recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: * PEP 649 (https://peps.python.org/pep-0649/): deferred evaluation of annotations ( https://docs.python.org/3.14/whatsnew/3.14.html#pep-649-deferred-evaluation-of-annotations ) * Improved error messages ( https://docs.python.org/3.14/whatsnew/3.14.html#improved-error-messages) * (Hey, **fellow core developer,** if a feature you find important is missing from this list, [let Hugo know (h...@python.org).) The next pre-release of Python 3.14 will be 3.14.0a2, currently scheduled for 2024-11-19. # More resources * Online documentation: https://docs.python.org/3.14/ * PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0719/ * Report bugs at https://github.com/python/cpython/issues * Help fund Python and its community: https://www.python.org/psf/donations/ # And now for something completely different π (or pi) is a mathematical constant, approximately 3.14, for the ratio of a circle's circumference to its diameter. It is an irrational number, which means it cannot be written as a simple fraction of two integers. When written as a decimal, its digits go on forever without ever repeating a pattern. Here's 76 digits of π: 3.141592653589793238462643383279502884197169399375105820974944592307816406286 Piphilology is the creation of mnemonics to help remember digits of π. In a pi-poem, or "piem", the number of letters in a word equal the corresponding digit. This covers 9 digits, 3.14159265: > *How I wish I could recollect pi easily today!* One of the most well-known covers 15 digits, 3.14159265358979: > *How I want a drink, alcoholic of course, after the heavy chapters involving quantum mechanics!* Here's a 35-word piem in the shape of a circle, 3.1415926535897932384626433832795728: It's a fact A ratio immutable Of circle round and width, Produces geometry's deepest conundrum. For as the numerals stay random, No repeat lets out its presence, Yet it forever stretches forth. Nothing to eternity. The Guiness World Record for memorising the most digits is held by Rajveer Meena, who recited 70,000 digits blindfold in 2015. The unofficial record is held by Akira Haraguchi who recited 100,000 digits in 2006. # Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Regards from a bright and colourful Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.14.0 alpha 2 is out
Alpha 2? But Alpha 1 only just came out! https://www.python.org/downloads/release/python-3140a2/ This is an early developer preview of Python 3.14 Major new features of the 3.14 series, compared to 3.13: Python 3.14 is still in development. This release, 3.14.0a2 is the second of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: * PEP 649: deferred evaluation of annotations * PEP 741: Python configuration C API * PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. * Improved error messages * (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) The next pre-release of Python 3.14 will be 3.14.0a3, currently scheduled for 2024-12-17. More resources * Online documentation: https://docs.python.org/3.14/ * PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0719/ * Report bugs at https://github.com/python/cpython/issues * Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different Ludolph van Ceulen (1540-1610) was a fencing and mathematics teacher in Leiden, Netherlands, and spent around 25 years calculating π (or pi), using essentially the same methods Archimedes employed some seventeen hundred years earlier. Archimedes estimated π by calculating the circumferences of polygons that fit just inside and outside of a circle, reasoning the circumference of the circle lies between these two values. Archimedes went up to polygons with 96 sides, for a value between 3.1408 and 3.1428, which is accurate to two decimal places. Van Ceulen used a polygon with half a billion sides. He published a 20-decimal value in his 1596 book Vanden Circkel (“On the Circle”), and later expanded it to 35 decimals: 3.14159265358979323846264338327950288 Van Ceulen’s 20 digits is more than enough precision for any conceivable practical purpose. For example, even if a printed circle was perfect down to the atomic scale, the thermal vibrations of the molecules of ink would make most of those digits physically meaningless. NASA Jet Propulsion Laboratory’s highest accuracy calculations, for interplanetary navigation, uses 15 decimals: 3.141592653589793. At Van Ceulen’s request, his upper and lower bounds for π were engraved on his tombstone in Leiden. The tombstone was eventually lost but restored in 2000. In the Netherlands and Germany, π is sometimes referred to as the “Ludolphine number”, after Van Ceulen. Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from a chilly Helsinki with snow on the way, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.14.0 alpha 3 is out
O Alpha 3, O Alpha 3, how lovely are your branches! https://www.python.org/downloads/release/python-3140a3/ This is an early developer preview of Python 3.14. Python 3.14 is still in development. This release, 3.14.0a3, is the third of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: * PEP 649: deferred evaluation of annotations * PEP 741: Python configuration C API * PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. * Improved error messages * (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) The next pre-release of Python 3.14 will be 3.14.0a4, currently scheduled for 2025-01-14. More resources: * Online documentation: https://docs.python.org/3.14/ * PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0745/ * Report bugs at https://github.com/python/cpython/issues * Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different A mince pie is a small, round covered tart filled with “mincemeat”, usually eaten during the Christmas season – the UK consumes some 800 million each Christmas. Mincemeat is a mixture of things like apple, dried fruits, candied peel and spices, and originally would have contained meat chopped small, but rarely nowadays. They are often served warm with brandy butter. According to the Oxford English Dictionary, the earliest mention of Christmas mince pies is by Thomas Dekker, writing in the aftermath of the 1603 London plague, in Newes from Graues-end: Sent to Nobody (1604): Ten thousand in London swore to feast their neighbors with nothing but plum-porredge, and mince-pyes all Christmas. Here’s a meaty recipe from Rare and Excellent Receipts, Experienc’d and Taught by Mrs Mary Tillinghast and now Printed for the Use of her Scholars Only (1678): XV. How to make Mince-pies. To every pound of Meat, take two pound of beef Suet, a pound of Corrants, and a quarter of an Ounce of Cinnamon, one Nutmeg, a little beaten Mace, some beaten Colves, a little Sack & Rose-water, two large Pippins, some Orange and Lemon peel cut very thin, and shred very small, a few beaten Carraway-seeds, if you love them the Juyce of half a Lemon squez’d into this quantity of meat; for Sugar, sweeten it to your relish; then mix all these together and fill your Pie. The best meat for Pies is Neats-Tongues, or a leg of Veal; you may make them of a leg of Mutton if you please; the meat must be parboyl’d if you do not spend it presently; but if it be for present use, you may do it raw, and the Pies will be the better. Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from a snowy and slippery Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa -- https://mail.python.org/mailman/listinfo/python-list
Python 3.14.0 alpha 4 is out
Hello, three dot fourteen dot zero alpha four! https://www.python.org/downloads/release/python-3140a4/ This is an early developer preview of Python 3.14. Python 3.14 is still in development. This release, 3.14.0a4, is the fourth of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: * PEP 649: deferred evaluation of annotations * PEP 741: Python configuration C API * PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. * Improved error messages * Removals of old deprecations, and new deprecations, many scheduled for removal from Python 3.16 * C API removals and deprecations * (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) The next pre-release of Python 3.14 will be 3.14.0a5, currently scheduled for 2025-02-11. More resources: * Online documentation: https://docs.python.org/3.14/ * PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0745/ * Report bugs at https://github.com/python/cpython/issues * Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different In Python, you can use Greek letters as constants. For example: ``` from math import pi as π def circumference(radius: float) -> float: return 2 * π * radius print(circumference(6378.137)) # 40075.016685578485 ``` Enjoy the new release. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from a slushy, slippery Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa -- https://mail.python.org/mailman/listinfo/python-list
Python 3.14.0 alpha 5
Here comes the antepenultimate alpha. https://www.python.org/downloads/release/python-3140a5/ This is an early developer preview of Python 3.14. Major new features of the 3.14 series, compared to 3.13: Python 3.14 is still in development. This release, 3.14.0a5, is the fifth of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: - PEP 649: deferred evaluation of annotations - PEP 741: Python configuration C API - PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. - Improved error messages - A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source. - Python removals and deprecations - C API removals and deprecations - (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) The next pre-release of Python 3.14 will be the penultimate alpha, 3.14.0a6, currently scheduled for 2025-03-14. More resources: - Online documentation: https://docs.python.org/3.14/ - PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0745/ - Report bugs at https://github.com/python/cpython/issues - Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different! 2025-01-29 marked the start of a new lunar year, the Year of the Snake 🐍 (and the Year of Python?). For centuries, π was often approximated as 3 in China. Some time between the years 1 and 5 CE, astronomer, librarian, mathematician and politician Liu Xin (劉歆) calculated π as 3.154. Around 130 CE, mathematician, astronomer, and geographer Zhang Heng (張衡, 78–139) compared the celestial circle with the diameter of the earth as 736:232 to get 3.1724. He also came up with a formula for the ratio between a cube and inscribed sphere as 8:5, implying the ratio of a square’s area to an inscribed circle is √8:√5. From this, he calculated π as √10 (~3.162). Third century mathematician Liu Hui (刘徽) came up with an algorithm for calculating π iteratively: calculate the area of a polygon inscribed in a circle, then as the number of sides of the polygon is increased, the area becomes closer to that of the circle, from which you can approximate π. This algorithm is similar to the method used by Archimedes in the 3rd century BCE and Ludolph van Ceulen in the 16th century CE (see 3.14.0a2 release notes), but Archimedes only went up to a 96-sided polygon (96-gon). Liu Hui went up to a 192-gon to approximate π as 157/50 (3.14) and later a 3072-gon for 3.14159. Liu Hu wrote a commentary on the book The Nine Chapters on the Mathematical Art which included his π approximations. In the fifth century, astronomer, inventor, mathematician, politician, and writer Zu Chongzhi (祖沖之, 429–500) used Liu Hui’s algorithm to inscribe a 12,288-gon to compute π between 3.1415926 and 3.1415927, correct to seven decimal places. This was more accurate than Hellenistic calculations and wouldn’t be improved upon for 900 years. Happy Year of the Snake! Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from a remarkably snowless Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa -- https://mail.python.org/mailman/listinfo/python-list
Python 3.14.0 alpha 6
Here comes the penultimate alpha. https://www.python.org/downloads/release/python-3140a6/ This is an early developer preview of Python 3.14 Major new features of the 3.14 series, compared to 3.13: Python 3.14 is still in development. This release, 3.14.0a6, is the sixth of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: - PEP 649: deferred evaluation of annotations - PEP 741: Python configuration C API - PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. - Improved error messages - A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source. - UUID versions 6-8 are now supported by the uuid module, and generation of versions 3-5 and 8 are up to 40% faster. - Python removals and deprecations - C API removals and deprecations - (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) The next pre-release of Python 3.14 will be the final alpha, 3.14.0a7, currently scheduled for 2025-04-08. More resources - Online documentation: https://docs.python.org/3.14/ - PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0745/ - Report bugs at https://github.com/python/cpython/issues - Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different! March 14 is celebrated as pi day, because 3.14 is an approximation of π. The day is observed by eating pies (savoury and/or sweet) and celebrating π. The first pi day was organised by physicist and tinkerer Larry Shaw of the San Francisco Exploratorium in 1988. It is also the International Day of Mathematics and Albert Einstein’s birthday. Let’s all eat some pie, recite some π, install and test some py, and wish a happy birthday to Albert, Loren and all the other pi day children! Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from Helsinki as fresh snow falls, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa -- https://mail.python.org/mailman/listinfo/python-list
Python 3.14.0a7, 3.13.3, 3.12.10, 3.11.12, 3.10.17 and 3.9.22 are now available
Not one, not two, not three, not four, not five, but six releases! Is this the most in a single day? 3.12-3.14 were regularly scheduled, and we had some security fixes to release in 3.9-3.11 so let’s make a big day of it. This also marks the last bugfix release of 3.12 as it enters the security-only phase. Python 3.14.0a7 Here comes the final alpha! This means we have just four weeks until the first beta to get those last features into 3.14 before the feature freeze on 2025-05-06! https://www.python.org/downloads/release/python-3140a7/ This is an early developer preview of Python 3.14 Major new features of the 3.14 series, compared to 3.13: Python 3.14 is still in development. This release, 3.14.0a7, is the last of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: - PEP 649: deferred evaluation of annotations - PEP 741: Python configuration C API - PEP 758: Allow except and except* expressions without parentheses - PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. - PEP 765: disallow return/break/continue that exit a finally block - PEP 768: Safe external debugger interface for CPython - A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source. - UUID versions 6-8 are now supported by the uuid module, and generation of versions 3-5 and 8 are up to 40% faster. - Improved error messages - Python removals and deprecations - C API removals and deprecations - (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) The next pre-release of Python 3.14 will be the first beta, 3.14.0b1, currently scheduled for 2025-05-06. After this, no new features can be added but bug fixes and docs improvements are allowed – and encouraged! Python 3.13.3 This is the third maintenance release of Python 3.13. Python 3.13 is the newest major release of the Python programming language, and it contains many new features and optimizations compared to Python 3.12. 3.13.3 is the latest maintenance release, containing almost 320 bugfixes, build improvements and documentation changes since 3.13.2. https://www.python.org/downloads/release/python-3133/ Python 3.12.10 This is the tenth maintenance release of Python 3.12. Python 3.12.10 is the latest maintenance release of Python 3.12, and the last full maintenance release. Subsequent releases of 3.12 will be security-fixes only. This last maintenance release contains about 230 bug fixes, build improvements and documentation changes since 3.12.9. https://www.python.org/downloads/release/python-31210/ Python 3.11.12 This is a security release of Python 3.11: - gh-106883: Fix deadlock in threaded application when using sys._current_frames - gh-131809: Upgrade vendored expat to 2.7.1 - gh-80222: Folding of quoted string in display_name violates RFC - gh-121284: Invalid RFC 2047 address header after refolding with email.policy.default - gh-131261: Update libexpat to 2.7.0 - gh-105704: [CVE-2025-0938] urlparse does not flag hostname containing [ or ] as incorrect - gh-119511: OOM vulnerability in the imaplib module https://www.python.org/downloads/release/python-31112/ Python 3.10.17 This is a security release of Python 3.10: - gh-131809: Upgrade vendored expat to 2.7.1 - gh-80222: Folding of quoted string in display_name violates RFC - gh-121284: Invalid RFC 2047 address header after refolding with email.policy.default - gh-131261: Update libexpat to 2.7.0 - gh-105704: CVE-2025-0938 urlparse does not flag hostname containing [ or ] as incorrect - gh-119511: OOM vulnerability in the imaplib module https://www.python.org/downloads/release/python-31017/ Python 3.9.22 This is a security release of Python 3.9: - gh-131809 and gh-131261: Upgrade vendored expat to 2.7.1 - gh-121284: Invalid RFC 2047 address header after refolding with email.policy.default - gh-105704: CVE-2025-0938 urlparse does not flag hostname containing [ or ] as incorrect - gh-119511: OOM vulnerability in the imaplib module https://www.python.org/downloads/release/python-3922/ Please upgrade! Please test! We highly recommend upgrading 3.9-3.13 and we encourage you to test 3.14. And now for something completely different On Saturday, 5th April, 3.141592653589793 months of the year had elapsed. Enjoy the new releases
Python 3.14.0 beta 1 is here!
mathematics and helping with the ship’s navigation. On return to London seven years later, he became a maths teacher in coffee houses and a private tutor. In 1706, Jones published Synopsis Palmariorum Matheseos which used the symbol π for the ratio of a circle’s circumference to diameter. Jones was also the first person to realise π is an irrational number, meaning it can be written as a decimal number that goes on forever, but cannot be written as a fraction of two integers. But why π? It’s thought Jones used the Greek letter π because it’s the first letter in perimetron or perimeter. Jones was the first to use π as our familiar ratio but wasn’t the first to use it in as part of the ratio. William Oughtred, in his 1631 Clavis Mathematicae (The Key of Mathematics), used π/δ to represent what we now call pi. His π was the circumference, not the ratio of circumference to diameter. James Gregory, in his 1668 Geometriae Pars Universalis (The Universal Part of Geometry) used π/ρ instead, where ρ is the radius, making the ratio 6.28… or τ. After Jones, Leonhard Euler had used π for 6.28…, and also p for 3.14…, before settling on and popularising π for the famous ratio. Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from Helsinki as the leaves begin to appear on the trees, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa -- https://mail.python.org/mailman/listinfo/python-list
Python 3.14.0 beta 2 is here!
Here’s the second 3.14 beta. https://www.python.org/downloads/release/python-3140b2/ This is a beta preview of Python 3.14 Python 3.14 is still in development. This release, 3.14.0b2, is the second of four planned beta releases. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.14 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature-complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2025-07-22). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.14 as possible during the beta phase. This includes creating pre-release wheels for 3.14, as it helps other projects to do their own testing. However, we recommend that your regular production releases wait until 3.14.0rc1, to avoid the risk of ABI breaks. Please keep in mind that this is a preview release and its use is not recommended for production environments. Major new features of the 3.14 series, compared to 3.13 Some of the major new features and changes in Python 3.14 are: New features - PEP 649: The evaluation of type annotations is now deferred, improving the semantics of using annotations. - PEP 750: Template string literals (t-strings) for custom string processing, using the familiar syntax of f-strings. - PEP 784: A new module compression.zstd providing support for the Zstandard compression algorithm. - PEP 758: except and except* expressions may now omit the brackets. - Syntax highlighting in PyREPL, and support for color in unittest, argparse, json and calendar CLIs. - PEP 768: A zero-overhead external debugger interface for CPython. - UUID versions 6-8 are now supported by the uuid module, and generation of versions 3-5 and 8 are up to 40% faster. - PEP 765: Disallow return/break/continue that exit a finally block. - PEP 741: An improved C API for configuring Python. - A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source. - Improved error messages. - Builtin implementation of HMAC with formally verified code from the HACL* project. - A new command-line interface to inspect running Python processes using asynchronous tasks. - The pdb module now supports remote attaching to a running Python process. (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) For more details on the changes to Python 3.14, see What’s new in Python 3.14. The next pre-release of Python 3.14 will be 3.14.0b3, scheduled for 2025-06-17. https://docs.python.org/3.14/whatsnew/3.14.html Build changes - PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. - Official macOS and Windows release binaries include an experimental JIT compiler. Python install manager The installer we offer for Windows is being replaced by our new install manager, which can be installed from the Windows Store or our FTP page. See our documentation for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. More resources - Online documentation: https://docs.python.org/3.14/ - PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0745/ - Report bugs at https://github.com/python/cpython/issues - Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different In 1897, the State of Indiana almost passed a bill defining π as 3.2. Of course, it’s not that simple. Edwin J. Goodwin, M.D., claimed to have come up with a solution to an ancient geometrical problem called squaring the circle, first proposed in Greek mathematics. It involves trying to draw a circle and a square with the same area, using only a compass and a straight edge. It turns out to be impossible because π is transcendental (and this had been proved just 13 years earlier by Ferdinand von Lindemann), but Goodwin fudged things so the value of π was 3.2 (his writings have included at least nine different values of π: including 4, 3.236, 3.232, 3.2325… and even 9.2376…). Goodwin had copyrighted his proof and offered it to the State of Indiana to use in their educational textbooks without paying royalties, provided they endorsed it
Python 3.14 release candidate 1 is go!
It’s the first 3.14 release candidate! https://www.python.org/downloads/release/python-3140rc1/ This release, 3.14.0rc1, is the penultimate release preview. Entering the release candidate phase, only reviewed code changes which are clear bug fixes are allowed between this release candidate and the final release. The second candidate (and the last planned release preview) is scheduled for Tuesday, 2025-08-26, while the official release of 3.14.0 is scheduled for Tuesday, 2025-10-07. There will be no ABI changes from this point forward in the 3.14 series, and the goal is that there will be as few code changes as possible. Call to action We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.14 during this phase, and where necessary publish Python 3.14 wheels on PyPI to be ready for the final release of 3.14.0, and to help other projects do their own testing. Any binary wheels built against Python 3.14.0rc1 will work with future versions of Python 3.14. As always, report any issues to the Python bug tracker. Please keep in mind that this is a preview release and while it’s as close to the final release as we can get it, its use is not recommended for production environments. Core developers: time to work on documentation now - Are all your changes properly documented? - Are they mentioned in What’s New? - Did you notice other changes you know of to have insufficient documentation? Major new features of the 3.14 series, compared to 3.13 Some of the major new features and changes in Python 3.14 are: New features - PEP 779: Free-threaded Python is officially supported - PEP 649: The evaluation of type annotations is now deferred, improving the semantics of using annotations. - PEP 750: Template string literals (t-strings) for custom string processing, using the familiar syntax of f-strings. - PEP 734: Multiple interpreters in the stdlib. - PEP 784: A new module compression.zstd providing support for the Zstandard compression algorithm. - PEP 758: except and except* expressions may now omit the brackets. - Syntax highlighting in PyREPL, and support for color in unittest, argparse, json and calendar CLIs. - PEP 768: A zero-overhead external debugger interface for CPython. - UUID versions 6-8 are now supported by the uuid module, and generation of versions 3-5 are up to 40% faster. - PEP 765: Disallow return/break/continue that exit a finally block. - PEP 741: An improved C API for configuring Python. - A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source. - Improved error messages. - Builtin implementation of HMAC with formally verified code from the HACL* project. - A new command-line interface to inspect running Python processes using asynchronous tasks. - The pdb module now supports remote attaching to a running Python process. (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) For more details on the changes to Python 3.14, see What’s new in Python 3.14. The next pre-release of Python 3.14 will be the final release candidate, 3.14.0rc2, scheduled for 2025-08-26. https://docs.python.org/3.14/whatsnew/3.14.html Build changes - PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. - Official macOS and Windows release binaries include an experimental JIT compiler. Incompatible changes, removals and new deprecations - Incompatible changes - Python removals and deprecations - C API removals and deprecations - Overview of all pending deprecations Python install manager The installer we offer for Windows is being replaced by our new install manager, which can be installed from the Windows Store or from its download page. See our documentation for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. More resources - Online documentation https://docs.python.org/3.14/ - PEP 745: 3.14 Release Schedule https://peps.python.org/pep-0745/ - Report bugs at https://github.com/python/cpython/issues - Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different Today, 22nd July, is Pi Approximation Day, because 22/7 is a common approximation of π and closer to π than 3.14. 22/7 is a Diophantine approximation, named after Diophantus of Alexandria (3rd century CE), which is a way of estimating a real number as a ratio of two integers. 22/7 has been known since antiquity; Archimedes (3rd century BCE) wrote the first known proof that 22/7 overestimates π by comparing 96-sided polygons to the circle it
